Re: Re[2]: [PERFORM] SMP on a heavy loaded database

On Fri, Jan 4, 2013 at 6:38 PM, nobody nowhere <devnull(at)mail(dot)ua> wrote:
> On Fri, Jan 4, 2013 at 6:07 PM, nobody nowhere <devnull(at)mail(dot)ua> wrote:
>> 9092 postgres 16 0 4326m 41m 34m S 0.0 0.3 0:00.27 14 postgres: user
>> user_db [local] idle
>> 9098 postgres 16 0 4329m 203m 194m S 3.5 1.3 0:00.65 14 postgres: user
>> user_db [local] idle
>> 9099 postgres 16 0 4327m 45m 38m S 0.0 0.3 0:00.41 14 postgres: user
>> user_db [local] idle
>
> That looks like pg has been pinned to CPU14. I don't think it's pg's
> doing. All I can think of is: check scheduler tweaks, numa, and pg's
> initscript. Just in case it's being pinned explicitly.
>
> Not pinned.
> Forks with tcp connection use other CPU. I just add connections pool and
> change socket to tcp

How interesting. It must be a peculiarity of unix sockets. I know unix
sockets have close to no buffering, task-switching to the consumer
instead of buffering. Perhaps what you're experiencing here is this
"optimization" effect. It's probably not harmful at all. The OS will
switch to another CPU if the need arises.

Have you done any stress testing? Is there any actual performance impact?