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

Пятница, 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] Re[2]: [PERFORM] SMP on a heavy loaded database

> 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 от Scott Marlowe > : > On Thu, Jan

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

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

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

Пятница, 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 >> >> >> >> >> Пятница,

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

Пятница, 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.

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

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

Re: [PERFORM] Postgres delete performance problem

Hello, Just wondering whether you were able to resolve this issue. We are experiencing a very similar issue with deletes using Postgrs 9.0.5 on Ubuntu 12.04. Dan -- View this message in context: http://postgresql.1045698.n5.nabble.com/Postgres-delete-performance-problem-tp5714153p5738765.html

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

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] FW: performance issue with a 2.5gb joinded table

Heikki Linnakangas writes: > One difference is that numerics are stored more tightly packed on > Oracle. Which is particularly good for Oracle as they don't have other > numeric data types than number. On PostgreSQL, you'll want to use int4 > for ID-fields, where possible. An int4 always takes

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

>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

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

Re: [PERFORM] FW: performance issue with a 2.5gb joinded table

-Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Freitag, 4. Januar 2013 21:41 To: Heikki Linnakangas Cc: Daniel Westermann; 'pgsql-performance@postgresql.org' Subject: Re: [PERFORM] FW: performance issue with a 2.5gb joinded table Heikki Linnakangas writes: > One diff

[PERFORM] Partition table in 9.0.x?

Hi all, I have a table that has about 73mm rows in it and growing. Running 9.0.x on a server that unfortunately is a little I/O constrained. Some (maybe) pertinent settings: default_statistics_target = 50 maintenance_work_mem = 512MB constraint_exclusion = on effective_cache_size = 5GB work_

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

Пятница, 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

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

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

=?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] Partition table in 9.0.x?

On Friday, January 4, 2013, AJ Weber wrote: > Hi all, > > I have a table that has about 73mm rows in it and growing. How big is the table in MB? Its indexes? ... > > The server has 12GB RAM, 4 cores, but is shared with a big webapp running > in Tomcat -- and I only have a RAID1 disk to work