Обсуждение: Issue with Linux+Pentium SMP Context Switching
Folks, I brought up this issue a couple of weeks ago on the Performance list. Since then, I've gotten e-mail confirmation from a few other users seeing this problem. Here's the shape of the problem, we just don't know what causes it. I've been trying to do some profiling, but since I only have production systems to work with it's been really slow -- I have to wait for weekly downtime for each test. I'm hoping that someone with a greater knowledge of Linux Kernel internals and a good test machine can help out. Linux Versions Reported: RH and Gentoo reported, Kernels 2.4.18 to 2.4.22Not tested on other distros/kernels. Kernels areSMP-enabled. Hardware: Intel Pentium III and 4 dual-processor systems. 5 of the 6 reported machines are made by Dell; the other is ahome-build. Demonstrated on both hyper-threaded and non-hyperthreaded Xeons; Cannot be reproduced on Athalons. Description of the Problem: When a query is made against a table with millions of rows that requires a seq scan, large hash join, per-row calculations or other intensive operation, the system climbs to tens or hundreds of thousands of context switches per second (contrast with, for example, 5000cs/second on AthalonMP). This hurts performance significantly, possibly up to doubling query execution time.Initial debug logging of a test on one Xeon systemdemonstrating this issue showed a very large number of unattributed semop() calls. We are still following up on this. In discussions with Linux kernel hackers online, they blame the way that PostgreSQL uses shared memory. Whether or not they are correct, the effect of the issue is to harm PostgreSQL's performance and make us look bad on one of the major "enterprise" systems of choice: the multi-processor Xeon system. Ideas, anyone? -- Josh Berkus Aglio Database Solutions San Francisco
On Fri, Dec 19, 2003 at 10:30:13AM -0800, Josh Berkus wrote: > > Linux Versions Reported: RH and Gentoo reported, Kernels 2.4.18 to 2.4.22 > Not tested on other distros/kernels. Kernels are SMP-enabled. Does the same problem show with an SMP kernel on an UP system? > When a query is made against a table with millions of rows that requires a > seq scan, large hash join, per-row calculations or other intensive operation, > the system climbs to tens or hundreds of thousands of context switches per > second (contrast with, for example, 5000cs/second on AthalonMP). This is without any other query running, right? I even find 5000 cs/s rather large if there isn't any other process that wants some CPU. > In discussions with Linux kernel hackers online, they blame the way that > PostgreSQL uses shared memory. To me this can only make sense in case there is an other backend trying to use the same memory, and it needs to be moved from 1 CPU to an other. Kurt
Kurt, > This is without any other query running, right? I even find 5000 > cs/s rather large if there isn't any other process that wants > some CPU. Sorry! Darn! Important fact left out of the problem description: The issue happens when *two or more* intensive queries are running simultaneosly. > To me this can only make sense in case there is an other backend > trying to use the same memory, and it needs to be moved from 1 > CPU to an other. Yes. See above. -- Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus wrote:
> Initial debug logging of a test on one Xeon system demonstrating this issue
>showed a very large number of unattributed semop() calls. We are still
>following up on this.
>
Postgres has it's own user space spinlock and semaphore implementation.
Both fall back to semop if there is contention.
Hmm. You wrote that the problem is Xeon specific, and that AthlonMP are
unaffected. Perhaps Xeon cpus do not like the s_lock implementation? It
doesn't follow Intel's recommentations:
- no pause instructions.
- always TAS. The recommended approach is nonatomic tests until the
value is 0, then an atomic TAS.
Attached is a gross hack that adds pause instructions. If this doesn't
magically fix your problem, then we must figure out what causes the
semop calls, and avoid them.
Could you ask your Linux hackers why they blame the shared memory
implementation in postgres? I don't see any link between shared memory
and lock contention.
--
Manfred
Index: backend/storage/lmgr/s_lock.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/backend/storage/lmgr/s_lock.c,v
retrieving revision 1.16
diff -c -r1.16 s_lock.c
*** backend/storage/lmgr/s_lock.c 8 Aug 2003 21:42:00 -0000 1.16
--- backend/storage/lmgr/s_lock.c 19 Dec 2003 20:01:33 -0000
***************
*** 111,116 ****
--- 111,117 ----
spins = 0;
}
+ __asm__ __volatile__("rep;nop\n": : : "memory");
}
}
On Fri, Dec 19, 2003 at 11:17:31AM -0800, Josh Berkus wrote: > > Important fact left out of the problem description: The issue happens when > *two or more* intensive queries are running simultaneosly. So two queries are enough to get this problem? I assume the tables are so big that they don't fit in shared memory and it needs to go read in the data? So that the problem only shows itself when it needs to replace buffers? If it doesn't have to go read, do you still have the problem? Kurt
On Saturday 20 December 2003 00:00, Josh Berkus wrote: > In discussions with Linux kernel hackers online, they blame the way that > PostgreSQL uses shared memory. Whether or not they are correct, the > effect of the issue is to harm PostgreSQL's performance and make us look > bad on one of the major "enterprise" systems of choice: the multi-processor > Xeon system. Two suggestions.. 1. Patch linux kernel for HT aware scheduler. 2. Try running Xeons in HTdisabled modes. See if that helps. I would say using 2.6 on it is recommended anyways.. If possible of course.. Shridhar
<br /><blockquote cite="mid200312201220.08675.shridhar_daithankar@myrealbox.com" type="cite"><pre wrap="">Two suggestions.. 1. Patch linux kernel for HT aware scheduler. 2. Try running Xeons in HTdisabled modes. See if that helps. I would say using 2.6 on it is recommended anyways.. If possible of course.. </pre></blockquote> I would avoid 2.6 on a production machine. 2.6 breaks alot (not as in a bad thing, but as in not reallycompatible with) of things. Wait until distribution vendors<br /> are shipping production with it.<br /><br /> Sincerely,<br/><br /> Joshua Drake<br /><br /><br /><br /><blockquote cite="mid200312201220.08675.shridhar_daithankar@myrealbox.com"type="cite"><pre wrap=""> Shridhar ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster </pre></blockquote><br /><br /><pre class="moz-signature" cols="72">-- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - <a class="moz-txt-link-abbreviated" href="mailto:jd@commandprompt.com">jd@commandprompt.com</a> - <a class="moz-txt-link-freetext"href="http://www.commandprompt.com">http://www.commandprompt.com</a> Editor-N-Chief - PostgreSQl.Org - <a class="moz-txt-link-freetext" href="http://www.postgresql.org">http://www.postgresql.org</a></pre>