"Simon Riggs" <[EMAIL PROTECTED]> wrote: > > tests | pgbench | DBT-2 response time (avg/90%/max) > > ---------------------------+---------+----------------------------------- > > LDC only | 181 tps | 1.12 / 4.38 / 12.13 s > > + BM_CHECKPOINT_NEEDED(*) | 187 tps | 0.83 / 2.68 / 9.26 s > > + Sorted writes | 224 tps | 0.36 / 0.80 / 8.11 s > > I'm very surprised by the BM_CHECKPOINT_NEEDED results. What percentage > of writes has been saved by doing that? > How long was the write phase of the checkpoint, how long > between checkpoints? > > I can see the sorted writes having an effect because the OS may not > receive blocks within a sufficient time window to fully optimise them. > That effect would grow with increasing sizes of shared_buffers and > decrease with size of controller cache. How big was the shared buffers > setting? What OS scheduler are you using? The effect would be greatest > when using Deadline.
I didn't tune OS parameters, used default values. In terms of cache amounts, postgres buffers were larger than kernel write pool and controller cache. that's why the OS could not optimise writes enough in checkpoint, I think. - 200MB <- RAM * dirty_background_ratio - 128MB <- Controller cache - 2GB <- postgres shared_buffers I forget to gather detail I/O information in the tests. I'll retry it and report later. RAM 2GB Controller cache 128MB shared_buffers 1GB checkpoint_timeout = 15min checkpoint_write_percent = 50.0 RHEL4 (Linux 2.6.9-42.0.2.EL) vm.dirty_background_ratio = 10 vm.dirty_ratio = 40 vm.dirty_expire_centisecs = 3000 vm.dirty_writeback_centisecs = 500 Using cfq io scheduler Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
