Re: Using pgiosim realistically

Поиск
Список
Период
Сортировка
От Jeff
Тема Re: Using pgiosim realistically
Дата
Msg-id B15C84A0-369F-4F29-B3F3-A85C3107DDBD@torgo.978.org
обсуждение исходный текст
Ответ на Re: Using pgiosim realistically  (John Rouillard <rouilj@renesys.com>)
Ответы Re: Using pgiosim realistically  (John Rouillard <rouilj@renesys.com>)
Список pgsql-performance
On May 16, 2011, at 9:17 AM, John Rouillard wrote:

>>>
>>> I am seeing really poor (70) iops with pgiosim.  According to:
>>> http://www.tomshardware.com/reviews/2tb-hdd-7200,2430-8.html in the
>>> database benchmark they are seeing ~170 iops on a single disk for
>>> these drives. I would expect an 8 disk raid 10 should get better
>>> then
>>> 3x the single disk rate (assuming the data is randomly distributed).
>> Those drives are 7200 rpm drives which would give you a maximum write
>> rate of 120/sec at best with the cache disabled. I actually think
>> your
>> 70/sec is closer to reality and what you should anticipate in real
>> use.
>> I do not see how they could make 170/sec. Did they strap a jet
>> engine to
>> the drive. :)
>

also you are reading with a worst case scenario for the mechanical
disk - randomly seeking around everywhere, which will lower
performance drastically.

> Hmm, I stated the disk cache was disabled. I should have said the disk
> write cache, but it's possible the readhead cache is disabled as well
> (not quite sure how to tell on the lsi cards). Also there isn't a lot
> of detail in what the database test mix is and I haven't tried
> researching the site to see if the spec the exact test. If it included
> a lot of writes and they were being handled by a cache then that could
> explain it.
>

you'll get some extra from the os readahead and the drive's potential
own readahead.


> However, in my case I have an 8 disk raid 10 with a read only load (in
> this testing configuration). Shouldn't I expect more iops than a
> single disk can provide? Maybe pgiosim is hitting some other boundary
> than just i/o?
>

given your command line you are only running a single thread - use the
-t argument to add more threads and that'll increase concurrency.  a
single process can only process so much at once and with multiple
threads requesting different things the drive will actually be able to
respond faster since it will have more work to do.
I tend to test various levels - usually a single (-t 1 - the default)
to get a base line, then -t (drives / 2), -t (#drives) up to probably
4x drives (you'll see iops level off).

> Also it turns out that pgiosim can only handle 64 files. I haven't
> checked to see if this is a compile time changable item or not.
>

that is a #define in pgiosim.c

also, are you running the latest pgiosim from pgfoundry?

the -w param to pgiosim has it rewrite blocks out as it runs. (it is a
percentage).

--
Jeff Trout <jeff@jefftrout.com>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/




В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: reducing random_page_cost from 4 to 2 to force index scan
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: reducing random_page_cost from 4 to 2 to force index scan