From: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
---|---|
To: | Hannu Krosing <hannu(at)2ndquadrant(dot)com> |
Cc: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Testing Sandforce SSD |
Date: | 2010-08-03 11:19:57 |
Message-ID: | 4C57FB5D.1020006@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hannu Krosing wrote:
> Did it fit in shared_buffers, or system cache ?
>
Database was ~5GB, server has 16GB, shared buffers was set to 1920MB.
> I first noticed this several years ago, when doing a COPY to a large
> table with indexes took noticably longer (2-3 times longer) when the
> indexes were in system cache than when they were in shared_buffers.
>
I read this as a hint: try increasing shared_buffers. I'll redo the
pgbench run with increased shared_buffers.
>> so the test is actually how fast the ssd can capture
>> sequential WAL writes and fsync without barriers, mixed with an
>> occasional checkpoint with random write IO on another partition). Since
>> the WAL writing is the same for both block_size setups, I decided to
>> compare random writes to a file of 5GB with Oracle's Orion tool:
>>
>
> Are you sure that you are not writing full WAL pages ?
>
I'm not sure I understand this question.
> Do you have any stats on how much WAL is written for 8kb and 4kb test
> cases ?
>
Would some iostat -xk 1 for each partition suffice?
> And for other disk i/o during the tests ?
>
Not existent.
regards,
Yeb Havinga
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-08-03 14:02:19 | Re: Testing Sandforce SSD |
Previous Message | Hannu Krosing | 2010-08-03 09:08:42 | Re: Testing Sandforce SSD |