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
=?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
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
Пятница, 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
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_
-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
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
>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
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
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
>
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
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
Пятница, 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.
Пятница, 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
>>
>>
>>
>>
>> Пятница,
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
> 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
Пятница, 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 _
17 matches
Mail list logo
