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

2013-01-05 Thread nobody nowhere
> > [ all postgres processes seem to be pinned to CPU 14 ] > > I wonder whether this is a "benefit" of sched_autogroup_enabled? > > http://archives.postgresql.org/message-id/50e4aab1.9040...@optionshouse.com > > regards, tom lane Thanks Lane RHEL 5.x :( -- Sent via pgsq

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

2013-01-05 Thread nobody nowhere
Пятница, 4 января 2013, 18:53 -03:00 от Claudio Freire : >On Fri, Jan 4, 2013 at 6:38 PM, nobody nowhere < devn...@mail.ua > wrote: >> On Fri, Jan 4, 2013 at 6:07 PM, nobody nowhere < devn...@mail.ua > wrote: >>> 9092 postgres 16 0 4326m 41m 34m S 0.0 0.3 0:00.27 14 postgres: user >>> user_db

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

2013-01-04 Thread Tom Lane
=?UTF-8?B?bm9ib2R5IG5vd2hlcmU=?= writes: > [ all postgres processes seem to be pinned to CPU 14 ] I wonder whether this is a "benefit" of sched_autogroup_enabled? http://archives.postgresql.org/message-id/50e4aab1.9040...@optionshouse.com regards, tom lane -- Sent via

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

2013-01-04 Thread Claudio Freire
On Fri, Jan 4, 2013 at 6:38 PM, nobody nowhere wrote: > On Fri, Jan 4, 2013 at 6:07 PM, nobody nowhere 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

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

2013-01-04 Thread nobody nowhere
Пятница, 4 января 2013, 18:20 -03:00 от Claudio Freire : >On Fri, Jan 4, 2013 at 6:07 PM, nobody nowhere < devn...@mail.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

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

2013-01-04 Thread Claudio Freire
On Fri, Jan 4, 2013 at 6:07 PM, nobody nowhere 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 45

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

2013-01-04 Thread nobody nowhere
>Oh... and you can also tell top to show the "last used processor". I >guess I should have said this first ;-) Even if do not fix it, I'll know a new feature of top :) Certainly sure 14 CPU  Total DISK READ: top - 21:54:38 up 453 days, 23:34, 1 user, load average: 0.56, 0.55, 0.48 Tasks: 429

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

2013-01-04 Thread Claudio Freire
On Fri, Jan 4, 2013 at 3:38 PM, nobody nowhere wrote: > > An unfiltered top or ps might give you a clue. You could also try > > Look at letter on the topic start. It's filtered by -u postgres, so you can't see apache there. > iotop, php does hit the filesystem (sessions stored in disk), and if >

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

2013-01-04 Thread Claudio Freire
On Fri, Jan 4, 2013 at 1:23 PM, nobody nowhere wrote: > > ...have you checked which PID is using that core? Is it postgres-related? > > How do I know it? An unfiltered top or ps might give you a clue. You could also try iotop, php does hit the filesystem (sessions stored in disk), and if it's on

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

2013-01-04 Thread nobody nowhere
Пятница, 4 января 2013, 11:52 -03:00 от Claudio Freire : >On Fri, Jan 4, 2013 at 11:41 AM, nobody nowhere < devn...@mail.ua > wrote: >> So how many concurrent users are accessing this db? pgsql assigns one >> process on one core so to speak. It can't spread load for one user >> over all cores.

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

2013-01-04 Thread nobody nowhere
Пятница, 4 января 2013, 9:47 -05:00 от Charles Gomes : > >> From: devn...@mail.ua >> To: pgsql-performance@postgresql.org >> Subject: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database >> Date: Fri, 4 Jan 2013 18:41:25 +0400

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

2013-01-04 Thread Claudio Freire
On Fri, Jan 4, 2013 at 11:41 AM, nobody nowhere wrote: > So how many concurrent users are accessing this db? pgsql assigns one > process on one core so to speak. It can't spread load for one user > over all cores. > > 64 php Fast-cgi processes over the Unix socket and about 20-30 over tcp I guess

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

2013-01-04 Thread Charles Gomes
> From: devn...@mail.ua > To: pgsql-performance@postgresql.org > Subject: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database > Date: Fri, 4 Jan 2013 18:41:25 +0400 > > > > > Пятница, 4 января 2013, 0:42 -07:00 от Sc

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

2013-01-04 Thread nobody nowhere
Пятница, 4 января 2013, 0:42 -07:00 от Scott Marlowe : >On Thu, Jan 3, 2013 at 4:45 PM, nobody nowhere < devn...@mail.ua > wrote: >> Centos 5.X kernel 2.6.18-274 >> pgsql-9.1 from pgdg-91-centos.repo >> relatively small database 3.2Gb >> Lot of insert, update, delete. >> >> I see non balanced _

Re: [PERFORM] SMP on a heavy loaded database

2013-01-03 Thread Scott Marlowe
On Thu, Jan 3, 2013 at 4:45 PM, nobody nowhere wrote: > Centos 5.X kernel 2.6.18-274 > pgsql-9.1 from pgdg-91-centos.repo > relatively small database 3.2Gb > Lot of insert, update, delete. > > I see non balanced _User_ usage on 14 CPU, exclusively assigned to the > hardware raid controller. > Wha

[PERFORM] SMP on a heavy loaded database

2013-01-03 Thread nobody nowhere
Centos 5.X kernel 2.6.18-274 pgsql-9.1 from pgdg-91-centos.repo relatively small database 3.2Gb Lot of insert, update, delete. I see non balanced _User_ usage on 14 CPU, exclusively assigned to the hardware raid controller. What I'm doing wrong, and is it possible somehow to fix? Thanks in advan