Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1glqEV-0004av-3A for pgsql-admin@arkaria.postgresql.org; Tue, 22 Jan 2019 07:12:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1glqET-0003pu-QF for pgsql-admin@arkaria.postgresql.org; Tue, 22 Jan 2019 07:12:25 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1glqET-0003nw-D2 for pgsql-admin@lists.postgresql.org; Tue, 22 Jan 2019 07:12:25 +0000 Received: from mail-ot1-x341.google.com ([2607:f8b0:4864:20::341]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1glqER-00066V-17 for pgsql-admin@lists.postgresql.org; Tue, 22 Jan 2019 07:12:24 +0000 Received: by mail-ot1-x341.google.com with SMTP id 32so22718514ota.12 for ; Mon, 21 Jan 2019 23:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=/lY/lZJJuQBfTuBCT/dXPBCN4gcuP+xnJ5LjQmrXRRA=; b=okoRiiq3EYTxb/sKk5a1LQr4ku6Fex1UYY+CImM8gA3aURyFK5B10sYkwiYUTKzxo7 awIKWiBjP9WG9b8Av48dMBvUKmtFyAAqc3ODggJtcPBDtNXoAbCI8QeIYE7ou3rNPTeF 6RDJmqoNKWfDZVa+9VCKWQkUCSX0HCDHFYaFEvFAYFvR/saiI11+bn0W1yr18/XzFaZW jDIED3w1A9uR3rQqoEFTIp+S+13Z0RGpdxngpK4YWfa5uH9bINHLVTyCgpvXH4zr2Ry8 6ecB6gsEC2FaoTTmB78BIYggGhsNIGjQrcdozUxRbPrVpapd3NAkjD/F3fJN6VDhSrI0 +StA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=/lY/lZJJuQBfTuBCT/dXPBCN4gcuP+xnJ5LjQmrXRRA=; b=rmst6LWWgyY8C2ouuiKaVx7FhWznMZYzmcBmYQg/cKzytVYJud/skFZr8h+BiVZi04 Sy7yPWn4Y/EW+0E/S2I8au4Fum7agpm9UhGK2OmKJt+oTqVP24gdEJf3mfmk0C81SQvY 3K/jZBJ68bzHX5fC8AjtCaBmdIRa0vxZ+RV3ryOxagokMOT3LaFnGZ3hdiQJZqt/vPI1 +qFQ2TbSDYn+3NNyFSh2FvZgJ+oEgR2JcvraVzDfBPRUMQFnaVvIvdI2NireE0ahwc8H uaTzLM5JqtibeKgopbyji5KxGuJEcsOpsqS44p1Yv9tYUtb1N4dtW9zMpkKSX7bF67Yc jDcw== X-Gm-Message-State: AJcUukdmg2cAoRFUT3tY0dE2OLwu55Oyol2CKa5rD9PR85ZNgGFAUuw0 r3lGeIkqMWxh/Z34+A9rQ+sDyxaW X-Google-Smtp-Source: ALg8bN41ZnOlBOT0tOgaCTL6CiQ6PhR6IzhTp45McCvxhI/9VSGnhB9ntl/R9odHvaNT5CYi/H1XUg== X-Received: by 2002:a9d:1b0:: with SMTP id e45mr22523091ote.16.1548141141932; Mon, 21 Jan 2019 23:12:21 -0800 (PST) Received: from [192.168.1.10] (ip70-171-116-89.no.no.cox.net. [70.171.116.89]) by smtp.googlemail.com with ESMTPSA id c7sm6291147otf.59.2019.01.21.23.12.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Jan 2019 23:12:21 -0800 (PST) Subject: Re: IO scheduler recommendation To: pgsql-admin@lists.postgresql.org References: From: Ron Message-ID: <612605b8-c94b-68a3-3e8f-0134ddcfe71d@gmail.com> Date: Tue, 22 Jan 2019 01:12:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F5282FBF400CB9E1F7897EB6" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------F5282FBF400CB9E1F7897EB6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Isn't the use of NFS pretty high on the "things not to do with Postgres" list? On 1/22/19 12:13 AM, Tim Cross wrote: > I suspect the main reason there are no official recommendations is because > setting the IO scheduler is a  low level optimisation, getting very close > to a 'mciro-optimisation' compared to other areas of optimisation.  Some > even consider playing at this level to be somewhat of a black art - > primarily because it is very complicated and dependent on many, many > variables (hardware, use profile, data profile etc). For these reasons, I > doubt there is a clear 'winner' for PG (especially as PG doesn't do direct > IO to disk like Oracle does).  I suspect the fact your using NFS will > overshadow any differences with the IO scheduling algorithm as well.  > Regardless, the only reliable way to select the best algorithm would be > extensive benchmarking using realistic data and usage profiles. > > On Tue, 22 Jan 2019 at 16:38, AB_ba# > wrote: > > Thanks Laurenz > Surprise to know that there are no official recommendation from > PostgreSQL. > > On Mon, Jan 21, 2019 at 9:14 PM Laurenz Albe > wrote: > > AB_ba# wrote: > > I searched the complete PostgreSQL Documentation but didn't get > anything with respect to IO scheduler recommendation. > > What is being recommended by PostgreSQL ? > > There is no clear recommendation. > > I personally have seen workloads where changing from "cfq" to > "deadline" > or "noop" improved performance by a factor of 4, but on many > systems "cfq" > seems to be doing at least as good as the others. > > I believe that it depends a lot on your hardware configuration and > your workload, and you are best advised to run a realistic load test. > > > Which is the best IO scheduler considering the Data is hosted on > NFS? > > No idea - probably depends on what is behind the NFS. > > Make sure to use hard, fg mounts. > If you can, use "jumbo frames" so that an 8KB block can fit into > a single IP frame. > > Yours, > Laurenz Albe > -- > Cybertec | https://www.cybertec-postgresql.com > > > > -- > Thanks and Regards > ANUP BHARTI > > > > -- > regards, > > Tim > > -- > Tim Cross > -- Angular momentum makes the world go 'round. --------------F5282FBF400CB9E1F7897EB6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Isn't the use of NFS pretty high on the "things not to do with Postgres" list?

On 1/22/19 12:13 AM, Tim Cross wrote:
I suspect the main reason there are no official recommendations is because setting the IO scheduler is a  low level optimisation, getting very close to a 'mciro-optimisation' compared to other areas of optimisation.  Some even consider playing at this level to be somewhat of a black art - primarily because it is very complicated and dependent on many, many variables (hardware, use profile, data profile etc). For these reasons, I doubt there is a clear 'winner' for PG (especially as PG doesn't do direct IO to disk like Oracle does).  I suspect the fact your using NFS will overshadow any differences with the IO scheduling algorithm as well.  Regardless, the only reliable way to select the best algorithm would be extensive benchmarking using realistic data and usage profiles. 

On Tue, 22 Jan 2019 at 16:38, AB_ba# <bharti.anup@gmail.com> wrote:
Thanks Laurenz
Surprise to know that there are no official recommendation from PostgreSQL.

On Mon, Jan 21, 2019 at 9:14 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
AB_ba# wrote:
> I searched the complete PostgreSQL Documentation but didn't get anything with respect to IO scheduler recommendation.
> What is being recommended by PostgreSQL ?

There is no clear recommendation.

I personally have seen workloads where changing from "cfq" to "deadline"
or "noop" improved performance by a factor of 4, but on many systems "cfq"
seems to be doing at least as good as the others.

I believe that it depends a lot on your hardware configuration and
your workload, and you are best advised to run a realistic load test.

> Which is the best IO scheduler considering the Data is hosted on NFS?

No idea - probably depends on what is behind the NFS.

Make sure to use hard, fg mounts.
If you can, use "jumbo frames" so that an 8KB block can fit into
a single IP frame.

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com



--
Thanks and Regards
ANUP BHARTI


--
regards,

Tim

--
Tim Cross


--
Angular momentum makes the world go 'round.
--------------F5282FBF400CB9E1F7897EB6--