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
and it
|
| 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
: [PERFORM] High load average in 64-core server , no I/O wait and
CPU is idle
|
| On Thu, May 24, 2012 at 12:39 AM, Rajesh Kumar. Mallah
|mal...@tradeindia.com 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
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
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
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
to
| From: Steve Crawford scrawf...@pinpointresearch.com
| To: Rajesh Kumar. Mallah mal...@tradeindia.com
| Cc: Andy Colson a...@squeakycode.net, Claudio Freire
klaussfre...@gmail.com, pgsql-performance@postgresql.org
| Sent: Thursday, May 24, 2012 9:23:47 PM
| Subject: Re: [PERFORM] High load
- Stephen Frost sfr...@snowman.net wrote:
| From: Stephen Frost sfr...@snowman.net
| To: Rajesh Kumar. Mallah mal...@tradeindia.com
| 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
* 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
On Thu, May 24, 2012 at 2:09 PM, Stephen Frost sfr...@snowman.net 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
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
On Thu, May 24, 2012 at 12:39 AM, Rajesh Kumar. Mallah
mal...@tradeindia.com 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
- Claudio Freire klaussfre...@gmail.com wrote:
| From: Claudio Freire klaussfre...@gmail.com
| To: Rajesh Kumar. Mallah mal...@tradeindia.com
| 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
On Thu, May 24, 2012 at 2:26 AM, Rajesh Kumar. Mallah
mal...@tradeindia.com 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
On Thu, Jan 27, 2011 at 6:36 AM, Michael Kohl michael.k...@tupalo.com wrote:
Cédric, thanks a lot for your answer so far!
On Thu, Jan 27, 2011 at 12:24 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
you have swap used, IO on the swap partition ?
Memory-wise we are fine.
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
On Thu, Jan 27, 2011 at 5:31 AM, Michael Kohl michael.k...@tupalo.com 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 Thu, Jan 27, 2011 at 6:05 PM, Scott Marlowe scott.marl...@gmail.com 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 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)
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
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
2011/1/27 Michael Kohl michael.k...@tupalo.com:
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
Cédric, thanks a lot for your answer so far!
On Thu, Jan 27, 2011 at 12:24 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com 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:
2011/1/27 Michael Kohl michael.k...@tupalo.com:
Cédric, thanks a lot for your answer so far!
On Thu, Jan 27, 2011 at 12:24 PM, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
you have swap used, IO on the swap partition ?
Memory-wise we are fine.
can you paste the /proc/meminfo
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 limit
On Thu, Jan 27, 2011 at 1:30 PM, Justin Pitts justinpi...@gmail.com 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
2011/1/27 Andres Freund and...@anarazel.de:
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.
On Thursday, January 27, 2011 02:23:48 PM Cédric Villemain wrote:
2011/1/27 Andres Freund and...@anarazel.de:
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
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 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
On Thu, Jan 27, 2011 at 4:06 PM, Andy Colson a...@squeakycode.net 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
On Thu, Jan 27, 2011 at 8:09 AM, Michael Kohl michael.k...@tupalo.com wrote:
On Thu, Jan 27, 2011 at 4:06 PM, Andy Colson a...@squeakycode.net 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
On 1/27/2011 9:09 AM, Michael Kohl wrote:
On Thu, Jan 27, 2011 at 4:06 PM, Andy Colsona...@squeakycode.net 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
* 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 Thu, Jan 27, 2011 at 10:54 AM, Stephen Frost sfr...@snowman.net 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
On Thursday, January 27, 2011 07:13:17 PM Scott Marlowe wrote:
On Thu, Jan 27, 2011 at 10:54 AM, Stephen Frost sfr...@snowman.net 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
./Canadá
Asunto: Re: [PERFORM] High load,
On 1/27/2011 9:09 AM, Michael Kohl wrote:
On Thu, Jan 27, 2011 at 4:06 PM, Andy Colsona...@squeakycode.net wrote:
Have you run each of your queries through explain analyze lately?
A code review including checking of queries is on our agenda.
You
@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 wrote:
We
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
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
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.
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
-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.
We moved our application to a new machine last
: [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
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 Allgood wrote
] 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 postmasters is that you
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.4.x,
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
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
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
=?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
in
=?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 randomly
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
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 for a
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
3.We have
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
-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 have replaced
?
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 netapp over NFS
]
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 netapp over NFS without any
issues, but we have seen high IO-wait on other Dell
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.
...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 servers
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
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
[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 =
[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
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%, often near
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 provided
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
68 matches
Mail list logo
