From: Bron Gondwana <brong@fastmail.fm> To: Christoph Lameter <cl@linux.com> Cc: Robert Mueller <robm@fastmail.fm>, Shaohua Li <shaohua.li@intel.com>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Bron Gondwana <brong@fastmail.fm>, linux-mm <linux-mm@kvack.org>, Mel Gorman <mel@csn.ul.ie> Subject: Re: Default zone_reclaim_mode = 1 on NUMA kernel is bad for file/email/web servers Date: Sat, 18 Sep 2010 00:09:16 +1000 [thread overview] Message-ID: <20100917140916.GA8474@brong.net> (raw) In-Reply-To: <alpine.DEB.2.00.1009170851200.11900@router.home> On Fri, Sep 17, 2010 at 08:56:06AM -0500, Christoph Lameter wrote: > On Fri, 17 Sep 2010, Robert Mueller wrote: > > > > > I don't think this is any fault of how the software works. It's a > > > > *very* standard "pre-fork child processes, allocate incoming > > > > connections to a child process, open and mmap one or more files to > > > > read data from them". That's not exactly a weird programming model, > > > > and it's bad that the kernel is handling that case very badly with > > > > everything default. > > > > > > maybe you incoming connection always happen on one CPU and you do the > > > page allocation in that cpu, so some nodes use out of memory but > > > others have a lot free. Try bind the child process to different nodes > > > might help. > > > > There's are 5000+ child processes (it's a cyrus IMAP server). Neither > > the parent of any of the children are bound to any particular CPU. It > > uses a standard fcntl lock to make sure only one spare child at a time > > calls accept(). I don't think that's the problem. > > From the first look that seems to be the problem. You do not need to be > bound to a particular cpu, the scheduler will just leave a single process > on the same cpu by default. If you then allocate all memory only from this > process then you get the scenario that you described. Huh? Which bit of forking server makes you think one process is allocating lots of memory? They're opening and reading from files. Unless you're calling the kernel a "single process". > There should be multiple processes allocating memory from all processors > to take full advantage of fast local memory. If you cannot do that then > the only choice is to reduce performance by some sort of interleaving > either at the Bios or OS level. OS level interleaving only for this > particular application would be best because then the OS can at least > allocate its own data in memory local to the processors. In actual fact we're running 20 different Cyrus instances on this machine, each with its own config file and own master file. The only "parentage" they share is they were most likely started from a single bash shell at one point, because we start them up after the server is already running from a management script. So we're talking 20 Cyrus master processes, each of which forks off hundreds of imapd processes, each of which listens, opens mailboxes as required, reads and writes files. You can't seriously tell me that the scheduler is putting ALL THESE PROCESSES on a single CPU. Bron.
WARNING: multiple messages have this Message-ID (diff)
From: Bron Gondwana <brong@fastmail.fm> To: Christoph Lameter <cl@linux.com> Cc: Robert Mueller <robm@fastmail.fm>, Shaohua Li <shaohua.li@intel.com>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Bron Gondwana <brong@fastmail.fm>, linux-mm <linux-mm@kvack.org>, Mel Gorman <mel@csn.ul.ie> Subject: Re: Default zone_reclaim_mode = 1 on NUMA kernel is bad for file/email/web servers Date: Sat, 18 Sep 2010 00:09:16 +1000 [thread overview] Message-ID: <20100917140916.GA8474@brong.net> (raw) In-Reply-To: <alpine.DEB.2.00.1009170851200.11900@router.home> On Fri, Sep 17, 2010 at 08:56:06AM -0500, Christoph Lameter wrote: > On Fri, 17 Sep 2010, Robert Mueller wrote: > > > > > I don't think this is any fault of how the software works. It's a > > > > *very* standard "pre-fork child processes, allocate incoming > > > > connections to a child process, open and mmap one or more files to > > > > read data from them". That's not exactly a weird programming model, > > > > and it's bad that the kernel is handling that case very badly with > > > > everything default. > > > > > > maybe you incoming connection always happen on one CPU and you do the > > > page allocation in that cpu, so some nodes use out of memory but > > > others have a lot free. Try bind the child process to different nodes > > > might help. > > > > There's are 5000+ child processes (it's a cyrus IMAP server). Neither > > the parent of any of the children are bound to any particular CPU. It > > uses a standard fcntl lock to make sure only one spare child at a time > > calls accept(). I don't think that's the problem. > > From the first look that seems to be the problem. You do not need to be > bound to a particular cpu, the scheduler will just leave a single process > on the same cpu by default. If you then allocate all memory only from this > process then you get the scenario that you described. Huh? Which bit of forking server makes you think one process is allocating lots of memory? They're opening and reading from files. Unless you're calling the kernel a "single process". > There should be multiple processes allocating memory from all processors > to take full advantage of fast local memory. If you cannot do that then > the only choice is to reduce performance by some sort of interleaving > either at the Bios or OS level. OS level interleaving only for this > particular application would be best because then the OS can at least > allocate its own data in memory local to the processors. In actual fact we're running 20 different Cyrus instances on this machine, each with its own config file and own master file. The only "parentage" they share is they were most likely started from a single bash shell at one point, because we start them up after the server is already running from a management script. So we're talking 20 Cyrus master processes, each of which forks off hundreds of imapd processes, each of which listens, opens mailboxes as required, reads and writes files. You can't seriously tell me that the scheduler is putting ALL THESE PROCESSES on a single CPU. Bron. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-09-17 14:09 UTC|newest] Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-09-13 3:39 Default zone_reclaim_mode = 1 on NUMA kernel is bad for file/email/web servers Robert Mueller 2010-09-16 10:01 ` KOSAKI Motohiro 2010-09-16 10:01 ` KOSAKI Motohiro 2010-09-16 17:06 ` Christoph Lameter 2010-09-16 17:06 ` Christoph Lameter 2010-09-17 0:50 ` Robert Mueller 2010-09-17 0:50 ` Robert Mueller 2010-09-17 6:01 ` Shaohua Li 2010-09-17 6:01 ` Shaohua Li 2010-09-17 7:32 ` Robert Mueller 2010-09-17 7:32 ` Robert Mueller 2010-09-17 13:56 ` Christoph Lameter 2010-09-17 13:56 ` Christoph Lameter 2010-09-17 14:09 ` Bron Gondwana [this message] 2010-09-17 14:09 ` Bron Gondwana 2010-09-17 14:22 ` Christoph Lameter 2010-09-17 14:22 ` Christoph Lameter 2010-09-17 23:01 ` Bron Gondwana 2010-09-17 23:01 ` Bron Gondwana 2010-09-20 9:34 ` Mel Gorman 2010-09-20 9:34 ` Mel Gorman 2010-09-20 23:41 ` Default zone_reclaim_mode = 1 on NUMA kernel is bad forfile/email/web servers Rob Mueller 2010-09-20 23:41 ` Rob Mueller 2010-09-21 9:04 ` Mel Gorman 2010-09-21 9:04 ` Mel Gorman 2010-09-21 14:14 ` Christoph Lameter 2010-09-21 14:14 ` Christoph Lameter 2010-09-22 3:44 ` Rob Mueller 2010-09-22 3:44 ` Rob Mueller 2010-09-27 2:01 ` KOSAKI Motohiro 2010-09-27 2:01 ` KOSAKI Motohiro 2010-09-27 13:53 ` Christoph Lameter 2010-09-27 13:53 ` Christoph Lameter 2010-09-27 23:17 ` Robert Mueller 2010-09-27 23:17 ` Robert Mueller 2010-09-28 12:35 ` Christoph Lameter 2010-09-28 12:35 ` Christoph Lameter 2010-09-28 12:42 ` Bron Gondwana 2010-09-28 12:42 ` Bron Gondwana 2010-09-28 12:49 ` Christoph Lameter 2010-09-28 12:49 ` Christoph Lameter 2010-09-30 7:05 ` Andi Kleen 2010-09-30 7:05 ` Andi Kleen 2010-10-04 12:45 ` KOSAKI Motohiro 2010-10-04 12:45 ` KOSAKI Motohiro 2010-10-04 13:07 ` Christoph Lameter 2010-10-04 13:07 ` Christoph Lameter 2010-10-05 5:32 ` KOSAKI Motohiro 2010-10-05 5:32 ` KOSAKI Motohiro 2010-10-04 19:43 ` David Rientjes 2010-10-04 19:43 ` David Rientjes 2010-09-21 1:05 ` Default zone_reclaim_mode = 1 on NUMA kernel is bad for file/email/web servers KAMEZAWA Hiroyuki 2010-09-21 1:05 ` KAMEZAWA Hiroyuki 2010-09-27 2:04 ` KOSAKI Motohiro 2010-09-27 2:04 ` KOSAKI Motohiro 2010-09-27 2:06 ` KAMEZAWA Hiroyuki 2010-09-27 2:06 ` KAMEZAWA Hiroyuki 2010-09-23 11:44 ` Balbir Singh 2010-09-23 11:44 ` Balbir Singh 2010-09-30 8:38 ` Bron Gondwana 2010-09-30 8:38 ` Bron Gondwana
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20100917140916.GA8474@brong.net \ --to=brong@fastmail.fm \ --cc=cl@linux.com \ --cc=kosaki.motohiro@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mel@csn.ul.ie \ --cc=robm@fastmail.fm \ --cc=shaohua.li@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.