Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFQrl-0000jH-6W for pgsql-admin@arkaria.postgresql.org; Mon, 29 May 2017 20:02:13 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dFQrk-0004KB-Is for pgsql-admin@arkaria.postgresql.org; Mon, 29 May 2017 20:02:12 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dFQps-00014I-Il for pgsql-admin@postgresql.org; Mon, 29 May 2017 20:00:16 +0000 Received: from mail-wm0-x22a.google.com ([2a00:1450:400c:c09::22a]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dFQpl-0006xb-Av for pgsql-admin@postgresql.org; Mon, 29 May 2017 20:00:15 +0000 Received: by mail-wm0-x22a.google.com with SMTP id d127so71476457wmf.0 for ; Mon, 29 May 2017 13:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=uSbpsm8W7Qt4RTfRrlaoHz+fs/OeKnJJ9Zwi0pIlGbU=; b=jN0qC9aoPzcKSB4r32c2hlomNFJ76obTgXUfSp9D+t6SbpAscTyOOpHkfE5+sWAMxD jHl0xHhM6ZyUfX4S2flt69kEgK/uC4VRhshIiUVC4mu5x1IeELXe6Ih9HeF+EU7L2Q31 5hjbBRE+gyUtyaZUj2eWqv99yR6naFNpVE/1WtdYqFh0X9pMJh4lDReGqsXyv+RyDFoH wVFJjKB0iAITWwboF+s2W5eArxx4f/n7M/joTYP+T0Z0gisNNgoJ6yUMH+eivbS9Yujp AYCKaAHRjz/iC8zj10ntbvU9W7bVw+v2dcnFb5UL1EupDwDm+p/rjwE//dZiD9bT6c+/ N8fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=uSbpsm8W7Qt4RTfRrlaoHz+fs/OeKnJJ9Zwi0pIlGbU=; b=YBRbUTaMzj6mxAfhZu0lZjTcIAOS6Hl5ZU/z+l3517RMnuCMqkyzpPh6Ft5p8Ulygu 6P4IZ5xVYro3sCqV2eCYTpYtwiEYpv+sNx0nyhqexc+5buzX2MAz3uUqk4Rt1EMi6fpA Xg9oPCx7jhHc68srwaXebRN3dLOmSF5tFb1rqx2M1IVvFp9ncswcQkTU7QthG+VThtbw GI+bdtfpMaiGEWYjXmH02wB9DdRweNIVk9mEaiKvfUkmqRyg9wBghQvLjR6cN8caxIG1 NnctbP2i6V5Q48+VLeX1qyzVUZxRHCeL5DSPxspBYj0rHrVKZRdw1HbQaAJg7WHoOnE4 3bEg== X-Gm-Message-State: AODbwcCM6vcLDCddtfmpB1LeUg/AWQURDeOReGJDIeRYpcMmCKwFApi9 4mKEX+l8ibzG1q97 X-Received: by 10.28.156.142 with SMTP id f136mr24092046wme.24.1496088007724; Mon, 29 May 2017 13:00:07 -0700 (PDT) Received: from PC018 (dslb-178-001-020-074.178.001.pools.vodafone-ip.de. [178.1.20.74]) by smtp.gmail.com with ESMTPSA id x17sm6506860wrd.63.2017.05.29.13.00.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 13:00:06 -0700 (PDT) From: "Klaus P. Pieper" To: "'Tom Lane'" Cc: References: <028501d2d84f$2f1ea840$8d5bf8c0$@gmail.com> <31836.1496045941@sss.pgh.pa.us> <030801d2d87b$4f556820$ee003860$@gmail.com> <12144.1496074592@sss.pgh.pa.us> In-Reply-To: <12144.1496074592@sss.pgh.pa.us> Subject: Re: pgbench Windows outperforms Debian in Write tests while Debian is faster in SELECT only tests Date: Mon, 29 May 2017 21:59:43 +0200 Message-ID: <006401d2d8b6$1e889240$5b99b6c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01D2D8C6.E21273B0" X-Mailer: Microsoft Outlook 16.0 Content-Language: de Thread-Index: AQGliTsjlxOtkJqG1mT2odcKF1E5LQEuBCa4AQwGyGgCFITZAaJD4XDg X-Antivirus: Avast (VPS 170529-2, 29.05.2017), Outbound message X-Antivirus-Status: Clean X-Pg-Spam-Score: -2.4 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org This is a multipart message in MIME format. ------=_NextPart_000_0065_01D2D8C6.E21273B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Von: Tom Lane > Gesendet: Montag, 29. Mai 2017 18:17 > > OK, so open_datasync and fdatasync are nonfunctional on Windows, which is= > unsurprising. The other cases are evidently doing *something*, but the amount > of overhead is variable from one sync method to another, which is likewis= e > unsurprising. The whole reason why we have these options at all is that some > systems handle some of them better than others. In this case, I think th= e > relevant conclusion is that correct configuration for Debian is to use > open_datasync or fdatasync, while correct configuration for Windows is to= use > fsync or fsync_writethrough, and when you compare those two configurations, > yes Windows is slower. Excellent answer, thanks. Correct me if I'm wrong: I understand that synchronous_commit =3D off in combination with fdatasync (Debian) or fsync_writethrough (Windows) is "safe" (for regular interactive desktop applications). These options gave the following results: Windows Debian 40 clients READ/WRITE 5400 7400 1 client READ/WRITE 400 390 Single client READ/WRITE tests are on now the same level. In the multi client test, Debian is performing significantly better than Windows. > > If you're a paranoid sort you would want to do plug-pull testing to ensur= e that > your selected setting actually does prevent data corruption during a system > crash. That's certainly an option before we take this into production. Regards Klaus --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren gepr=C3=BCft. https://www.avast.com/antivirus ------=_NextPart_000_0065_01D2D8C6.E21273B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Von= : Tom Lane

> Gesendet: Montag, 29= =2E Mai 2017 18:17

>

> OK, so open_datasync and fdatasync are nonfu= nctional on Windows, which is

> un= surprising.  The other cases are evidently doing *something*, but the = amount

> of overhead is variable f= rom one sync method to another, which is likewise

> unsurprising.  The whole reason why we have these op= tions at all is that some

> system= s handle some of them better than others.  In this case, I think the

> relevant conclusion is that corre= ct configuration for Debian is to use

> open_datasync or fdatasync, while correct configuration for Windows i= s to use

> fsync or fsync_writethr= ough, and when you compare those two configurations,

> yes Windows is slower.

 

Excellent answer, thank= s.

 

Correct me if I'm wrong: I understand that synchronous_commit = =3D off in combination with fdatasync (Debian) or fsync_writethrough (Windo= ws) is „safe“ (for regular interactive desktop applications).

 

These options gave the following results:

 

       &nbs= p;            &= nbsp;    Windows        D= ebian

40 clients READ/WRITE     &= nbsp; 5400          7400 =  

1 client READ/WRITE     =      400        = ;   390

 

Single client RE= AD/WRITE tests are on now the same level. In the multi client test, Debian = is performing significantly better than Windows.

 

> =

> If you're a paranoid sort you would = want to do plug-pull testing to ensure that

> your selected setting actually does prevent data corruption dur= ing a system

> crash.

 

That= ’s certainly an option before we take this into production.

 

= Regards Klaus


3D"" Virenf= rei. www.avast.com
=
------=_NextPart_000_0065_01D2D8C6.E21273B0--