home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ogicse!uwm.edu!caen!sdd.hp.com!col.hp.com!fc.hp.com!jk
- From: jk@fc.hp.com
- (John Kessenich)
- Newsgroups: comp.sys.hp
- Subject: Re: HP 7xx problem with virtual memory (thrashing)
- Message-ID: <C0G15G.K0A@fc.hp.com>
- Date: 6 Jan 93 17:41:40 GMT
- Article-I.D.: fc.C0G15G.K0A
- References: <1993Jan5.194958.10898@alchemy.chem.utoronto.ca>
- Sender: news@fc.hp.com (news daemon)
- Distribution: comp.sys.hp
- Organization: Hewlett-Packard Workstation Kernel, Ft. Collins, CO
- Lines: 27
- X-Newsreader: TIN [version 1.1.1 PL6]
-
- System Admin (Mike Peterson) (system@alchemy.chem.utoronto.ca) wrote:
-
- : Some added data: after boot, and for several days, the system would
- : report that about 60 MB of our 128 MB was "free". After that, the "free"
- : memory would decline slowly, until the system would become useless
- : when about 5 MB or less was free. The number of processes remained more
- : or less the same (i.e. not a huge number of defunct/zombies eating
- : memory), and no task would show more "SIZE" than it would when the
- : system was booted. It seems there is a black hole for memory;
-
- I agree that this points to a system memory leak. If you're seeing this
- problem with s700 8.0*, 9.0* may solve the problem. If you see this
- problem with 9.0*, you should report it through the official channels.
-
- A problem like this can potentially dramatically reduce paging
- performance. (Some types of memory leaks reduce the amount of physical
- memory available for normal processes to run in, some types don't.)
-
- : we have
- : one program which may not be well-behaved about returning malloc'ed
- : memory, but the system MUST recover all such memory when the process
- : dies no matter how screwed up the process becomes.
-
- Correct.
-
- --------------
- John Kessenich
-