Re: vacuum locking - Mailing list pgsql-performance

From Vivek Khera
Subject Re: vacuum locking
Date
Msg-id x765if3ccu.fsf@yertle.int.kciLink.com
Whole thread Raw
In response to vacuum locking  (Rob Nagler <nagler@bivio.biz>)
Responses Re: vacuum locking
List pgsql-performance
>>>>> "RN" == Rob Nagler <nagler@bivio.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@kciLink.com       Rockville, MD       +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/

pgsql-performance by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: RedHat Enterprise Linux ES 3 ?!?!
Next
From: Vivek Khera
Date:
Subject: Re: slow select