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 ..
Re: [HACKERS] lseek/read/write overhead becomes visible at scale .. |
Список | 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 по дате отправления: