Re: high memory problems with imap
On Sat, 6 Dec 2003 12:16, Theodore Knab [EMAIL PROTECTED] wrote: I have a courier/postfix maildir IMAP mail server with 10GB of RAM. Occasionally, the memory gets all chewed up and it becomes unusable. I think it becoming unusable because of buffer bounces. However, the documentation tells me that the virtual memory allocation and bounce buffer problem was fixed in 2001. My experience is that the problem you describe was occurring in the latest 2.4.x kernels in late 2002 and early 2003. It is fixed in the Red Hat and SUSE kernel trees, at the time I had the problem I used a SUSE kernel to fix it. Today I would probably use a Red Hat kernel instead. For such things instead of trying to patch a Debian kernel source tree or a kernel.org tree I recommend taking a working and tested kernel source tree such as that from Red Hat (which also fixes other bugs that may affect you in future). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: high memory problems with imap
On Sat, 6 Dec 2003 22:36, [EMAIL PROTECTED] (Donovan Baarda) wrote: On Sat, Dec 06, 2003 at 06:19:23PM +1100, Russell Coker wrote: For such things instead of trying to patch a Debian kernel source tree or a kernel.org tree I recommend taking a working and tested kernel source tree such as that from Red Hat (which also fixes other bugs that may affect you in future). Man, that's sad... a Debian list having to recommend a RedHat kernel... Look on the bright side. At least you know that on a Debian list you'll get the best answer on technical merits. Producing a good kernel for serious server use is a lot of work. Red Hat has many good kernel coders working 40+ hours a week on back-porting code from 2.6, writing drivers for various unsupported hardware, and merging the best patches that float by the l-k list. There's no reason for Debian to try to reproduce this effort, the Red Hat kernel source is entirely GPL, there's no reason not to use it. I've been meaning to package it for Debian... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: high memory problems with imap
On Sat, Dec 06, 2003 at 06:19:23PM +1100, Russell Coker wrote: On Sat, 6 Dec 2003 12:16, Theodore Knab [EMAIL PROTECTED] wrote: [...] For such things instead of trying to patch a Debian kernel source tree or a kernel.org tree I recommend taking a working and tested kernel source tree such as that from Red Hat (which also fixes other bugs that may affect you in future). Man, that's sad... a Debian list having to recommend a RedHat kernel... -- Donovan Baardahttp://minkirri.apana.org.au/~abo/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: high memory problems with imap
Thanks, that sounds like a perfectly good way to solve the problem. I never thought to use another distro's kernel. I guess it does not really hurt anything to use the RedHat kernel on a Debian system. Actually, I forgot that RedHat has been making a big effort to create a kernel that would run high memory Oracle systems. Thus, RedHat probably has the most experienced kernel package developers for high memory support. Producing a good kernel for serious server use is a lot of work. Red Hat has many good kernel coders working 40+ hours a week on back-porting code from 2.6, writing drivers for various unsupported hardware, and merging the best patches that float by the l-k list. There's no reason for Debian to try to reproduce this effort, the Red Hat kernel source is entirely GPL, there's no reason not to use it. I've been meaning to package it for Debian... -- -- Ted Knab Chester, MD 21619 -- 940216d6021602a41607166696c656c202778696368602d65616e637 02940226c696e646c69702c6f667560256675627478696e67602a416 0716e6563756e2a0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: high memory problems with imap
On Sat, 6 Dec 2003 12:16, Theodore Knab [EMAIL PROTECTED] wrote: I have a courier/postfix maildir IMAP mail server with 10GB of RAM. Occasionally, the memory gets all chewed up and it becomes unusable. I think it becoming unusable because of buffer bounces. However, the documentation tells me that the virtual memory allocation and bounce buffer problem was fixed in 2001. My experience is that the problem you describe was occurring in the latest 2.4.x kernels in late 2002 and early 2003. It is fixed in the Red Hat and SUSE kernel trees, at the time I had the problem I used a SUSE kernel to fix it. Today I would probably use a Red Hat kernel instead. For such things instead of trying to patch a Debian kernel source tree or a kernel.org tree I recommend taking a working and tested kernel source tree such as that from Red Hat (which also fixes other bugs that may affect you in future). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: high memory problems with imap
On Sat, Dec 06, 2003 at 06:19:23PM +1100, Russell Coker wrote: On Sat, 6 Dec 2003 12:16, Theodore Knab [EMAIL PROTECTED] wrote: [...] For such things instead of trying to patch a Debian kernel source tree or a kernel.org tree I recommend taking a working and tested kernel source tree such as that from Red Hat (which also fixes other bugs that may affect you in future). Man, that's sad... a Debian list having to recommend a RedHat kernel... -- Donovan Baardahttp://minkirri.apana.org.au/~abo/
Re: high memory problems with imap
Thanks, that sounds like a perfectly good way to solve the problem. I never thought to use another distro's kernel. I guess it does not really hurt anything to use the RedHat kernel on a Debian system. Actually, I forgot that RedHat has been making a big effort to create a kernel that would run high memory Oracle systems. Thus, RedHat probably has the most experienced kernel package developers for high memory support. Producing a good kernel for serious server use is a lot of work. Red Hat has many good kernel coders working 40+ hours a week on back-porting code from 2.6, writing drivers for various unsupported hardware, and merging the best patches that float by the l-k list. There's no reason for Debian to try to reproduce this effort, the Red Hat kernel source is entirely GPL, there's no reason not to use it. I've been meaning to package it for Debian... -- -- Ted Knab Chester, MD 21619 -- 940216d6021602a41607166696c656c202778696368602d65616e637 02940226c696e646c69702c6f667560256675627478696e67602a416 0716e6563756e2a0
high memory problems with imap
What Debian Linux Kernel works best for High Memory ( 4GB) machines that are under heavy io loads ? I have a courier/postfix maildir IMAP mail server with 10GB of RAM. Occasionally, the memory gets all chewed up and it becomes unusable. I think it becoming unusable because of buffer bounces. However, the documentation tells me that the virtual memory allocation and bounce buffer problem was fixed in 2001. http://lwn.net/2001/0607/kernel.php3 Is anyone using high memory on servers with heavy loads ? I am running a 2.4.22 kernel on a machine with a 4GB. This machine is also under a heavy load as it servers up web-mail, but I have no problems with it. However things seem to turn experimental with more than than 4GB of RAM. -- -- Ted Knab Chester, MD 21619 -- 940216d6021602a41607166696c656c202778696368602d65616e637 02940226c696e646c69702c6f667560256675627478696e67602a416 0716e6563756e2a0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
