Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL strugling during high load

From: "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Cc: Mindaugas Riauba <mind(at)bi(dot)lt>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,pgsql-performance(at)postgresql(dot)org
Subject: Re: PostgreSQL strugling during high load
Date: 2005-05-16 02:45:54
Message-ID: C2CE8A93-938B-4E30-A25E-8A25316B715B@sitening.com (view raw or flat)
Thread:
Lists: pgsql-performance
Actually, that solution didn't work so well. Even very small delays  
in the loop caused the entire loop to perform too slowly to be useful  
in the production environment. I ended up producing a small patch out  
of it :P, but we ended up using pgpool to reduce connections from  
another part of the app, which made the pg_autovacuum spikes less  
troublesome overall.

-tfo

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC

Strategic Open Source: Open Your i™

http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On May 15, 2005, at 9:26 PM, Matthew T. O'Connor wrote:

> Mindaugas Riauba wrote:
>
>
>>> The "vacuum cost" parameters can be adjusted to make vacuums fired
>>> by pg_autovacuum less of a burden.  I haven't got any specific  
>>> numbers
>>> to suggest, but perhaps someone else does.
>>>
>>>
>>
>>  It looks like that not only vacuum causes our problems. vacuum_cost
>> seems to lower vacuum impact but we are still noticing slow  
>> queries "storm".
>> We are logging queries that takes >2000ms to process.
>>  And there is quiet periods and then suddenly 30+ slow queries  
>> appears in
>> log within the same second. What else could cause such behaviour?  
>> WAL log
>> switch? One WAL file seems to last <1 minute.
>>
>>
>
> How long are these quite periods?  Do the "strom" periods  
> correspond to pg_autovacuum loops?  I have heard from one person  
> who had LOTS of databases and tables that caused the pg_autovacuum  
> to create a noticable load just updateing all its stats.  The  
> solution in that case was to add a small delay insidet the inner  
> pg_autovacuum loop.

In response to

pgsql-performance by date

Next:From: Josh BerkusDate: 2005-05-16 03:26:02
Subject: Re: checkpoint segments
Previous:From: Matthew T. O'ConnorDate: 2005-05-16 02:26:50
Subject: Re: PostgreSQL strugling during high load

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group