home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / hp / 14575 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  2.1 KB
  1. From: stroyan@hpfcso.FC.HP.COM (Mike Stroyan)
  2. Date: Wed, 6 Jan 1993 20:17:06 GMT
  3. Subject: Re: HP 7xx problem with virtual memory (thrashing)
  4. Message-ID: <7371514@hpfcso.FC.HP.COM>
  5. Organization: Hewlett-Packard, Fort Collins, CO, USA
  6. Path: sparky!uunet!paladin.american.edu!gatech!emory!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!hpscit.sc.hp.com!hplextra!hpfcso!stroyan
  7. Newsgroups: comp.sys.hp
  8. References: <1992Dec31.193847.6419@csi.com>
  9. Lines: 28
  10.  
  11. > Some added data: after boot, and for several days, the system would
  12. > report that about 60 MB of our 128 MB was "free". After that, the "free"
  13. > memory would decline slowly, until the system would become useless
  14. > when about 5 MB or less was free. The number of processes remained more
  15. > or less the same (i.e. not a huge number of defunct/zombies eating
  16. > memory), and no task would show more "SIZE" than it would when the
  17. > system was booted. It seems there is a black hole for memory; we have
  18. > one program which may not be well-behaved about returning malloc'ed
  19. > memory, but the system MUST recover all such memory when the process
  20. > dies no matter how screwed up the process becomes.
  21.  
  22. There is another possible way to use up swap space.  Shared memory
  23. segments also require swap space.  Since shared memory segments will
  24. survive the exit of their creating process, they can accumulate whenever
  25. a program fails to destroy segments that it creates.  The command
  26. "ipcs -mb" will list shared memory segments, their owners and their sizes.
  27. If you note segments accumulating over time you can ask the owners
  28. what kind of programs they are executing, and try to pin down the source.
  29.  
  30. Shared memory segments can be removed using "ipcrm", but it can be
  31. difficult to determine whether a shared memory segment is entirely
  32. unused.  A segment is in use if the "NATTCH" field reported by "ipcs -mo"
  33. is greater than 0.  An apparently unused segment might be left
  34. around intentionally to hold information for later executions of a
  35. program.  The only way to check for this is to check the documentation
  36. or the author of each program involved.
  37.  
  38. Mike Stroyan, mike_stroyan@fc.hp.com
  39.