Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 12B9D1337BD6 for ; Thu, 14 Apr 2011 01:23:54 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 93383-10 for ; Thu, 14 Apr 2011 04:23:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.postgresql.org (Postfix) with ESMTP id 217911337B80 for ; Thu, 14 Apr 2011 01:23:45 -0300 (ADT) Received: from [75.208.32.253] (253.sub-75-208-32.myvzw.com [75.208.32.253]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MTMxT-1QHXfz3Tjb-00S0sQ; Thu, 14 Apr 2011 06:23:40 +0200 Message-ID: <4DA676BB.4050501@2ndquadrant.com> Date: Wed, 13 Apr 2011 21:23:23 -0700 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Scott Carey CC: Glyn Astill , Kevin Grittner , "david@lang.hm" , Steve Clark , "Joshua D. Drake" , Scott Marlowe , "pgsql-performance@postgresql.org" Subject: Re: Linux: more cores = less concurrency. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:rqb4v+6ygYxE8EGmgkBKA+rh4ugjsDJj1z98jTD0hjz ZDVcRRFzoRJUYZTo2AHjzS+O+Ljqp7oJAVyA8/o/UHcms8v/Xp mwUIgJnZczEwYiDAMElimI0kKLLZmqwvgHNLNSWg7KmX4xgGvn lHk4ZgO43aORDyGUs7KerosZEro6SbMOiF4J/vbdI1a4JShk7l X61Q2KJD311lwHgHEkB4Ssk9VpKqt5Kqag9mIFXutg= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201104/208 X-Sequence-Number: 43270 Scott Carey wrote: > If postgres is memory bandwidth constrained, what can be done to reduce > its bandwidth use? > > Huge Pages could help some, by reducing page table lookups and making > overall access more efficient. > Compressed pages (speedy / lzo) in memory can help trade CPU cycles for > memory usage for certain memory segments/pages -- this could potentially > save a lot of I/O too if more pages fit in RAM as a result, and also make > caches more effective. > The problem with a lot of these ideas is that they trade the memory problem for increased disruption to the CPU L1 and L2 caches. I don't know how much that moves the bottleneck forward. And not every workload is memory constrained, either, so those that aren't might suffer from the same optimizations that help in this situation. I just posted my slides from my MySQL conference talk today at http://projects.2ndquadrant.com/talks , and those include some graphs of recent data collected with stream-scaling. The current situation is really strange in both Intel and AMD's memory architectures. I'm even seeing situations where lightly loaded big servers are actually outperformed by small ones running the same workload. The 32 and 48 core systems using server-class DDR3/1333 just don't have the bandwidth to a single core that, say, an i7 desktop using triple-channel DDR3-1600 does. The trade-offs here are extremely hardware and workload dependent, and it's very easy to tune for one combination while slowing another. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books