Claudio Freire wrote:
> Stephen Frost wrote:
>> Rajesh Kumar. Mallah (mal...@tradeindia.com) wrote:
>>> we are actually also running out db max connections (also)
>>> ( which is currently at 600) , when that happens something at
>>> the beginning of the application stack also gets dysfunctional
On Thu, May 24, 2012 at 2:09 PM, Stephen Frost wrote:
> * Rajesh Kumar. Mallah (mal...@tradeindia.com) wrote:
>> We are running linux with kernel 3.2.X
>> (which has the lseek improvements)
>
> Ah, good.
>
>> Thanks for the reference , even i thought so (LockManager) ,
>> but we are actually also
* Rajesh Kumar. Mallah (mal...@tradeindia.com) wrote:
> We are running linux with kernel 3.2.X
> (which has the lseek improvements)
Ah, good.
> Thanks for the reference , even i thought so (LockManager) ,
> but we are actually also running out db max connections (also)
> ( which is currently at
- "Stephen Frost" wrote:
| From: "Stephen Frost"
| To: "Rajesh Kumar. Mallah"
| Cc: pgsql-performance@postgresql.org
| Sent: Thursday, May 24, 2012 9:27:37 PM
| Subject: Re: [PERFORM] High load average in 64-core server , no I/O wait and
CPU is idle
|
| From: "Steve Crawford"
| To: "Rajesh Kumar. Mallah"
| Cc: "Andy Colson" , "Claudio Freire"
, pgsql-performance@postgresql.org
| Sent: Thursday, May 24, 2012 9:23:47 PM
| Subject: Re: [PERFORM] High load average in 64-core server , no I/O wait and
Rajesh,
* Rajesh Kumar. Mallah (mal...@tradeindia.com) wrote:
> We are puzzled why the CPU and DISK I/O system are not being utilized
> fully and would seek lists' wisdom on that.
What OS is this? What kernel version?
> just a thought, will it be a good idea to partition the host hardware
>
On 05/24/2012 05:58 AM, Rajesh Kumar. Mallah wrote:
Dear Andy ,
Following the discussion on load average we are now investigating on some
other parts of the stack (other than db).
Essentially we are bumping up the limits (on appserver) so that more requests
goes to the DB server.
Which leads
Dear Andy ,
Following the discussion on load average we are now investigating on some
other parts of the stack (other than db).
Essentially we are bumping up the limits (on appserver) so that more requests
goes to the DB server.
|
| Maybe you are hitting some locks? If its not IO and no
On 05/24/2012 12:26 AM, Rajesh Kumar. Mallah wrote:
- "Claudio Freire" wrote:
| From: "Claudio Freire"
| To: "Rajesh Kumar. Mallah"
| Cc: pgsql-performance@postgresql.org
| Sent: Thursday, May 24, 2012 9:23:43 AM
| Subject: Re: [PERFORM] High load average i
|
| Load avg is the number of processes in the running queue, which can
| be either waiting to be run or actually running.
|
| So if you had 100% CPU usage, then you'd most definitely have a load
| avg of 64, which is neither good or bad. It may simply mean that
| you're using your hardware's ful
On Thu, May 24, 2012 at 2:26 AM, Rajesh Kumar. Mallah
wrote:
> |
> | Load can easily get to 64 (1 per core) without reaching its capacity.
> | So, unless you're experiencing decreased performance I wouldn't think
> | much of it.
>
> I far as i understand ,
> Load Avg is the average number of proce
- "Claudio Freire" wrote:
| From: "Claudio Freire"
| To: "Rajesh Kumar. Mallah"
| Cc: pgsql-performance@postgresql.org
| Sent: Thursday, May 24, 2012 9:23:43 AM
| Subject: Re: [PERFORM] High load average in 64-core server , no I/O wait and
CPU is idle
|
| On
On Thu, May 24, 2012 at 12:39 AM, Rajesh Kumar. Mallah
wrote:
> The problem is that sometimes there are spikes of load avg which
> jumps to > 50 very rapidly ( ie from 0.5 to 50 within 10 secs) and
> it remains there for sometime and slowly reduces to normal value.
>
> During such times of high
Dear List ,
We are having scalability issues with a high end hardware
The hardware is
CPU = 4 * opteron 6272 with 16 cores ie Total = 64 cores.
RAM = 128 GB DDR3
Disk = High performance RAID10 with lots of 15K spindles and a working BBU
Cache.
normally the 1 min load average of the system
On Thu, Jan 27, 2011 at 6:36 AM, Michael Kohl wrote:
> Cédric, thanks a lot for your answer so far!
>
> On Thu, Jan 27, 2011 at 12:24 PM, Cédric Villemain
> wrote:
>
>> you have swap used, IO on the swap partition ?
>
> Memory-wise we are fine.
>
>> can you paste the /proc/meminfo ?
>
> Sure:
>
>
Michael Kohl wrote:
HDD: 2x 120 GB OCZ Vertex 2 SSD; RAID 1
As a general warning here, as far as I know the regular Vertex 2 SSD
doesn't cache writes properly for database use. It's possible to have a
crash that leaves the database corrupted, if the drive has writes queued
up in its cach
On Thu, Jan 27, 2011 at 5:31 AM, Michael Kohl wrote:
> we are running a fairly big Ruby on Rails application on Postgres 8.4.
> Our traffic grew quite a bit lately, and since then we are facing DB
> performance issues. System load occasionally explodes (around 170
> yesterday on a 16 core system),
On 27/01/2011 11:31, Michael Kohl wrote:
Hi all,
we are running a fairly big Ruby on Rails application on Postgres 8.4.
Our traffic grew quite a bit lately, and since then we are facing DB
performance issues. System load occasionally explodes (around 170
yesterday on a 16 core system), which see
Michael Kohl wrote:
We are already doing the logging part, we are just a bit behind on the
"explain analyze" part of things. One day soon...
There is, of course, the auto_explain module which will do that for you.
--
Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-
On Thu, Jan 27, 2011 at 6:05 PM, Scott Marlowe wrote:
> A good method to start is to log long running queries and then explain
> analyze just them.
We are already doing the logging part, we are just a bit behind on the
"explain analyze" part of things. One day soon...
Thanks,
Michael
--
Sent v
the
Acunote ´s Project Management Platform
http://blog.pluron.com
- Mensaje original -
De: "Andy Colson"
Para: "Michael Kohl"
CC: pgsql-performance@postgresql.org
Enviados: Jueves, 27 de Enero 2011 12:20:18 GMT -05:00 Región oriental EE.
UU./Canadá
Asunto: Re: [PER
On Thursday, January 27, 2011 07:13:17 PM Scott Marlowe wrote:
> On Thu, Jan 27, 2011 at 10:54 AM, Stephen Frost wrote:
> > * Michael Kohl (michael.k...@tupalo.com) wrote:
> >> HDD: 2x 120 GB OCZ Vertex 2 SSD; RAID 1
> >
> > I'm amazed no one else has mentioned this yet, but you should look into
On Thu, Jan 27, 2011 at 10:20 AM, Andy Colson wrote:
> On 1/27/2011 9:09 AM, Michael Kohl wrote:
>>
>> On Thu, Jan 27, 2011 at 4:06 PM, Andy Colson wrote:
>>>
>>> Have you run each of your queries through explain analyze lately?
>>
>> A code review including checking of queries is on our agenda.
On Thu, Jan 27, 2011 at 10:54 AM, Stephen Frost wrote:
> * Michael Kohl (michael.k...@tupalo.com) wrote:
>> HDD: 2x 120 GB OCZ Vertex 2 SSD; RAID 1
>
> I'm amazed no one else has mentioned this yet, but you should look into
> splitting your data and your WALs. Obviously, having another set of
> S
* Michael Kohl (michael.k...@tupalo.com) wrote:
> HDD: 2x 120 GB OCZ Vertex 2 SSD; RAID 1
I'm amazed no one else has mentioned this yet, but you should look into
splitting your data and your WALs. Obviously, having another set of
SSDs to put your WALs on would be ideal.
You should probably also
On 1/27/2011 9:09 AM, Michael Kohl wrote:
On Thu, Jan 27, 2011 at 4:06 PM, Andy Colson wrote:
Have you run each of your queries through explain analyze lately?
A code review including checking of queries is on our agenda.
You are vacuuming/autovacuuming, correct?
Sure :-)
Thank you,
Mich
On Thu, Jan 27, 2011 at 8:09 AM, Michael Kohl wrote:
> On Thu, Jan 27, 2011 at 4:06 PM, Andy Colson wrote:
>> Have you run each of your queries through explain analyze lately?
>
> A code review including checking of queries is on our agenda.
A good method to start is to log long running queries
On Thu, Jan 27, 2011 at 4:06 PM, Andy Colson wrote:
> Have you run each of your queries through explain analyze lately?
A code review including checking of queries is on our agenda.
> You are vacuuming/autovacuuming, correct?
Sure :-)
Thank you,
Michael
--
Sent via pgsql-performance mailing
On 1/27/2011 4:31 AM, Michael Kohl wrote:
Hi all,
we are running a fairly big Ruby on Rails application on Postgres 8.4.
Our traffic grew quite a bit lately, and since then we are facing DB
performance issues. System load occasionally explodes (around 170
yesterday on a 16 core system), which se
> Number of logical CPUs: 16 (4x Quadcore Xeon E5520 @ 2.27GHz)
> RAM: 16GB
> Concurrent connections (according to our monitoring tool): 7 (min), 74
> (avg), 197 (max)
Your current issue may be IO wait, but a connection pool isn't far off
in your future either.
> max_connections = 200
> work_mem
On Thursday, January 27, 2011 02:23:48 PM Cédric Villemain wrote:
> 2011/1/27 Andres Freund :
> > On Thursday, January 27, 2011 12:24:10 PM Cédric Villemain wrote:
> >> > maintenance_work_mem = 512MB
> >>
> >> 128MB is usualy enough
> >
> > Uhm, I don't want to be picky, but thats not really my e
2011/1/27 Andres Freund :
> On Thursday, January 27, 2011 12:24:10 PM Cédric Villemain wrote:
>> > maintenance_work_mem = 512MB
>> 128MB is usualy enough
> Uhm, I don't want to be picky, but thats not really my experience. Sorts for
> index creation are highly dependent on a high m_w_m. Quite regul
On Thu, Jan 27, 2011 at 1:30 PM, Justin Pitts wrote:
> That is a foot-gun waiting to go off.
Thanks, I had already changed this after Cedric's mail.
>> HDD: 2x 120 GB OCZ Vertex 2 SSD; RAID 1
>> random_page_cost = 2.0
> I thought these drives were a lot better at random IO than this gives
> them
On Thursday, January 27, 2011 12:24:10 PM Cédric Villemain wrote:
> > maintenance_work_mem = 512MB
> 128MB is usualy enough
Uhm, I don't want to be picky, but thats not really my experience. Sorts for
index creation are highly dependent on a high m_w_m. Quite regularly I find the
existing 1GB lim
2011/1/27 Michael Kohl :
> Cédric, thanks a lot for your answer so far!
>
> On Thu, Jan 27, 2011 at 12:24 PM, Cédric Villemain
> wrote:
>
>> you have swap used, IO on the swap partition ?
>
> Memory-wise we are fine.
>
>> can you paste the /proc/meminfo ?
>
> Sure:
>
> # cat /proc/meminfo
> MemTot
Cédric, thanks a lot for your answer so far!
On Thu, Jan 27, 2011 at 12:24 PM, Cédric Villemain
wrote:
> you have swap used, IO on the swap partition ?
Memory-wise we are fine.
> can you paste the /proc/meminfo ?
Sure:
# cat /proc/meminfo
MemTotal: 16461012 kB
MemFree: 280440
2011/1/27 Michael Kohl :
> Hi all,
>
> we are running a fairly big Ruby on Rails application on Postgres 8.4.
> Our traffic grew quite a bit lately, and since then we are facing DB
> performance issues. System load occasionally explodes (around 170
> yesterday on a 16 core system), which seems to b
Hi all,
we are running a fairly big Ruby on Rails application on Postgres 8.4.
Our traffic grew quite a bit lately, and since then we are facing DB
performance issues. System load occasionally explodes (around 170
yesterday on a 16 core system), which seems to be caused by disk I/O
(iowait in our
sql-performance@postgresql.org
Subject: Re: [PERFORM] High Load on Postgres 7.4.16 Server
The problem with this is that it doesn't leverage shared buffers and
kernel buffers well.
Anyways, my bet is that your SAN isn't performing as you expect on
the new hardware.
Dave
On 5-Apr-07, at 4:13 PM,
"John Allgood" <[EMAIL PROTECTED]> writes:
> ... The other configuration was RHEL3 and Postgres 7.4.13 and Redhat
> Cluster Suite. The application seemed to run much faster on the older
> equipment.
While I agree with the other comments that you should think about moving
to something newer than 7
TECTED] On Behalf Of Dave
Cramer
Sent: Thursday, April 05, 2007 4:01 PM
To: John Allgood
Cc: 'Jeff Frost'; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] High Load on Postgres 7.4.16 Server
On 5-Apr-07, at 3:33 PM, John Allgood wrote:
The hard thing about running multiple pos
Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dave Cramer
Sent: Thursday, April 05, 2007 4:01 PM
To: John Allgood
Cc: 'Jeff Frost'; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] High Load on Postgres 7.4.16 Server
On 5-Apr-07, at 3:33 PM, John All
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Frost
Sent: Thursday, April 05, 2007 3:24 PM
To: John Allgood
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] High Load on Postgres 7.4.16 Server
On Thu, 5 Apr 2007, John Allgood wrote:
Hello All
I sent
l 05, 2007 3:24 PM
To: John Allgood
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] High Load on Postgres 7.4.16 Server
On Thu, 5 Apr 2007, John Allgood wrote:
Hello All
I sent this message to the admin list and it never got through so I
am trying the performance list.
W
what about kernel buffers on RHEL4.
Thanks
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Frost
Sent: Thursday, April 05, 2007 3:24 PM
To: John Allgood
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] High Load on Postgres 7.4.16 Server
John Allgood wrote:
Hello All
I sent this message to the admin list and it never got through so I
am trying the performance list.
We moved our application to a new machine last night. It is a Dell
PowerEdge 6950 2X Dual Core. AMD Opteron 8214 2.2Ghz. 8GB Memory. Th
On Thu, 5 Apr 2007, John Allgood wrote:
Hello All
I sent this message to the admin list and it never got through so I
am trying the performance list.
We moved our application to a new machine last night. It is a Dell
PowerEdge 6950 2X Dual Core. AMD Opteron 8214 2.2Ghz. 8GB Memo
Hello All
I sent this message to the admin list and it never got through so I
am trying the performance list.
We moved our application to a new machine last night. It is a Dell
PowerEdge 6950 2X Dual Core. AMD Opteron 8214 2.2Ghz. 8GB Memory. The
machine is running R
;
> Thanks,
>
> Anjan
>
> _
>
> From: Woody Woodring [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 30, 2005 2:30 PM
> To: 'Rémy Beaumont'; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] High load and iowait but no disk access
>
>
?
Thanks,
Anjan
From: Woody Woodring
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 30, 2005
2:30 PM
To: 'Rémy Beaumont';
pgsql-performance@postgresql.org
Subject: Re: [PERFORM] High load
and iowait but no disk access
Have you tried a different kernel?
We run with a n
nt'; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] High load and iowait but no disk access
Have you tried a different kernel? We run with a netapp over NFS
without any issues, but we have seen high IO-wait on other Dell boxes
(running and not running postgres) and RHES 3. We
On 30-Aug-05, at 14:32, Josh Berkus wrote:
Remy,
The behavior we see is that when running queries that do random reads
on disk, IOWAIT goes over 80% and actual disk IO falls to a crawl at a
throughput bellow 3000kB/s (We usually average 4 kB/s to 8
kB/s
on sequential read operations
ehalf Of Rémy
BeaumontSent: Monday, August 29, 2005 9:43 AMTo:
pgsql-performance@postgresql.orgSubject: [PERFORM] High load and
iowait but no disk access
We have been trying to pinpoint what originally seem to be a I/O
bottleneck but which now seems to be an issue with either Postgresql or RHES
Remy,
> The behavior we see is that when running queries that do random reads
> on disk, IOWAIT goes over 80% and actual disk IO falls to a crawl at a
> throughput bellow 3000kB/s (We usually average 4 kB/s to 8 kB/s
> on sequential read operations on the netapps)
This seems pretty low fo
On 30-Aug-05, at 12:29, Tom Lane wrote:
=?ISO-8859-1?Q?R=E9my_Beaumont?= <[EMAIL PROTECTED]> writes:
On 30-Aug-05, at 12:15, Tom Lane wrote:
I know zip about NetApps, but doesn't the 8th column indicate pretty
steady disk reads?
Yes, but they are very low.
Sure, but that's more or less w
=?ISO-8859-1?Q?R=E9my_Beaumont?= <[EMAIL PROTECTED]> writes:
> On 30-Aug-05, at 12:15, Tom Lane wrote:
>> I know zip about NetApps, but doesn't the 8th column indicate pretty
>> steady disk reads?
> Yes, but they are very low.
Sure, but that's more or less what you'd expect if the thing is random
=?ISO-8859-1?Q?R=E9my_Beaumont?= <[EMAIL PROTECTED]> writes:
> The stats of the NetApp do confirm that it is sitting idle.
Really?
> CPU NFS CIFS HTTP TotalNet kB/s Disk kB/s Tape kB/s
> Cache Cache CP CP Disk DAFS FCP iSCSI FCP kB/s
>
On Mon, Aug 29, 2005 at 09:42:46AM -0400, Rémy Beaumont wrote:
We have been trying to pinpoint what originally seem to be a I/O
bottleneck but which now seems to be an issue with either Postgresql or
RHES 3.
Nope, it's an IO bottleneck.
The behavior we see is that when running queries that d
On 30-Aug-05, at 12:15, Tom Lane wrote:
=?ISO-8859-1?Q?R=E9my_Beaumont?= <[EMAIL PROTECTED]> writes:
The stats of the NetApp do confirm that it is sitting idle.
Really?
CPU NFS CIFS HTTP TotalNet kB/s Disk kB/s Tape kB/s
Cache Cache CP CP Disk DAFS FCP iSCSI
We have been trying to pinpoint what originally seem to be a I/O bottleneck but which now seems to be an issue with either Postgresql or RHES 3.
We have the following test environment on which we can reproduce the problem:
1) Test System A
Dell 6650 Quad Xeon Pentium 4
8 Gig of RAM
OS: RHES 3 upd
On Aug 18, 2004, at 4:18 AM, eleven wrote:
Hello,
This is not strictly PostgreSQL performance hint, but may be
helpful to someone with problems like mine.
As I earlier posted, I was experiencing very high load average
on one of my Linux database servers (IBM eServer 345, SCSI disks on
LSI Logic co
eleven wrote:
Hello,
This is not strictly PostgreSQL performance hint, but may be
helpful to someone with problems like mine.
As I earlier posted, I was experiencing very high load average
on one of my Linux database servers (IBM eServer 345, SCSI disks on LSI
Logic controller) caused by I/O bottl
...and on Wed, Aug 18, 2004 at 10:18:19AM +0200, eleven used the keyboard:
> Hello,
>
> This is not strictly PostgreSQL performance hint, but may be
> helpful to someone with problems like mine.
>
> As I earlier posted, I was experiencing very high load average
> on one of my Linux database serve
Hello,
This is not strictly PostgreSQL performance hint, but may be
helpful to someone with problems like mine.
As I earlier posted, I was experiencing very high load average
on one of my Linux database servers (IBM eServer 345, SCSI disks on LSI
Logic controller) caused by I/O bottleneck.
INSERT
[EMAIL PROTECTED] wrote:
Whole config is available here:
http://ludojad.itpp.pl/~eleven/pg-high-load.conf
effective_cache_size = 4000 # typically 8KB each
#random_page_cost = 4 # units are one sequential page fetch cost
#cpu_tuple_cost = 0.01 # (same)
#cpu_index_tuple_cost = 0.
Eleven,
> In particular - could someone tell me if those iostat
> values can tell if I'm close to upper performance boundary
> of fast SCSI (Ultra 320, 15k RPM) disks?
It's quite possible that you need to improve your disk array; certainly I
would have spec'd a lot more disk than you're using (
On Tue, 2004-06-29 at 09:55, [EMAIL PROTECTED] wrote:
> Hello,
>
> I'm using PostgreSQL 7.4.2 (package from backports.org)
> on a Debian (woody) box. The machine is IBM eServer 345
> with two 2.8 Xeon CPUs, it has 1024MB of RAM and
> two 15k RPM SCSI disks running in hardware RAID1, which
> is pr
On Tue, Jun 29, 2004 at 09:17:36AM -0700, Marc wrote:
> > Performance issue, I'm experiencing here, is somewhat
> > weird - server gets high average load (from 5 up to 15,
> > 8 on average). Standard performance monitoring
> > utilities (like top) show that CPUs are not loaded
> > (below 20%, ofte
[EMAIL PROTECTED] wrote:
<>I'm using PostgreSQL 7.4.2 (package from backports.org)
on a Debian (woody) box. The machine is IBM eServer 345
with two 2.8 Xeon CPUs, it has 1024MB of RAM and
two 15k RPM SCSI disks running in hardware RAID1, which
is provided by the onboard LSI Logic controller (LSI53C
On Tue, 29 Jun 2004 17:55:37 +0200, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Performance issue, I'm experiencing here, is somewhat
> weird - server gets high average load (from 5 up to 15,
> 8 on average). Standard performance monitoring
> utilities (like top) show that CPUs are not loaded
>
Hello,
I'm using PostgreSQL 7.4.2 (package from backports.org)
on a Debian (woody) box. The machine is IBM eServer 345
with two 2.8 Xeon CPUs, it has 1024MB of RAM and
two 15k RPM SCSI disks running in hardware RAID1, which
is provided by the onboard LSI Logic controller (LSI53C1030).
The databa
71 matches
Mail list logo
