Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wa4OO-0003xD-L0 for pgsql-performance@arkaria.postgresql.org; Tue, 15 Apr 2014 14:31:20 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Wa4OO-00044m-0I for pgsql-performance@arkaria.postgresql.org; Tue, 15 Apr 2014 14:31:20 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wa4OM-00044f-KX for pgsql-performance@postgresql.org; Tue, 15 Apr 2014 14:31:18 +0000 Received: from mail-bn1lp0144.outbound.protection.outlook.com ([207.46.163.144] helo=na01-bn1-obe.outbound.protection.outlook.com) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Wa4OD-0004rf-4D for pgsql-performance@postgresql.org; Tue, 15 Apr 2014 14:31:17 +0000 Received: from BN1PR05MB009.namprd05.prod.outlook.com (10.255.202.141) by BN1PR05MB010.namprd05.prod.outlook.com (10.255.202.143) with Microsoft SMTP Server (TLS) id 15.0.918.8; Tue, 15 Apr 2014 14:31:06 +0000 Received: from BN1PR05MB009.namprd05.prod.outlook.com ([169.254.15.209]) by BN1PR05MB009.namprd05.prod.outlook.com ([169.254.15.209]) with mapi id 15.00.0918.000; Tue, 15 Apr 2014 14:31:06 +0000 From: Mel Llaguno To: desmodemone CC: "pgsql-performance@postgresql.org" Subject: Re: HFS+ pg_test_fsync performance Thread-Topic: [PERFORM] HFS+ pg_test_fsync performance Thread-Index: AQHPWDFwlR15YRY8f0KSgkk6+/NESpsSmSGAgAAjMSA= Date: Tue, 15 Apr 2014 14:31:05 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [184.70.198.10] x-forefront-prvs: 0182DBBB05 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(51914003)(199002)(189002)(81542001)(87936001)(16236675002)(86362001)(76482001)(50986999)(76176999)(46102001)(54356999)(92566001)(2656002)(76576001)(80022001)(4396001)(15975445006)(1411001)(79102001)(99286001)(99396002)(74662001)(74502001)(77982001)(31966008)(66066001)(20776003)(74316001)(83322001)(83072002)(85852003)(19580395003)(33646001)(80976001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB010; H:BN1PR05MB009.namprd05.prod.outlook.com; FPR:B016F87E.C7340C7.72FAB1B8.84EAB918.201AA; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: coverity.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_e36bb23bb5f9457ebee6bee8c767ca23BN1PR05MB009namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: coverity.com X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --_000_e36bb23bb5f9457ebee6bee8c767ca23BN1PR05MB009namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My 2 cents : The results are not surprising, in the linux enviroment the i/o call of pg_= test_fsync are using O_DIRECT (PG_O_DIRECT) with also the O_SYNC or O_DSY= NC calls, so ,in practice, it is waiting the "answer" from the storage bypa= ssing the cache in sync mode, while in the Mac OS X it is not doing so, i= t's only using the O_SYNC or O_DSYNC calls without O_DIRECT, in practice, = it's using the cache of filesystem , even if it is asking the sync of io ca= lls. Bye Mat Dba -------- Thanks for the explanation. Given that OSX always seems to use filesystem c= ache, is there a way to measure fsync performance that is equivalent to Lin= ux? Or will the use of pg_test_fsync always be inflated under OSX? The reas= on I ask is that we would like to make a case with a customer that PG perfo= rmance on OSX/HFS+ would be sub-optimal compared to using Linux/EXT4 (or Fr= eeBSD/UFS2 for that matter). Thanks, Mel --_000_e36bb23bb5f9457ebee6bee8c767ca23BN1PR05MB009namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


My 2 cents :

The results are not surprising, in the linux env= iroment the i/o call of pg_test_fsync  are using O_DIRECT  (PG_O_= DIRECT) with also the O_SYNC or O_DSYNC calls, so ,in practice, it is waiti= ng the "answer" from the storage bypassing the cache  in sync mode, while in  the Mac OS X it is not doing so, = it's only using the O_SYNC or O_DSYNC calls without O_DIRECT,  in prac= tice, it's using the cache of filesystem , even if it is asking the sync of= io calls.


Bye

Mat Dba

--------

Thanks for the explanation. Given that OSX alway= s seems to use filesystem cache, is there a way to measure fsync performanc= e that is equivalent to Linux? Or will the use of pg_test_fsync always be i= nflated under OSX? The reason I ask is that we would like to make a case with a customer that PG performance o= n OSX/HFS+ would be sub-optimal compared to using Linux/EXT4 (or FreeBS= D/UFS2 for that matter).

Thanks, Mel
--_000_e36bb23bb5f9457ebee6bee8c767ca23BN1PR05MB009namprd05pro_--