Re: Poor performance on seq scan

>> tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id
>> 1 14 128.00 1 0.10 128.00 1 0.10 5 0 94 1 0
>> 0 12 123.98 104 12.56 123.74 104 12.56 8 0 90 2 0
>> 0 12 125.66 128 15.75 125.26 128 15.68 10 0 85 6 0
>> 0 12 124.66 129 15.67 124.39 129 15.64 12 0 85 3 0
>> 0 12 117.13 121 13.87 117.95 121 13.96 12 0 84 5 0
>> 0 12 104.84 118 12.05 105.84 118 12.19 10 0 87 2 0
>
> Why is that showing 85+ percent *system* CPU time?? I could believe a
> lot of idle CPU if the query is I/O bound, or a lot of user time if PG
> was being a hog about doing the ~~ comparisons (not too unlikely BTW).
> But if the kernel is eating all the CPU, there's something very wrong,
> and I don't think it's Postgres' fault.

There IS a bug for SATA disk drives in some versions of the Linux kernel. On a lark I ran some of the I/O tests in this thread, and much to my surprise discovered my write speed was 6 MB/sec ... ouch! On an identical machine, different kernel, the write speed was 54 MB/sec.

A couple of hours of research turned up this:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168363

The fix for me was to edit /boot/grub/grub.conf, like this:

kernel /vmlinuz-2.6.12-1.1381_FC3 ro root=LABEL=/ rhgb quiet \
ramdisk_size=12000000 ide0=noprobe ide1=noprobe

Notice the "ideX=noprobe". Instant fix -- after reboot the disk write speed jumped to what I expected.

Craig