Actually, this is because I changed sort_mem to 4 Mb as asked by Robert.
I removed this setting..
Gaëtan
Le 26/11/11 18:58, « Tomas Vondra » a écrit :
>Dne 26.11.2011 18:08, Gaëtan Allart napsal(a):
>> UhmŠ
>>
>> I'm seeing dozens and dozens of temporary file crea
th "base/pgsql_tmp/pgsql_tmp13772.2639", size
2749672
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp15388.1053", size 24276
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp15388.452", size
2948712
Does this help ?
Gaëtan
Le 26/11/11 17:47, « Gaëtan Allar
to keep my database Up&running even with bad
performance?
Filesystem is ext3. Running over a hardware RAID-1 config.
Gaëtan
Le 26/11/11 15:12, « Tomas Vondra » a écrit :
>On 26 Listopad 2011, 10:45, Gaëtan Allart wrote:
>> A better view of iotop :
>>
>> TID PRIO US
Hello Robert,
I'm having around 30 active connections (average).
As far as disk layout is concerned, ever thing's on the same disk (raid 1
with 2 SSDs).
Gaëtan
Le 26/11/11 15:25, « Robert Treat » a écrit :
>On Fri, Nov 25, 2011 at 6:48 PM, Gaëtan Allart wrote:
>>
en" AS "comments_open", "table"."site_id"
AS "site_id", "table"."is_local" AS "is_local", "table"."status" AS
"status", "table"."visits" AS "visits", "table".
:00.680779+01
(1 row)
Processes that were writing were "SELECT" queries against database.
Gaëtan
Le 26/11/11 00:17, « Cédric Villemain »
a écrit :
>Le 25 novembre 2011 23:47, Gaëtan Allart a écrit :
>> Hello Tomas and Cédric,
>>
>> Right now, the server
Hello Tomas and Cédric,
Right now, the server is not all right. Load is above 30 and queries are
slow like hell.
Here's the complete iotop. Note the 71 MB/s writes (apparently on SELECT
queries).
Total DISK READ: 633.35 K/s | Total DISK WRITE: 71.06 M/s
TID PRIO USER DISK READ DISK WRI
te:
>> On Thu, Nov 24, 2011 at 9:09 AM, Tomas Vondra wrote:
>>> On 24 Listopad 2011, 14:51, Gaëtan Allart wrote:
>>>> Postgresql.conf :
>>>>
>>>> max_connections = 50
>>>> shared_buffers = 12G
>>>> temp_buffers = 40MB
>>
Tomas,
I've enabled logging of checkpoints.
I'm waiting for the next i/o crisisŠ
Gaëtan
Le 24/11/11 17:02, « Tomas Vondra » a écrit :
>On 24 Listopad 2011, 16:39, Robert Treat wrote:
>> On Thu, Nov 24, 2011 at 9:09 AM, Tomas Vondra wrote:
>>> On 24 Listopa
made the first changes
recommenced by Tomas. Let's wait for a couple of hours again to confirm
this.
Gaëtan
Le 24/11/11 16:39, « Robert Treat » a écrit :
>On Thu, Nov 24, 2011 at 9:09 AM, Tomas Vondra wrote:
>> On 24 Listopad 2011, 14:51, Gaëtan Allart wrote:
>>> Hell
dirty_ratio
20
cat /proc/sys/vm/dirty_background_ratio10
Thanks a lot Tomas. You're really helpful!
Gaëtan
Le 24/11/11 15:09, « Tomas Vondra » a écrit :
>On 24 Listopad 2011, 14:51, Gaëtan Allart wrote:
>> Hello everyone,
>>
>> I'm having some troubles with a Postgresql
Hello everyone,
I'm having some troubles with a Postgresql server.
We're using PG has a database backend for a very big website (lots of data
and much traffic).
The issue : server suddenly (1H after restart) becomes slow (queries not
responding), load rises (>20 instead of 1), iowait rises (20 to
Hi everyone,
We've just moved our website database from pg 8.4 to pg 9.0 and we found
out a very long query (that wasn't that long under 8.4).
And I actually can't explain why it's taking so much timeŠ
Here it is :
EXPLAIN ANALYZE SELECT "articles_article"."id",
"articles_article"."name", "ar
You were absolutely right Tom.
Rising work_mem did the trick!
Many thanks :-)
What's the best value for work_mem ?
Gaëtan
Le 7 févr. 2010 à 07:38, Tom Lane a écrit :
> =?iso-8859-1?Q?Ga=EBtan_Allart?= writes:
>> I'm experiencing an interesting issue with PostgreSQL 8.4.2-r2.
>> I was running
ost=0.00..316550.04
rows=2245904 width=8)
(5 rows)
Tunning the postgresql.conf with these options has not changed anything :
enable_hashagg = on, enable_sort =off.
Any idea how to disable this automatic CPU killing sorting operation?
Thanks,
Gaëtan Allart
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
15 matches
Mail list logo