memory allocation for programs

[Tom Wallin_1]

I am wondering how the loader part of an executable calculates the
amount of memory to set aside for each program a user runs in his
environment. That is when a user types in a programs name at the prompt
and hits "Enter" How does the loader figure out how much memory to set
aside for it to run. I think it needs some for code, some for stack
space, and some for data.

We have identical programs, running on different servers, that are
grabbing two different amounts of memory when they are run.
The two different servers are as follows -
1. Alpha 4100 running V4.0F PK7 - has 3GB RAM
2. Alpha ES40 running V5.1b PK4 - has 8GB RAM

On the ES40 the program grabs 10x the amount of memory that it does on
the 4100.

Tom Wallin

[Hein van den Heuvel]

What do you use to tell the size?
ps -o RSS,VSZ ?

RSS is Real memory (resident set)
VSZ is Process virtual address size ... the program may or might not touch that all.
I suspect that RSS is similar, VSZ different.

I would also compare output for sysconfig -q proc

And check: ulimit -a


Hope this help some,
Hein.

[Ravi_8]

Hi

can you post output of "ulimit -a" on both machines

[Michael Schulte zur Sur]

Hi,

the two machines have a substantial difference in built in memory. There is a parameter that tells tru unix how much of a programme to hold in memory. With almost three times the memory size the es40 can hold more in memory.

greetings,

Michael

[Tom Wallin_1]

We are using RSS to compare. Attached is a text file(MS) with the ulimit -a from both machines.

Regards,

Tom Wallin

[Hein van den Heuvel]

Your STACK size seems unreasonable:

ES40 ulimit -a
:
stack(kbytes) 4,194,304

That's 4 GB of stack, where you used 2MB before. The app worked with the 2MB right? So it shoudl still work with that.
4GB of stack is a whole bunch of pagetable pages also!
If you do not have a very good reason for to have set it that high, then just fix the sysconfig proc entry for the stack and be happy.

Hein.

[Tom Wallin_1]

We decided yesterday to do as you suggested. But we are going to adjust the data setting also. Why did you focus in on the stack only? Also does the loader use these values to calculate how much memory to set aside when loaded into memory?

Tom Wallin

[Hein van den Heuvel]

>> Why did you focus in on the stack only?

a) Because I am in a BEA training with limited downtime :-).

b) Because that value is so clearly wrong (assuming you had a working system).
Typical sizes are 32M or so. If you need more (lots of local variables) then you wouls probably know.

c) I could imagine stack being different, as pages on either end will actually be touched.
'data' is just a fence. Just telling the system how far it can go, but you probably will not go there, so it does not matter if it is too far. However... if an application loses control, then it will not be stopped by this clean fence, but by some nasty resource depletion which my hurt other applications.

>> also does the loader use these values to calculate how much memory to set aside when loaded into memory.

Yes... but that is all 'virtual'. Just address ranges.

[Tom Wallin_1]

We changed the setting - per_proc_stack_size and restarted the server and started one of the programs and it was the same saize as before the change. We recompiled the program and restarted it no change.

The ulimit list of stack size did not change either.

What kernel variable should I be changing?

Tom Wallin

ps Thanks for your time.

[Michael Schulte zur Sur]

Tom,

could you post the output of the ps as Hein first suggested from both machines?

thanks,

Michael