On Fri, Jan 4, 2013 at 6:38 PM, nobody nowhere <devnull@xxxxxxx> wrote: > On Fri, Jan 4, 2013 at 6:07 PM, nobody nowhere <devnull@xxxxxxx> 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? -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
