Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dFKG8-0006xH-1L for pgsql-admin@arkaria.postgresql.org; Mon, 29 May 2017 12:58:56 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dFKG6-0005Q6-BX for pgsql-admin@arkaria.postgresql.org; Mon, 29 May 2017 12:58:54 +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 1dFKG5-0005PV-CT for pgsql-admin@postgresql.org; Mon, 29 May 2017 12:58:53 +0000 Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dFKG2-0007OY-Ag for pgsql-admin@postgresql.org; Mon, 29 May 2017 12:58:52 +0000 Received: by mail-wm0-x22b.google.com with SMTP id d127so58576026wmf.0 for ; Mon, 29 May 2017 05:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=M7AaGzgSLJVwqXAe1OGVhzNnB5wmgLu252FJ9uihs0M=; b=kzw34uqHK8mZWnbhmFrn0ANCPAL3x4MFbgJDVPPzpFV1RsAgv/n2ZNPDcu5q3srxgj i2xQJBnHswiFNKr6mX0gNShUV0+0bpKlcx+sFHyqVlH+dQIuOUR/w5M3SdKqWyk0fbWs uU/i1FduJQjH7gFrYzXv0vYnLxnVIOr3LoNTNLl82rwUZ+Z0s/pi1BQEcF2HxziGYBHy Bu8WL142fzrzPL8+dQs9G2QZItlwif4IsS9imq5JyVq6IUkVMygrlkdCh3fLaM+fBJJo 21PfGLeMWWB3bGSNP+bKgKFQWTQzFXNq7VFRm11SNdQHHc/KuXCxjK44AsW6z0yDjQvn ijGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=M7AaGzgSLJVwqXAe1OGVhzNnB5wmgLu252FJ9uihs0M=; b=JdlZNcMwbWZI5xKrLw8VH6uyfnArDR0wMz/Bz6tAnUnWTQQodIKuz5fBamHr1Bx5IG jxsmtgMyKdjYqK/SjIqXmckNL5YS9C0XudE5o0TcDYnfaSFXqrr873X2LX9DIfkVP6p6 Ryy0wXsEb+dB6u9/FssCBHb4K5ACJPEJsz8Zgx2A1Aw6MKOovSOhTfF3XNq+DazUmQ7S +1su9RmcB7vRx8YbZALWUMEZ/MKztN+nd3irHTIlF4yRqOcpH3Z3v6DRoIa1zkXCKyz/ oon0APnl98T6rlImhigXMMj/Sk16COYEP/5VjGfA3iW4zwHOfSWVNGMBn/rtW7R8Kx54 uTxQ== X-Gm-Message-State: AODbwcBCnm+GbCde9Vvzt0fZWfQh3hMbL8WhnFjjjjJNxpcx4w4vYHxW o3q+7++HJdCx53hj X-Received: by 10.223.138.194 with SMTP id z2mr2147792wrz.66.1496062727963; Mon, 29 May 2017 05:58:47 -0700 (PDT) Received: from PC14 (mail.ibeq.com. [212.100.42.241]) by smtp.gmail.com with ESMTPSA id 185sm9320287wmp.1.2017.05.29.05.58.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 05:58:47 -0700 (PDT) From: "Klaus P. Pieper" To: References: <028501d2d84f$2f1ea840$8d5bf8c0$@gmail.com> <31836.1496045941@sss.pgh.pa.us> In-Reply-To: <31836.1496045941@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 14:58:46 +0200 Message-ID: <030801d2d87b$4f556820$ee003860$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0309_01D2D88C.12E0F740" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGliTsjlxOtkJqG1mT2odcKF1E5LQEuBCa4olxv7BA= Content-Language: de 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_0309_01D2D88C.12E0F740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Urspr=FCngliche Nachricht----- > Von: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Gesendet: Montag, 29. Mai 2017 10:19 > An: Klaus P. Pieper > Cc: pgsql-admin@postgresql.org > Betreff: Re: [ADMIN] pgbench Windows outperforms Debian in Write tests > while Debian is faster in SELECT only tests >=20 > "Klaus P. Pieper" < kpi6288@gmail.com> = writes: > > How can Windows outperform Debian by a factor of 2? >=20 > Are you sure you have Windows configured to fsync properly? > Not waiting for writes to hit disk would be a really easy explanation = for a > discrepancy of this kind. =20 It seems that it is indeed related to the wal_sync_method settings. =20 Results for 1 client read / write: =20 Option Windows Debian fdatasync 340 150 fsync 125 90 open_datasync 360 160 fsync_writethrough 115 n/a open_sync n/a 90 =20 fsync =3D off 360 400 =20 The result setting fsync=3Doff shows that the maximum performance of the Debian syste is above Windows.=20 However, with fsync=3Don, Windows still outperforms the Debian system = with all options.=20 =20 In addition, the results on the Windows system with =93fsync =3D off=94 = are the same as =93wal_sync_method =3D open_datasync=94=20 =20 What does this mean?=20 - Is the Windows system =93better=94 than the Debian system?=20 - Or is the underlying filesystem on the Windows system less = safe?=20 - Or is the Windows system better integrated with the Hyper-V = host? =20 The Windows systems reports that the write cache is switched on for the virtual disk. It is however not possible to switch is off.=20 =20 Thanks Klaus ------=_NextPart_000_0309_01D2D88C.12E0F740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> = -----Urspr=FCngliche = Nachricht-----

> Von: Tom Lane = [mailto:tgl@sss.pgh.pa.us]

> Gesendet: Montag, 29. Mai 2017 = 10:19

> An: Klaus P. Pieper

> Cc: = pgsql-admin@postgresql.org

> Betreff: Re: [ADMIN] pgbench Windows = outperforms Debian in Write tests

> = while Debian is faster in SELECT = only tests

>

> "Klaus P. Pieper" <kpi6288@gmail.com<= /a>> writes:

> > How can Windows = outperform Debian by a factor of 2?

> =

> Are you sure you have Windows = configured to fsync properly?

> Not = waiting for writes to hit disk would be a really easy explanation for = a

> discrepancy of this kind.

 

It seems = that it is indeed related to the wal_sync_method = settings.

 

Results = for 1 client read / write:

 

Option=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 Windows=A0=A0=A0=A0=A0=A0=A0 = Debian

fdatasync=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0=A0340=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 150

fsync=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0125=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A090

open_datasync=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 360 =A0=A0=A0=A0=A0 160

fsync_writethrough=A0=A0=A0=A0= =A0=A0=A0 115=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = n/a

open_sync=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 n/a=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 90

 

fsync =3D = off=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 360=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 400

 

The result = setting fsync=3Doff shows that the maximum performance of the Debian = syste is above Windows.

However, = with fsync=3Don, Windows still outperforms the Debian system with all = options.

 

In = addition, the results on the Windows system with “fsync =3D = off” are the same as “wal_sync_method =3D = open_datasync”

 

What does = this mean?

-          = Is the Windows system “better” than = the Debian system?

-          = Or is the underlying filesystem on the Windows = system less safe?

-          = Or is the Windows system better integrated with = the Hyper-V host?

 

The = Windows systems reports that the write cache is switched on for the = virtual disk. It is however not possible to switch is off. =

 

Thanks

Klaus

------=_NextPart_000_0309_01D2D88C.12E0F740--