Postgres Pro
Downloads
Home   >   mailing lists

Re: Disk Benchmarking Question - Mailing list pgsql-performance

From Dave Stibrany
Subject Re: Disk Benchmarking Question
Date
Msg-id CAK17JmnuD8x1JWO3d09hXcJbhfUFbm3m7rBhnzb=yuYT4MJi=Q@mail.gmail.com
Whole thread Raw
In response to Re: Disk Benchmarking Question  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-performance
Tree view
Thanks for the feedback guys. I'm looking forward to the day when we upgrade to SSDs.

For future reference, the bonnie++ numbers I was referring to are: 

Size: 63G

Sequential Output: 
------------------------
396505 K/sec
% CPU 21

Sequential Input: 
------------------------
401117 K/sec
% CPU 21

Random Seeks:
----------------------
650.7 /sec
% CPU 25

I think a lot of my confusion resulted from expecting sequential reads to be 4x the speed of a single disk because the disks are in RAID10. I'm thinking now that the 4x only applies to random reads.

On Sat, Mar 19, 2016 at 6:32 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
On Sat, Mar 19, 2016 at 4:29 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote:

> Given the size of your bonnie test set and the fact that you're using
> RAID-10, the cache should make little or no difference. The RAID
> controller may or may not interleave reads between all four drives.
> Some do, some don't. It looks to me like yours doesn't. I.e. when
> reading it's not reading all 4 disks at once, but just 2, 1 from each
> pair.

Point of clarification. It may be that if two processes are reading
the data set at once you'd get a sustained individual throughput that
matches what a single read can get.



--
THIS IS A TEST

pgsql-performance by date:

Previous
From: Andreas Joseph Krogh
Date:
Subject: Re: Searching GIN-index (FTS) and sort by timestamp-column
Next
From: Oleg Bartunov
Date:
Subject: Re: Searching GIN-index (FTS) and sort by timestamp-column