Re: Very slow checkpoints - Mailing list pgsql-performance

From Steven Jones
Subject Re: Very slow checkpoints
Date
Msg-id COL129-W590158F348C93F28E325FE92010@phx.gbl
Whole thread Raw
In response to Re: Very slow checkpoints  (didier <did447@gmail.com>)
Responses Re: Very slow checkpoints  (Joao Junior <jcoj2006@gmail.com>)
List pgsql-performance
Hi,

>>
>> Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz
>> avgqu-sz await r_await w_await svctm %util
>> sda 0.00 0.00 0.00 5.00 0.00 2056.00 822.40
>> 0.00 0.00 0.00 0.00 0.00 0.00
>> sdb 0.00 0.00 1055.00 549.00 41166.50 22840.00 79.81
>> 5.28 3.28 4.94 0.10 0.62 100.00
> Your sdb is saturated...

Yes that's what iostat seems to indicate, but it's weird because at the same time it is reporting 100% io utilization I
canhit the disk write (seq) at> 250Mbyte/sec: 

# sync;time bash -c "(dd if=/dev/sda1 of=bf bs=8k count=500000; sync)"
500000+0 records in
500000+0 records out
4096000000 bytes (4.1 GB) copied, 14.8575 s, 276 MB/s

real    0m14.896s
user    0m0.068s
sys    0m10.157s


> Why are checkpointer process and writer process reading at 18 MB/s ?
> I have no experience with zfs but could it be related to COW and
> recordsize? I have no idea if these reads are counted in iotop output
> though.

In general, some random disk write benchmarks and varying block sizes don't have a huge effect.  But for some reason
thecheckpointing process is just simply writing checkpoints too slowly. In the meantime the COPY is piling up logs
whilethe previous checkpoint is still being written, so the next one starts straight away and no setting is able to
splitthem up. 


Regards,
Steve

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fwd: views much slower in 9.3 than 8.4
Next
From: Jake Magner
Date:
Subject: Merge Join chooses very slow index scan