From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Pietro Pugni <pietro(dot)pugni(at)gmail(dot)com> |
Cc: | "Wes Vaske (wvaske)" <wvaske(at)micron(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Suggestions for a HBA controller (6 x SSDs + madam RAID10) |
Date: | 2017-03-03 15:03:04 |
Message-ID: | CAHyXU0w7sGzk1GXTz3-ew1DTGY8fZ-vAQ4E0FJPG1MyG4CKkZw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Mar 2, 2017 at 3:51 PM, Pietro Pugni <pietro(dot)pugni(at)gmail(dot)com> wrote:
> The HBA provided slightly better performance without removing the expander
> and even more slightly faster after removing the expander, but then I tried
> increasing numjob from 1 to 16 (tried also 12, 18, 20, 24 and 32 but found
> 16 to get higher iops) and the benchmarks returned expected results. I guess
> how this relates with Postgres.. probably effective_io_concurrency, as
> suggested by Merlin Moncure, should be the counterpart of numjob in fio?
Kind of. effective_io_concurrency allows the database to send >1
filesystem commands to the hardware from a single process. Sadly,
only certain classes of query can currently leverage this factility --
as you can see, it's a huge optimization.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-03-03 15:19:48 | Re: Performance issue in PostgreSQL server... |
Previous Message | Dinesh Chandra 12108 | 2017-03-03 12:44:07 | Re: Performance issue in PostgreSQL server... |