We have noticed this behavior when doing multiple large sequential copies. It locks up the system. ------------------ Marvin Blackburn Systems Administrator Glen Raven "He's no failure. He's not dead yet" --William Lloyd George > -----Original Message----- > From: redhat-list-admin@xxxxxxxxxx > [mailto:redhat-list-admin@xxxxxxxxxx]On Behalf Of Marcel > Sent: Tuesday, October 21, 2003 8:52 AM > To: redhat-list@xxxxxxxxxx > Subject: Re: Physical Memory is beeing filled (RH7.1) > > > Hi! > > Thank you for your postings. I tried to change the bdflush > parameters, but > with no difference in the behaviour of Linux. > I attached a file where I simulated my problem. There you see > the memory > status after different actions as well as a "ps -ef". > Could it be that this is a "normal" behavior of Linux? > > Thanks a lot! > Marcel > > > >> > Marcel, > >> > > >> > Your problem sounds like the Cache Swap bug: > >> > > >> >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89226#c15 > >> > > >> >Try doing the following: > >> > > >> >From the command line (as root) type: > >> > > >> >/sbin/sysctl -w vm.bdflush="30 500 0 0 2560 15360 60 20 0" > >> > > >> >Then edit your /etc/sysctl.conf file and add the following line: > >> > > >> >vm.bdflush="30 500 0 0 2560 15360 60 20 0" > >> > >> We have been experiencing similar issues on our web server, whereby > >> sudden swap usage spikes basically bring the server to a > halt. While the > >> blame has been placed on high traffic by those helping to > >> troubleshooting the problem, I have felt that there was > something else > >> going on, since most of the crashes we have experienced > have actually > >> been random, often at low peak times, and the symptoms are nearly > >> identical to those documented in the bug report. While > granted our web > >> traffic has been increasing steadily over the past few months, the > >> beginning of our crash problems was quite sudden, starting after we > >> migrated from RH 7.1 to 7.3 and then updated the kernel. > It has been > >> extremely difficult to pinpoint the issue since there are > virtual no > >> errors logged when this occurs, and there seems to be > little to go on by > >> way of finding a common denominator between the incidents. > >> > >> A 'uname -a ; cat /proc/sys/vm/bdflush' returns: > >> > >> Linux server1.myserver.net 2.4.20-20.7smp #1 SMP Mon Aug > 18 14:46:14 EDT > >> 2003 i686 unknown > >> 30 500 0 0 500 3000 60 20 0 > >> > >> A couple questions, first - all of the comments regarding this bug > >> appeared to reference RH9. Does the same apply to RH 7.3? > > > > Yes, this is a *kernel* issue, so whatever version of RH > you're using, if > > you'v updated teh kernel, you can be susceptible. In fact, > in comment #15, > > another user mentions that they started seeing this issue > in RH 7.3 after > > they also updated their kernel. > > > >> Second, what > >> exactly do these bdflush figures represent, and how does > the recommended > >> edit change the behavior of the system. Needless to say I > am desperate > >> for a solution, but I am reluctant to make any changes without > >> understanding the potential effect on the system as a whole. > > > > As I understand it, the bdflush parameters deal with when > the kernel flushes > > cache to disk and how it deals with virtual memory. I > haven't dug deeply > > into it, as the options I detailed in my previous post have > worked just > > dandy on our web server. > > > > Nevertheless, a google on "bdflush parameters" pulled up many hits, > > including: > > http://www.faqs.org/docs/securing/chap6sec68.html > > > https://listman.redhat.com/archives/ext3-users/2003-May/msg00035.html > > > https://listman.redhat.com/archives/ext3-users/2002-November/m sg00073.html > > and many others. > > Ben -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
