From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Dan Armbrust <daniel(dot)armbrust(dot)list(at)gmail(dot)com> |
Cc: | pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: vacuum output question |
Date: | 2008-11-14 09:33:57 |
Message-ID: | 491D4605.9010604@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Scott Marlowe wrote:
> On Thu, Nov 13, 2008 at 4:08 PM, Dan Armbrust
> <daniel(dot)armbrust(dot)list(at)gmail(dot)com> wrote:
>> Why did those particular tables and indexes take _so_ long to vacuum?
>> Perhaps we have a disk level IO problem on this system?
>
> Assuming pagesize is 8k, then we're talking about scanning 1303*8192
> bytes or 10 Megabytes. My laptop can scan that in less than a second.
>
> So, either the hard drive is incredibly fragmented, or there's
> something wrong with that machine.
If you're using a system with RAID storage, I'd check to make sure
there's no high priority background rebuild or RAID scrubbing going on.
I've had issues in the past where RAID issues have crippled a server to
the point where it's barely able to handle ssh logins.
[Assuming a Linux server:] Naturally it's also worth checking for
processes doing absurd amounts of I/O. See pidstat -d, iostat, vmstat.
Also look for processes constantly in the `D' state in `ps aux' or `top'
which is usually due to heavy I/O. dmesg may also contain useful
information if it's a low level issue.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | tv | 2008-11-14 10:28:40 | Re: Fwd: Tweaking PG (again) |
Previous Message | Craig Ringer | 2008-11-14 09:25:11 | Re: Archive files growth!!! |