Re: High load,

From: Justin Pitts <justinpitts(at)gmail(dot)com>
To: Michael Kohl <michael(dot)kohl(at)tupalo(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: High load,
Date: 2011-01-27 12:30:54
Message-ID: AANLkTi=ZE1fZbB10jar+wAemGJfa2V8fWKurv5GLBZZx@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> 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 = 256MB

That is a foot-gun waiting to go off. If 32 queries manage to
simultaneously each need 256MB to sort, your cache is blown out and
the server is out of RAM. If your application is like most, you need a
huge work_mem for, maybe, 1% of your queries. You can request it high
on a per connection/per query basis for the queries that need it, and
set the default to a low, safe figure.

> 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 credit for. The are certainly no better at sequential IO than
(good) conventional drives. You might have a lot of room to turn this
down even smaller.

In response to

  • High load, at 2011-01-27 10:31:13 from Michael Kohl

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Andres Freund 2011-01-27 12:35:24 Re: High load,
Previous Message Waldomiro 2011-01-27 12:10:01 Why I lost the last pg_xlog file?