How do you control the amount of memory a bshell reserves as users login? Is there a minumum before the bshell perfoms poorly for the user?

The reason I ask is I would like to manage the memory ours use on our HPUX system. I'm not even sure at this point if it a bshell parameter setting or a kernel parameter.

When a user logs in to Baan, the bshell process "reserves" approximately 45 mb of memory (VSS value in HPUX), but it appears to only actively use around 1-5 mb (RSS value). For example, I just logged in and sitting at the main menu, my bshell reserved memory is 41.9 mb, but it "active" memory is only 1.5 mb.

A secondary question is some bshells (a process we call automation) build up a lot of memory over time. Does anyone know of a way to tell it to free the memory and reset to the minimum without logging it out?

Sorry for the long post and thanks in advance.

RSS (Resident Set Size) is the portion of the process that resides in the physical memory while VSS (Virtual Set Size) is the memory portion of the process that could potentially be loaded into that same physical memory. Rarely will you see all the VSS part being loaded into physical memory (RSS=VSS). Unless your VSS start growing in alarming way - e.g. memory leaking - then there's no real reason for concern.

As to memory tuning: I don't think you can directly tune the bshell's memory consumption as you mean it (unless you would change and recompile the executable). However there is a set of 3 kernel parameters that can control the maximum values of 3 important process components: text, data and stack:
MAXTSIZE: maximum memory for TEXT (or executable code)
MAXDSIZE: maximum memory for DATA (program data structures)
MAXSSIZE: maximum memory for STACK (program internal data structures)
You could try to tune any of these parameters downwards but take care not to run into problems with some of the heavier processes (e.g. err 28). I would stick to the minimum recommended values in your Baan installation guide.

Thanks for the reply Patrick. That helps me understand it a little better, but leads me to maybe a more clear question. If the VSS portion is the portion that could potentially be loaded into the same physical memory isn't the system reserving that memory, reducing the amount of physical memory available to other processes?

We bump up against our memory threshhold (100% usage in glance) after we've been running a couple weeks without downtime. I'm just wondering if we can better manage our memory by controlling the initial value of that VSS number if that's even possible. Maybe it has no effect.

We end up booting the users and making them log back in and we have about 65 to 70% usage then.

Greg,

You have to distinguish between physical and virtual memory. The VSS portion of each process resides in your virtual memory, ie swap space. 'Swapping' or allocating space (page-ins) in your virtual memory is NOT necessarily bad IF those events do not go hand-in-hand with pages being loaded into your physical memory (page-outs). Depending on your usage pattern it could be normal that your memory usage increases after initial startup and then levels out gradually (e.g. typical office hours pattern vs 24x7 operation). Again a 100% memory usage doesn't necessarily has to be bad if 100% is all your processes really need. However it could be a sign that you would need to do some capacity planning to handle future demand. So what you really should be looking at when reaching your 100% memory threshold is the virtual memory (page-outs) activity.

Thanks again Patrick. I'll look deeper into the page out activity when we reach 100% again.

Greg,

One other thing you may consider checking is the configuration of your UNIX buffer cache. Ideally this should be set for a dynamic configuration.