wjw@ebs.eb.ele.tue.nl (Willem Jan Withagen) (02/05/91)
Hi,
Again I have this curiosity:
Running ps axu on my sr10.3 system gives (some of it):
USER PID SZ RSS TTY STAT TIME COMMAND
root 100 512 136 ? R 17:44 /etc/tcpd -c
root 105 512 64 ? S 0:13 /etc/syslogd
root 108 512 68 ? S 1:16 /etc/routed -f
root 124 256 0 ? S 0:00 /etc/ncs/llbd
user 135 256 40 ? S 0:10 /sys/spm/spm
user 137 256 0 ? S 0:00 /etc/writed
user 141 512 8 ? S 0:10 /sys/mbx/mbx_helper
root 144 768 224 ? S < 3:54 /etc/Xapollo -K /usr/X11/lib/keyboard/keyboard.config -D1 s+r-
wees 146 768 760 ? S < 30:26 dm
wjw 8113 512 148 ttyp0 R 0:02 -csh
wjw 8297 512 236 ttyp0 R 0:00 ps -axu
Whilest running it on sr10.2 gives:
USER PID SZ RSS TTY STAT TIME COMMAND
root 92 1856 80 ? S 23:12 [ tcpd ]
root 98 2048 34 ? S 0:20 [ syslogd ]
root 101 1888 31 ? S 2:04 [ routed ]
root 118 2080 28 ? S 0:04 [ llbd ]
user 142 704 12 ? S 0:24 [ spm ]
user 149 896 4 ? S 0:02 [ mbx_helper ]
user 152 704 0 ? S 0:00 [ writed ]
root 157 3104 394 ? S < 0:14 [ Xapollo ]
sys_pers 159 2560 728 ? S < 54:33 [ dm ]
kruytzer 14661 672 119 remote S 0:02 [ csh ]
(Note: that this is a 'ps axu //remote_node')
The problem is the size of every process. All processes on sr10.3 are
significantly smaller. Since this is a trent which goes upstream, I wonder
if sr10.3 has started using a different way of measuring process sizes.
Very few processes ever get really big. I had a dde session of a fairly large
program, and it claimed to be 1.5Mb, which is really peanuts when compared
to the >12Mb it takes on sr10.2 :-)
If that's the case, how do I find out what the virt. mem. size of a process
really is on sr10.3?
If the sizes are really correct, well done!
Could anybody (from Hapollo) shed some light on this?
Thanx,
Willem Jan Withagen.
PS: I've got several replies to my ELM question:
It's simple:
You just get it by ftp (anywhere near you)
Run Configure and answer most questions default.
Make and Install it.
Use it. :-)
Note that you may want to get Patchlevel 11, since supposedly there are
some Apollo specifics in this patch. (I'm now runnning PL8 just fine.)
Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl
Digital Systems Group, Room EH 10.10
P.O. 513 Tel: +31-40-473401
5600 MB Eindhoven The Netherlandshanche@imf.unit.no (Harald Hanche-Olsen) (02/06/91)
In article <1082@eba.eb.ele.tue.nl> wjw@ebs.eb.ele.tue.nl (Willem Jan Withagen) writes:
Again I have this curiosity:
Running ps axu on my sr10.3 system gives (some of it):
USER PID SZ RSS TTY STAT TIME COMMAND
root 100 512 136 ? R 17:44 /etc/tcpd -c
root 105 512 64 ? S 0:13 /etc/syslogd
root 108 512 68 ? S 1:16 /etc/routed -f
root 124 256 0 ? S 0:00 /etc/ncs/llbd
user 135 256 40 ? S 0:10 /sys/spm/spm
user 137 256 0 ? S 0:00 /etc/writed
user 141 512 8 ? S 0:10 /sys/mbx/mbx_helper
wjw 8113 512 148 ttyp0 R 0:02 -csh
wjw 8297 512 236 ttyp0 R 0:00 ps -axu
Hmm... Trying it on our sr10.3 DN10000 I get:
USER PID SZ RSS TTY STAT TIME COMMAND
root 1046 5632 568 ? S 259:21 /etc/tcpd
root 105210240 264 ? S 2:42 /etc/syslogd
root 1068 5632 76 ? S 0:11 /etc/ncs/llbd -li dds
user 1093 6656 188 ? S 0:54 /sys/spm/spm
user 1095 6144 24 ? S 0:00 /etc/writed
user 1100 4608 52 ? S 0:01 /sys/mbx/mbx_helper
hanche 15117 6656 160 ttyp6 S 0:01 -csh
hanche 17711 7168 808 ttyp6 R 0:00 ps augx
The sizes given are so impossibly huge I have never trusted them.
Therefore, by implication, I have never trusted the ps sizes for the
m68k processes either. Maybe I am being unfair. If someone who knows
could post the appropriate conversion factors I would be grateful.
- Harald Hanche-Olsen <hanche@imf.unit.no>
Division of Mathematical Sciences
The Norwegian Institute of Technology
N-7034 Trondheim, NORWAYrees@pisa.ifs.umich.edu (Jim Rees) (02/07/91)
In article <HANCHE.91Feb5184146@hufsa.imf.unit.no>, hanche@imf.unit.no (Harald Hanche-Olsen) writes:
The sizes given are so impossibly huge I have never trusted them.
Therefore, by implication, I have never trusted the ps sizes for the
m68k processes either. Maybe I am being unfair. If someone who knows
could post the appropriate conversion factors I would be grateful.
The sizes reported by ps when there is a dn10000 involved are often a factor
of 4 too small or too large. This is because of the change in page size to
4k and inadequate testing. I haven't tried all the combinations to know
exactly what fails, and it seems to have changed at sr10.3. Sizes reported
by a m68k for m68k processes are correct.
Anyone care to submit an APR?krowitz@RICHTER.MIT.EDU (David Krowitz) (02/13/91)
The "size" column under the "ps" command includes not only the actual code of the application, but also the system libraries that are mapped into the application's address space. Domain/OS has roughly 4 Mb of global libraries that are mapped into all processes' address spaces. The /com/las (list address space) utility will show you what all is mapped into a particular process' address space. For those of you who do not have the Aegis environment loaded, you can use /usr/apollo/bin/las. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
rees@pisa.ifs.umich.edu (Jim Rees) (02/14/91)
In article <9102131424.AA16548@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes:
The "size" column under the "ps" command includes not only the
actual code of the application, but also the system libraries
that are mapped into the application's address space.
No, 'ps' only lists per-process address space. You can see this by running
it on a 68k Apollo and noticing that many processes are way less than 4 Mb.