From: Matthew Glanville

I have seen those errors on one ADSM server when running SUN Solaris 2.6
and ADSM 3.1

If I remember correctly, It didn't appear to be memory related.  It just
was that too many things were going on at once on the TSM server (too many
threads?).  I reduced the number of volumes in the disk pools (there werer
over 60, 1 GB volumes, changed that to 6, 10 GB volumes ) and reduced the
maximum sessions setting and never had that problem again.

Maybe this will help...

Matthew Glanville





Andy Carlson <[EMAIL PROTECTED]> on 01/30/2001 02:12:36 PM

Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>

To:   [EMAIL PROTECTED]
cc:    (bcc: Matthew Glanville/437358/EKC)
Subject:  Re: 1GB Buffer Pool Memory




I am running it as root, with no limit.  I have 4GB real memory, and 3GB
of paging space, 1% used.

Andy Carlson                             |\      _,,,---,,_
[EMAIL PROTECTED]            ZZZzz /,`.-'`'    -.  ;-;;,_
BJC Health System                       |,4-  ) )-,_. ,\ (  `'-'
St. Louis, Missouri                    '---''(_/--'  `-'\_)
Cat Pics: http://andyc.dyndns.org/animal.html

On Tue, 30 Jan 2001, Richard Sims wrote:

> >Has anyone seen strange behviour what the buffer pool memory is greater
> >than 1GB?  I normally have mine set to about 800MB, but since I have
> >some spare memory, tried 1.2GB.  It runs well for a while, but then
> >exhibits strange behaviour.  I enter admin commends, and the headings
> >come back and say <UNNAMED> or <UNKNOWN>, messages do not come out
> >correctly, I can't start new sessions, etc.  This is fairly repeatable
> >behaviour.  I am at 3.7.4.  Thanks.
>
> Andy - I presume you mean the BUFPoolsize.  There is no TSM limit; but
>        you need to stay within your system's virtual memory size.
> What is that on your system?
>
> Interesting that pushing the value yields flakey behavior instead of
> an advisory message or the like.  I presume there was no opsys limit
> on the userid which started the server, which may influence the
> server's ability to acquire storage...
>
>   Richard Sims, BU
>

Reply via email to