PostgreSQL on SMP machines

Joey mailed lately just another announcement for the m68k port ermeeting. This year in Kiel from August 29th – 31st:

Executive summary:

2008 M68k Linux Porter Meeting
August 29th – 31st
University of Kiel, Germany

This summer we are organising a Linux porter meeting especially
targetting the m68k architecture. During the meeting current problems
of the m68k architecture, its integration in Debian, releases
etc. will be discussed.

The meeting will take place at the last weekend in August (29-31) at
the University of Kiel, Germany. Details and participants are
collected here:

This meeting is evolved from the Oldenburg porter meeting that has
started with the m68k architecture but had to stop two years ago.

Interested developers and supporters are invited to join the meeting
and help develop the m68k port of Linux.

If you are interested to attend this meeting, please drop Christian
(cts) or me a note or add yourself to the Wiki page.

Regards,

Joey

Despite all the problems the m68k faced in the last years, we’re still alive and performing fine. Part of the meeting will be discussion about the current changes of the m68k port like Aranym buildds and other stuff.

So, if you’re interested in the m68k port or the experience of the m68k porters for your embedded architecture, come to Kiel and visit us! 🙂

Uncategorized

6 thoughts on “PostgreSQL on SMP machines

  1. I don't see that this is a bug, since none of the CPUs appear to be reaching 100% busy. If some CPUs were completely busy and the others were not being used, that would be a bug.

    At a guess, the interrupt affinity of network interrupts is affecting which processes handle incoming requests. A network card that uses MSI-X can have multiple interrupts routed to multiple processors, but not necessarily all of them.

  2. Not a bug. The kernel is distributing the processes to the first package of each of the dual cores, either for cache affinity purposes, interrupt affinity as Ben pointed out, or simply because there isn't enough CPU activity to justify polluting the other cores.

    Any way you look at it, though, this is purely a kernel issue, not one with Postgres.

  3. Yes, I suspected the interrupts as well. Regarding CPU usage: neither via network nor via sockets, all CPUs/cores are 100% busy. Usually CPU load is about 25-50% per core.

  4. Well, that's what I already guessed, but just wanted to have confirmation. Anyway, it would be nice to have the kernel using all cores equally…

  5. Even if it means lower performance? The point I failed at making, I guess, is that a dual core chip isn't the same as having two processors — what happens on one can affect the other in odd ways, and it isn't always a win to spread load between both of them equally.

    OTOH, if you were to manage to get the cpu usage above 400%, then the kernel would likely oblige you, and spread the load to the idle cores…

  6. I'm not sure that it would mean lower performance. Do there exist comparisons between real Quad CPU setups and Quad Core systems somewhere?
    I'm more experience with multi CPU setups on SGIs under IRIX, though…

    Anyway, today I made a quick test with 2.6.18 instead of 2.6.25-2 and IIRC it performed better, but I really need to verify my memory tomorrow… 😉
    So, yes, it's apparently a kernel issue, not a postgresql one…

Comments are closed.