jim@melpar.UUCP (J. Hopkins) (06/28/89)
I am trying to calculate the amount of RAM taken up by application
tasks in a SUN 4/260. My local SUN rep. told me to use pstat or ps.
Pstat reports sizes in "pages" which I believe are 8k bytes each.
There are two "size" fields one is SZ which is the executable image and
the other is the RSS which is the "real" size in RAM.
The result is that every task using sunview windows has an RSS of 1 Meg or
more and a SZ of a few hundred k bytes. Non-window tasks have more
reasonable sizes.
Questions:
1) Is there a better way to evaluate size than pstat and ps?
2) Is Sunview really a memory pig?
3) Where are shared library sizes accounted for?
Are they in each entry of a pstat?
(i.e. I'm adding them in multiple times)
4) How can I get an accurate RAM usage for each task?
5) How can I get the RAM taken up by shared libraries?
6) If there is enough physical RAM to hold the tasks will there
still be swapping?
7) What is vmstat telling me?
Any comments or solutions will be greatly appreciated.
Please send responses to uunet!melpar!jim.
Thankspb@idca.tds.PHILIPS.nl (Peter Brouwer) (06/29/89)
In article <210@melpar.UUCP> jim@melpar.UUCP (J. Hopkins) writes: > > > I am trying to calculate the amount of RAM taken up by application >tasks in a SUN 4/260. My local SUN rep. told me to use pstat or ps. >Pstat reports sizes in "pages" which I believe are 8k bytes each. Depends of the system, see the ctob macro in /usr/include/sysmacros on how to convert from clicks ( pages ) to bytes. >There are two "size" fields one is SZ which is the executable image and >the other is the RSS which is the "real" size in RAM. > > Questions: > 1) Is there a better way to evaluate size than pstat and ps? Write your own tool: If you have the source of ps available than you can use that as an example. You have to read the region structures to get the size of each item ( text, data, stack and so on ) . There may be more than one region for each for each type. The type can be found in p_type of the pregion of the process and in the region structure the field r_pgsz contains the size of the type and r_nvalid contains the number of pages currently in memory. Output looks like Kernel data usage for each process + system stack (= USIZE) = 8 k name text data stack shtext shdata shmem dmmem vpix sched 0 0| 0 0| 0 0| 0 0| 0 0| 0 0| 0 0 init 36 36| 16 16| 8 4| 0 0| 0 0| 0 0| 0 0 vhand 0 0| 0 0| 0 0| 0 0| 0 0| 0 0| 0 0 bdflush 0 0| 0 0| 0 0| 0 0| 0 0| 0 0| 0 0 getty 16 12| 8 8| 8 4| 20 20| 4 4| 0 0| 0 0 uugetty 28 28| 20 16| 8 4| 0 0| 0 0| 0 0| 0 0 ksh 104 104| 28 28| 8 4| 0 0| 0 0| 0 0| 0 0 cron 24 24| 20 20| 8 4| 20 20| 4 4| 0 0| 0 0 uugetty 28 28| 20 16| 8 4| 0 0| 0 0| 0 0| 0 0 pp 16 12| 36 36| 8 4| 20 20| 4 4| 0 0| 0 0 physmem 3712 Kbytes 928 pages freemem 1292 Kbytes 323 pages For comercial reasons I cannot post the source. > 3) Where are shared library sizes accounted for? > Are they in each entry of a pstat? > (i.e. I'm adding them in multiple times) Text of shared libraries are to be accounted for once and its data for each user. > 4) How can I get an accurate RAM usage for each task? I use the above described tool. > 6) If there is enough physical RAM to hold the tasks will there > still be swapping? Depends on the low water mark of the vhand process, see GPGSLO in tuneable.h -- # Peter Brouwer, ## # Philips TDS, Dept SSP-V2 ## voice +31 55 432523 # P.O. Box 245 ## UUCP address ..!mcvax!philapd!pb # 7300 AE Apeldoorn, The Netherlands ## Internet pb@idca.tds.philips.nl