On Thu, 13 Nov 2003, Eddie Bindt wrote: > > That said, Celeron is i686. > > yeah, can be. But I have 2 of these machines out of 200 non-celerons. And > both of the 2 machine run out of memory on RH9 ... > It seems that some non-visible process like internal cache is eating all > the mem ... After 2 or 3 days all mem is gone and I need to reboot ... > As configs on all machines are almost identical, I only can only suspect kernel or glibc ... > These are the only 2 i686 packages (and openssl) on that Celeron > machines.. No, this is just a memory leaking bug. L2 Cache manipulation isn't even managed by code as a general rule -- it is handled by the processor and chipset directly -- and a Celeron is pretty much the same core as a PIII but with a smaller L2. And the L2 size has nothing that I can think of to do with "eating memory" out in main memory, unless somebody has written an application that directly manipulates L2 (I'm not even sure this is POSSIBLE, mind you, but with assembler it may be). You need to use ps to figure out where all the memory is going. One of your processes PROBABLY will have a VSZ that grows, and grows, and grows with time. This process very likely has a malloc statement that isn't being matched with a free statement inside some loop (which may be very difficult to find, as it could be inside some linked-list manipulation library, in an XML application (it is easy as hell to leak in libxml), or MAYBE (one truly hopes not) in some kernel module. Oh, and then there are things like Open Office that may or may not technically "leak" memory, but they suck it up in 100 MB chunks just starting up (grrr). As I'm typing this response on a 320 MB Celeron laptop running RH 9 that basically never crashes and never runs out of memory (although it comes close, damn it, when OO runs) and have run all versions of RH on Celerons for years now with zero leak/stability problems, I really, seriously doubt that the kernel or glibc itself seriously leak, although particular snapshots or particular hardware device drivers can always provide an exception. > Since I manually installed an i386 kernel and glibc, problems seem to be > less. But not gone :-( > > Anyway, forcing someting like arch=i386 in yum.conf would help ... Wrong solution. First look for a leak as above. I'd be a nickel that you find it there. If you CAN'T find a leaking application, and can at all carefully reproduce the problem (especially on a stripped system -- e.g. one that runs the kernel and perhaps a single memory-tester application) leading to out of memory and oops or other crash, report it to the kernel list. Oh, and look for bug reports for YOUR PARTICULAR motherboard and chipset -- I should have mentioned that one exception to the rule of kernel stability is outlyier hardware that doesn't get as tested and particular BIOS revisions and particular (broken) motherboard/chipset combinations. rgb -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
