Re: [PERFORM] Response time increases over time

2011-12-08 Thread Havasvölgyi Ottó
esql.org > *Sent:* Thursday, December 8, 2011 9:48 AM > > *Subject:* Re: [PERFORM] Response time increases over time > > I have moved the data directory (xlog, base, global, and everything) to an > ext4 file system. The result hasn't changed unfortuately. With the same &g

Re: [PERFORM] Response time increases over time

2011-12-08 Thread Bob Lunney
] Response time increases over time I have moved the data directory (xlog, base, global, and everything) to an ext4 file system. The result hasn't changed unfortuately. With the same load test the average response time: 80ms; from 40ms to 120 ms everything occurs. This ext4 has default settin

Re: [PERFORM] Response time increases over time

2011-12-08 Thread Havasvölgyi Ottó
I have moved the data directory (xlog, base, global, and everything) to an ext4 file system. The result hasn't changed unfortuately. With the same load test the average response time: 80ms; from 40ms to 120 ms everything occurs. This ext4 has default settings in fstab. Have you got any other idea w

Re: [PERFORM] Response time increases over time

2011-12-08 Thread Marti Raudsepp
On Thu, Dec 8, 2011 at 06:37, Aidan Van Dyk wrote: > 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...

Re: [PERFORM] Response time increases over time

2011-12-08 Thread Havasvölgyi Ottó
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 s

Re: [PERFORM] Response time increases over time

2011-12-07 Thread Aidan Van Dyk
On Wed, Dec 7, 2011 at 5:13 PM, Havasvölgyi Ottó 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

Re: [PERFORM] Response time increases over time

2011-12-07 Thread Havasvölgyi Ottó
Thanks for that Mario, I will check it out. @All: Anyway, I have compiled 9.1.2 from source, and unfortunately the performance haven't got better at the same load, it is consistently quite low (~70 ms average transaction time with 100 clients) on this Debian. I am quite surprised about this, it is

Re: [PERFORM] Response time increases over time

2011-12-07 Thread Mario Splivalo
On 12/07/2011 09:23 AM, Havasvölgyi Ottó wrote: > Thanks, Josh. > The only reason I tried 8.4 first is that it was available for Debian as > compiled package, so it was simpler for me to do it. Anyway I am going > to test 9.1 too. I will post about the results. > If you're using squeeze, you can

Re: [PERFORM] Response time increases over time

2011-12-07 Thread Havasvölgyi Ottó
Thanks, Josh. The only reason I tried 8.4 first is that it was available for Debian as compiled package, so it was simpler for me to do it. Anyway I am going to test 9.1 too. I will post about the results. Best reagrds, Otto 2011/12/7 Josh Berkus > On 12/6/11 4:30 PM, Havasvölgyi Ottó wrote: >

Re: [PERFORM] Response time increases over time

2011-12-06 Thread Josh Berkus
On 12/6/11 4:30 PM, Havasvölgyi Ottó wrote: > Is there so much difference between 8.4 and 9.1, or is this something else? > Please tell me if any other info is needed. It is fairly likely that the difference you're seeing here is due to improvements made in checkpointing and other operations made

[PERFORM] Response time increases over time

2011-12-06 Thread Havasvölgyi Ottó
Hi all, I am running a load simulation on Debian with PostgreSQL 8.4.9 (standard Debian package). Certain number of clients do the following stepsin a transaction (read commited level) periodically (about 1.1 transaction per second / client) and concurrently: -reads a record of table Machine a