Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 0EB0938447B for ; Thu, 8 Dec 2011 11:58:47 -0400 (AST) Received: from nm14.bullet.mail.sp2.yahoo.com ([98.139.91.84]) by magus.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1RYgMu-0000xL-UM for pgsql-performance@postgresql.org; Thu, 08 Dec 2011 15:58:47 +0000 Received: from [98.139.91.66] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 08 Dec 2011 15:58:31 -0000 Received: from [98.139.91.27] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 08 Dec 2011 15:58:30 -0000 Received: from [127.0.0.1] by omp1027.mail.sp2.yahoo.com with NNFMP; 08 Dec 2011 15:58:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 984484.80868.bm@omp1027.mail.sp2.yahoo.com Received: (qmail 33040 invoked by uid 60001); 8 Dec 2011 15:58:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1323359910; bh=Ljws+X0Ksyhto7fGjp1M7YrfovU1+tG2J7+12ZLoFs0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=f9JM7K1eQYVaOX3DZnZBr7xaoqdolutSeCIAOC5F4IR/VmAEn0IufC9wxjmRZ94SOQ4nkLZqeyqTVf4K3qjen/isjoU0bKCkpQkqTwMfFCPrWhpac54OJnqSeUtwksqP2bpijineHh7t2s09c4Lj3J4Xck+ZrQmIP8QddCWSJ2Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=J3XPccRyBOMb/ssM+NsVA6rzl81ukFN45floPw/xxrCSLO0+XxiLrmw5EypoSXWq50oNgvvnOx3EWLBY90YhYG/ZhPW8tBXH2/YvrsKRHEVmgL4hxI0J/Tiy5isHPPCIiGOncV56VIXEAAXrNFIdeGieLeaUzNo/0+tepo0OlsE=; X-YMail-OSG: NvgV6hEVM1nrGldyC73gsEYrdym_ekhf2elxVCyKD44yyJz f7XeRP7n.vLaNprxLaPyT87XvM0wCywYBsYBvViOrEubakl.vGzGq18Cuisk sN_fRrSTcUPlFY3.4WNPQPaxhp8hTaiNx37bFRKZ4G4a2gMQsqtcfDxzDWLT 2zd8fV1.4T8FJcf0sdo7AT_r9LpHd718UcfO4aFenXwsFKtgOqmpf238RCZL CqCEar_CG1juG6OFg0.JqqNczKVMQuYapW1B4bjSjliUHINUVyR4ymXi8mrt ZtJ3qRK9Bg8m.NB.pCUU9Pjct67QrzDmesYb743E.9gUa.J3iCevOCZPyHNz bAV4K5YO4hLtz54XKYOgbT1RSo938tdRU7LLy.kjpAGHObOyJCamHAeYsu_B i6ONcdWeKYIXFy0ZEz_LPbs4qbpGQgr4AIgyHc5A6IuDyGjMvw6cEvvrstSu gZjl2tLN8dGXduRrS_TX7NXhh7w-- Received: from [64.126.29.122] by web39703.mail.mud.yahoo.com via HTTP; Thu, 08 Dec 2011 07:58:30 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: <4EDEE781.90801@agliodbs.com> <4EDF336F.9080707@megafon.hr> Message-ID: <1323359910.29568.YahooMailNeo@web39703.mail.mud.yahoo.com> Date: Thu, 8 Dec 2011 07:58:30 -0800 (PST) From: Bob Lunney Reply-To: Bob Lunney Subject: Re: Response time increases over time To: =?iso-8859-1?Q?Havasv=F6lgyi_Ott=F3?= , Marti Raudsepp Cc: Aidan Van Dyk , "pgsql-performance@postgresql.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-964953486-212489414-1323359910=:29568" X-Pg-Spam-Score: -3.2 (---) X-Archive-Number: 201112/72 X-Sequence-Number: 45871 ---964953486-212489414-1323359910=:29568 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Otto,=0A=0ASeparate the pg_xlog directory onto its own filesystem and retry= your tests.=0A=0ABob Lunney=0A=0A=0A________________________________=0A Fr= om: Havasv=F6lgyi Ott=F3 =0ATo: Marti Raudsepp = =0ACc: Aidan Van Dyk ; pgsql-performan= ce@postgresql.org =0ASent: Thursday, December 8, 2011 9:48 AM=0ASubject: Re= : [PERFORM] Response time increases over time=0A =0A=0AI have moved the dat= a directory (xlog, base, global, and everything) to an ext4 file system. Th= e result hasn't changed unfortuately. With the same load test the average r= esponse time: 80ms; from 40ms to 120 ms everything occurs.=0AThis ext4 has = default settings in fstab.=0AHave you got any other idea what is going on h= ere?=0A=0AThanks,=0AOtto=0A=0A=0A=0A=0A=0A2011/12/8 Marti Raudsepp =0A=0AOn Thu, Dec 8, 2011 at 06:37, Aidan Van Dyk wrote:=0A>> Let me guess, debian squeeze, with data and xlog on both on= a single=0A>> ext3 filesystem, and the fsync done by your commit (xlog) is= flushing=0A>> all the dirty data of the entire filesystem (including PG da= ta writes)=0A>> out before it can return...=0A>=0A>This is fixed with the d= ata=3Dwriteback mount option, right?=0A>(If it's the root file system, you = need to add=0A>rootfsflags=3Ddata=3Dwriteback to your kernel boot flags)=0A= >=0A>While this setting is safe and recommended for PostgreSQL and other=0A= >transactional databases, it can cause garbage to appear in recently=0A>wri= tten files after a crash/power loss -- for applications that don't=0A>corre= ctly fsync data to disk.=0A>=0A>Regards,=0A>Marti=0A> ---964953486-212489414-1323359910=:29568 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Otto,

Separate the pg_xlog directory onto its= own filesystem and retry your tests.

Bob Lunney

From: Havasv=F6lgyi Ott=F3 <havasvolgyi.otto@gmail.= com>
To: Marti Raud= sepp <marti@juffo.org>
Cc:<= /span> Aidan Van Dyk <aidan@highrise.ca>; pgsql-performance@postg= resql.org
Sent: Thurs= day, December 8, 2011 9:48 AM
Subject:<= /b> Re: [PERFORM] Response time increases over time

=0A
I have moved the data directory (xlog, base, global, and everything) = to an ext4 file system. The result hasn't changed unfortuately. With the sa= me load test the average response time: 80ms; from 40ms to 120 ms everythin= g occurs.
=0AThis ext4 has default settings in fstab.
Have you got an= y other idea what is going on here?

Thanks,
Otto



<= br>
2011/12/8 Marti Raudsepp <marti@juffo.org><= br>=0A
On Thu, Dec 8, 2011 at 06:37, Aidan Van Dyk <<= a rel=3D"nofollow" ymailto=3D"mailto:aidan@highrise.ca" target=3D"_blank" h= ref=3D"mailto:aidan@highrise.ca">aidan@highrise.ca> wrote:
=0A=0A= > Let me guess, debian squeeze, with data and xlog on both on a single=0A> ext3 filesystem, and the fsync done by your commit (xlog) is flus= hing
=0A> all the dirty data of the entire filesystem (including PG d= ata writes)
=0A> out before it can return...
=0A
=0A
This = is fixed with the data=3Dwriteback mount option, right?
=0A(If it's the = root file system, you need to add
=0Arootfsflags=3Ddata=3Dwriteback to y= our kernel boot flags)
=0A
=0AWhile this setting is safe and recommen= ded for PostgreSQL and other
=0Atransactional databases, it can cause ga= rbage to appear in recently
=0Awritten files after a crash/power loss --= for applications that don't
=0Acorrectly fsync data to disk.
=0A
= =0ARegards,
=0AMarti
=0A

=0A


---964953486-212489414-1323359910=:29568--