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 по дате отправления: