From: | david(at)lang(dot)hm |
---|---|
To: | Dmitry Koterov <dmitry(at)koterov(dot)ru> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Are random writes optimized sequentially by Linux kernel? |
Date: | 2009-01-08 00:10:00 |
Message-ID: | alpine.DEB.1.10.0901071604100.32030@asgard.lang.hm |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 8 Jan 2009, Dmitry Koterov wrote:
> OK, thank you.
>
> Now - PostgreSQL-related question. If the system reorders writes to minimize
> seeking, I suppose that in heavy write-loaded PostgreSQL instalation dstat
> (or iostat) realtime write statistics should be close to the maximum
> possible value reported by bonnie++ (or simple dd) utility.
this is not the case for a couple of reasons
1. bonnie++ and dd tend to write in one area, so seeks are not as big a
factor as writing across multiple areas
2. postgres doesn't do the simple writes like you described earlier
it does something like
write 123-124-fsync-586-354-257-fsync-123-124-125-fsync
(writes to the WAL journal, syncs it to make sure it's safe, then writes
to the destinations, the n syncs, then updates the WAL to record that it's
written....)
the fsync basicly tells the system, don't write anything more until these
are done. and interrupts the nice write pattern.
you can address this by having large battery-backed caches that you write
to and they batch things out to disk more efficiantly.
or you can put your WAL on a seperate drive so that the syncs on that
don't affect the data drives (but you will still have syncs on the data
disks, just not as many of them)
David Lang
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Carey | 2009-01-08 00:11:34 | Re: understanding postgres issues/bottlenecks |
Previous Message | Bborie Park | 2009-01-07 23:51:29 | Re: understanding postgres issues/bottlenecks |