Yes, ext3 is the global file system, and you are right, PG xlog and data are on this one.
Is this really what happens Aidan at fsync?
What is be the best I can do?
Mount xlog directory to a separate file system?
If so, which file system fits the best for this purpose?
Should I also mount the data separately, or is that not so important?
The strange thing is that InnoDb data and xlog are also on the same filesystem, but on a separate one (ext4) from the global one.
Thanks,
Otto
2011/12/8 Aidan Van Dyk
<aidan@highrise.ca>On Wed, Dec 7, 2011 at 5:13 PM, Havasvölgyi Ottó
<
havasvolgyi.otto@gmail.com> wrote:
> So there seems to be something on this Debian machine that hinders
> PostgreSQL to perform better. With 8.4 I logged slow queries (with 9.1 not
> yet), and almost all were COMMIT, taking 10-20-30 or even more ms. But at
> the same time the fsync rate can be quite high based on pg_test_fsync, so
> probably not fsync is what makes it slow. Performance seems to degrade
> drastically as I increase the concurrency, mainly concurrent commit has
> problems as I can see.
> Do anybody have any idea based on this info about what can cause such
> behaviour, or what I could check or try?
Let me guess, debian squeeze, with data and xlog on both on a single
ext3 filesystem, and the fsync done by your commit (xlog) is flushing
all the dirty data of the entire filesystem (including PG data writes)
out before it can return...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
