RE: UV command failing mystery

[Vance Dailey]

We upgraded our system from a 16 processor AV20000 to an 8 processor AV25000. Because each block of 4 cpus can only support 4gb of memory our upgrade was going to cut our memory in half. So, the main purpose of the changes was to cut the memory requirements of the universe lock tables. And in fact we successfully cut the per user memory usage in half. The other changes were made as part of the overall review prior to the upgrade. I intend to set a few of the Unix setting back to their original values this weekend, but if I understand the parameters its hard to see how the current values could be causing the problem. I should point out that the uv problem occurred a few time prior to the system upgrade so I have discounted the possibility that the upgrade could be the problem. We are running more users now and the frequency of the problem has increased over the last couple of weeks. However the problem happens at random times, sometimes with 10 users logged in, and at other times with 700 users logged in. I'll let everyone know if changing the parameters back helps the problem, but I am not real optimistic since we only experienced the problem a few times in the month following the changes but we are now getting the problem an average of once a day.

Thanks for responding. All suggestions are welcome.

Vance Dailey

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Timothy Snyder
Sent: Wednesday, February 04, 2004 11:44 AM
To: U2 Users Discussion List
Subject: Re: UV command failing mystery

<snip>
The only thing that may be suspicious is some changes we made to
some kernel and UV config settings a few weeks prior to the first reported
problem. The following changes were made:

(KERNEL)
SDELSIM 2048 TO 256
SEMOPM 100 TO 64
SEMUME 1024 TO 64
SHMMNI 4096 TO 2048
SEMMNI 4096 TO 2048

(UV CONFIG)
MFILES 56 TO 200
T30FILE 8000 TO 200 (we have no dynamic files)
FSEMNUM 101 TO 50
GSEMNUM 211 TO 97
GLTABSZ 150 TO 75
RLTABSZ 150 TO 75
MAXRLOCK 100 TO 74
<snip>


Just curious as to why so many parameters were reduced on a running system. Were you exhausting some sort of resource? I wouldn't imagine that most of these parameters would have caused problems at their original values, unless you're working with an incredibly small system. I generally don't like to change ANYTHING downward - especially on a functional production system - unless there's a compelling reason.



Tim Snyder
IBM Data Management Solutions
Consulting I/T Specialist , U2 Professional Services

[EMAIL PROTECTED]

-- 
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users