home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / hp / 14518 < prev    next >
Encoding:
Text File  |  1993-01-05  |  2.1 KB  |  37 lines
  1. Newsgroups: comp.sys.hp
  2. Path: sparky!uunet!utcsri!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
  3. From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
  4. Subject: Re: HP 7xx problem with virtual memory (thrashing)
  5. Message-ID: <1993Jan5.194958.10898@alchemy.chem.utoronto.ca>
  6. Organization: University of Toronto Chemistry Department
  7. References: <1993Jan3.034944.3556@alchemy.chem.utoronto.ca> <C0E6xu.E77@fc.hp.com>
  8. Distribution: comp.sys.hp
  9. Date: Tue, 5 Jan 1993 19:49:58 GMT
  10. Lines: 25
  11.  
  12. In article <C0E6xu.E77@fc.hp.com> jk@fc.hp.com (John Kessenich) writes:
  13. >    That the system thrashes means the amount of memory the CPU touches in a
  14. >    short amount of time is larger than the amount of physical memory
  15. >    available.  The main variables are the amount of available memory (less
  16. >    means more thrashing), the speed of the CPU (faster means more
  17. >    thrashing), the size of the process (smaller means less thrashing),
  18. >    speed of paging devices (faster/more discs means less thrashing), and
  19. >    the access pattern of the process (more locality means less thrashing).
  20. >    These will vary considerably from system to system, and knowing which
  21. >    one changes when performance changes requires some work.
  22.  
  23. Some added data: after boot, and for several days, the system would
  24. report that about 60 MB of our 128 MB was "free". After that, the "free"
  25. memory would decline slowly, until the system would become useless
  26. when about 5 MB or less was free. The number of processes remained more
  27. or less the same (i.e. not a huge number of defunct/zombies eating
  28. memory), and no task would show more "SIZE" than it would when the
  29. system was booted. It seems there is a black hole for memory; we have
  30. one program which may not be well-behaved about returning malloc'ed
  31. memory, but the system MUST recover all such memory when the process
  32. dies no matter how screwed up the process becomes.
  33. -- 
  34. core error - bus dumped    -*-    Mike Peterson, SysAdmin, U/Toronto Chemistry
  35.  *******   As usual, I speak only for me, myself and I; nobody else   *******
  36. E-mail: system@alchemy.chem.utoronto.ca  Tel: (416)978-7094  Fax: (416)978-8775
  37.