Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..
Дата
Msg-id 20170124183613.cbb47nqbvso4rvjb@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..  (Tobias Oberstein <tobias.oberstein@gmail.com>)
Ответы Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..  (Andres Freund <andres@anarazel.de>)
Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..  (Tobias Oberstein <tobias.oberstein@gmail.com>)
Список pgsql-hackers
Tobias Oberstein wrote:

> I am benchmarking IOPS, and while doing so, it becomes apparent that at
> these scales it does matter _how_ IO is done.
> 
> The most efficient way is libaio. I get 9.7 million/sec IOPS with low CPU
> load. Using any synchronous IO engine is slower and produces higher load.
> 
> I do understand that switching to libaio isn't going to fly for PG
> (completely different approach).

Maybe it is possible to write a new f_smgr implementation (parallel to
md.c) that uses libaio.  There is no "seek" in that interface, at least,
though the interface does assume that the implementation is blocking.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Tobias Oberstein
Дата:
Сообщение: Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..
Следующее
От: Corey Huinker
Дата:
Сообщение: Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)