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/
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" |