Re: vacuum locking

From: Vivek Khera <khera(at)kcilink(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: vacuum locking
Date: 2003-10-23 20:53:05
Message-ID: x765if3ccu.fsf@yertle.int.kciLink.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

>>>>> "RN" == Rob Nagler <nagler(at)bivio(dot)biz> writes:

RN> Vivek Khera writes:
>> AMI or Adaptec based?

RN> Adaptec, I think. AIC-7899 LVD SCSI is what dmidecode says, and
RN> Red Hat/Adaptec aacraid driver, Aug 18 2003 is what comes up when it

Cool. No need to diddle with it, then. The Adaptec work quite well,
especially if you have battery backup.

Anyhow, it seems that as Tom mentioned, you are going into swap when
your vacuum runs, so I'll suspect you're just at the edge of total
memory utilization, and then you go over the top.

Another theory is that the disk capacity is near saturation, the
vacuum causes it to slow down just a smidge, and then your application
opens additional connections to handle the incoming requests which
don't complete fast enough, causing more memory usage with the
additional postmasters created. Again, you suffer the slow spiral of
death due to resource shortage.

I'd start by getting full diagnosis of overall what your system is
doing during the vacuum (eg, additional processes created) then see if
adding RAM will help.

Also, how close are you to the capacity of your disk bandwidth? I
don't see that in your numbers. I know in freebsd I can run "systat
-vmstat" and it gives me a percentage of utilization that lets me know
when I'm near the capacity.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera(at)kciLink(dot)com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Vivek Khera 2003-10-23 20:54:26 Re: slow select
Previous Message Rob Messer 2003-10-23 18:18:31 Use of multipart index with "IN"