home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / sun / apps / 2451 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  1.4 KB
  1. Xref: sparky comp.sys.sun.apps:2451 comp.windows.x:19029 comp.unix.ultrix:8249 comp.unix.admin:6139
  2. Newsgroups: comp.sys.sun.apps,comp.windows.x,comp.unix.ultrix,comp.unix.admin
  3. Path: sparky!uunet!mnemosyne.cs.du.edu!nyx!ihastie
  4. From: ihastie@nyx.cs.du.edu (Ian Hastie)
  5. Subject: Re: Why is xload such a memory pig?
  6. Message-ID: <1992Nov12.023124.871@mnemosyne.cs.du.edu>
  7. Sender: usenet@mnemosyne.cs.du.edu (netnews admin account)
  8. Organization: University of Denver, Dept. of Math & Comp. Sci.
  9. References: <1992Nov11.223350.18090@leland.Stanford.EDU>
  10. Date: Thu, 12 Nov 92 02:31:24 GMT
  11. Lines: 16
  12.  
  13. mosedale@genome.stanford.edu (Dan Mosedale) writes:
  14.  
  15. >       F UID   PID  PPID CP PRI NI  SZ  RSS WCHAN    STAT TT  TIME COMMAND
  16. >200080011528  3219  3203  0   1  0 252  896 select   S    ?   0:01 xload -geome
  17. >200080011666  3263  3248  0   1  0 248  920 select   S    ?   0:01 xload -geome
  18. >200080011578  3640  3625  0   1  0 248  868 select   S    ?   0:01 xload -geome
  19. >200080012717  3694  3679  0   1  0 248  884 select   S    ?   0:00 xload -geome
  20.  
  21. OK... I may be being stupid here, but as far as I understand it a programs RSS
  22. should always be smaller than it's SZ.  At least surely it should not be bigger
  23. since this implies that the resident portion is bigger than the total size
  24. of the process.  Is there really something wierd going on or is it just that
  25. ps work differently on Suns in this respect from the way it does on DEC's
  26. boxes??
  27.  
  28. Ian.
  29.