![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2025\/11\/7346573-300x300.png\")
<\/p>\n
<\/p>\n
Le 25 septembre dernier, PostgreSQL sortait sa toute derni\u00e8re version, PostgreSQL 18.
\nCette version apporte de nombreux correctifs mais aussi des nouveaut\u00e9s et des am\u00e9liorations sur les performances globales.<\/p>\n
Une nouveaut\u00e9 est particuli\u00e8rement pertinente pour cette version. Il s’agit des “asynchronous IO” (AIO).<\/p>\n
Une lecture en mode synchrone se fait lorsque PostgreSQL demande au kernel l’acc\u00e8s \u00e0 une page disque. PostgreSQL attend alors sa mise \u00e0 disposition pour \u00eatre trait\u00e9e et mont\u00e9e en m\u00e9moire partag\u00e9e.
\nL’OS \u00e9coute la requ\u00eate de la part de PostgreSQL et ne peut anticiper les \u00e9ventuelles demandes.
\nDans ce contexte, PostgreSQL est tr\u00e8s d\u00e9pendant des performances disques avec d’\u00e9ventuels “bottlenecks”.<\/p>\n
Avec le mode asynchrone IO, l’OS est capable de traiter en parall\u00e8le les demandes faites par PostgreSQL et peut donc facilement travailler sur plusieurs requ\u00eates en lecture.<\/p>\n
<\/p>\n
Synchronous IO\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Asynchronous IO<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2025\/11\/synch_IO.jpg\")
\u00a0 \u00a0![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2025\/11\/asynch_IO.jpg\")
<\/p>\n
<\/p>\n
<\/p>\n
Un premier travail avait \u00e9t\u00e9 fait avec les versions r\u00e9centes de PostgreSQL afin de faire du “prefetch” de donn\u00e9es via la m\u00e9thode syst\u00e8me “posix_fadvise<\/a>“, ceci permettait d’anticiper les d\u00e9clarations d’acc\u00e8s \u00e0 certaines donn\u00e9es ou pages de fichiers en d\u00e9clarant un offset de d\u00e9part et une longueur d\u00e9fini. Ceci \u00e9vite des allers-retours sur le m\u00eame fichier traitant des pages contigu\u00ebs. Avec les asynchronous IO, PostgreSQL est particuli\u00e8rement performant lors des lectures s\u00e9quentielles (seq scans, bitmap heap scan). <\/p>\n <\/p>\n Avec la version 18, PostgreSQL met l’accent sur les lectures asynchrones avec de nouveaux param\u00e8tres.<\/p>\n io_method<\/b> qui peut prendre 3 valeurs diff\u00e9rentes<\/p>\n <\/p>\n io_worker<\/strong> repr\u00e9sentant le nombre de process en parall\u00e8le qui vont traiter les demandes de mise en cache des pages. effective_io_concurrency<\/strong> est d\u00e9j\u00e0 pr\u00e9sent sur les anciennes versions de PostgreSQL. Cependant, dans le cas des IO asychrones (io_method=worker ou io_methode=io_uring), les IO se font en concurrence directement dans PostgreSQL.<\/p>\n io_combine_limit<\/strong> est la taille maximale d’IO.<\/p>\n <\/p>\n <\/p>\n V\u00e9rifier que votre serveur Linux est compatible avec la m\u00e9thode “io_uring”. Pour cela ex\u00e9cuter cette commande, qui doit vous renvoyer 0<\/p>\n <\/p>\n Sinon, forcer la valeur \u00e0 0, sous “root”.<\/p>\n <\/p>\n La validation peut se faire \u00e9galement sur la configuration du kernel au d\u00e9marrage<\/p>\n <\/p>\n <\/p>\n Pour utiliser le mode “io_method=io_uring<\/span><\/strong>“, il faudra compiler PostgreSQL 18 avec ce mode -> with-liburing<\/strong>.<\/p>\n Il faut donc r\u00e9cup\u00e9rer les sources depuis le site officiel PostgreSQL<\/a><\/p>\n Puis configurer avec l’option suivante :<\/p>\n <\/p>\n <\/p>\n Pour nos tests, nous utilisons l’outil “pgbench”. Attention, chaque test se fait avec donn\u00e9es “\u00e0 froid”. Le cache est vid\u00e9 \u00e0 chaque interrogation. C’est \u00e0 la premi\u00e8re ex\u00e9cution que le test est le plus repr\u00e9sentatif car PostgreSQL n’a pas de pages dans son cache et doit donc solliciter le kernel.<\/p>\n <\/p>\n <\/p>\n La suite consiste \u00e0 lancer un “SELECT COUNT” sur la table “pgbench_accounts” et relever les temps d’ex\u00e9cution entre les diff\u00e9rentes versions de PostgreSQL et les diff\u00e9rentes m\u00e9thodes de lectures asynchrones.<\/p>\n <\/p>\n <\/p>\n Nous mettons un peu plus de 49 secondes pour compter les 50M de lignes de la table.<\/p>\n le plan d’ex\u00e9cution est le suivant<\/p>\n <\/p>\n Le “parallel seq scan” sur “pgbench_accounts” est fait avec 2 workers en parall\u00e8le.<\/p>\n <\/p>\n <\/p>\n Avec la valeur “io_methode=sync<\/strong>“, nous retrouvons \u00e0 peu pr\u00e8s le m\u00eame temps, m\u00eame si notre serveur sur PostgreSQL 18 est peu plus puissant et dispose de plus de RAM.Le “shared_buffer” a \u00e9t\u00e9 taill\u00e9 en cons\u00e9quence.<\/p>\n <\/p>\n <\/p>\n le plan est \u00e0 peu pr\u00e8s le m\u00eame avec nos 2 workers effectuant du “parallel seq scan” sur “pgbench_accounts”.<\/p>\n <\/p>\n <\/p>\n Avec “io_method=worker<\/strong>” = 3, l\u00e0, nous gagnons d\u00e9j\u00e0 quelques secondes en terme de temps d’ex\u00e9cution puisque notre requ\u00eate est proche des 40 sec.<\/p>\n Puis avec “io_method=io_uring<\/strong>“, c’est l\u00e0 que nous sommes le plus performant puisque nous descendons \u00e0 moins de 25 secondes.<\/p>\n <\/p>\n Nous obtenons les r\u00e9sultats suivants<\/p>\n <\/p>\n <\/p>\n <\/p>\n A noter que pendant des op\u00e9rations de lectures asynchrones, nous pouvons suivre l’\u00e9volution de celles ci via la vue ‘pg_aios<\/strong>” mise \u00e0 disposition par PostgreSQL.<\/p>\n <\/p>\n <\/p>\n Cette vue est aliment\u00e9e via la fonction ‘pg_get_aios”<\/strong>.<\/p>\n Nous pouvons voir l’offset de la page sur laquelle la lecture pointe ainsi que la longueur de l’op\u00e9ration IO en cours.<\/p>\n Pour profiter de l’efficacit\u00e9 des lectures asynchrones, ne pas oublier de configurer la valeur de “io_method<\/strong>” \u00e0 “worker<\/strong>” ou “io_uring\u00a0<\/strong><\/p>\n A volumes \u00e9quivalents, les plans d’ex\u00e9cutions nous permettent de voir que l’on traite un nombre de “shared read” similaire entre PostgreSQL 18 qu’avec PostgreSQL 17 mais avec un temps plus faible pour PostgreSQL 18.<\/p>\n Attention cependant, les gains sont effectifs sur les op\u00e9rations de type “seq scan” ou “bitmap heap scan”. Pas de gain possible sur des op\u00e9rations d’\u00e9critures.<\/p>\n En d’autres termes, la configuration Asynchrones IO sera parfaitement adapt\u00e9e pour des requ\u00eates d\u00e9cisionnelles avec datawarehouse volumineux.<\/p>\n Autre point \u00e0 savoir, il a \u00e9t\u00e9 relev\u00e9 \u00e9galement des risques en terme de s\u00e9curit\u00e9 avec le mode io_uring<\/strong> configur\u00e9 dans le kernel. Sur l’article Wikip\u00e9dia<\/a> d\u00e9di\u00e9 \u00e0 “io_uring<\/strong>“, il est d’ailleurs not\u00e9 -><\/p>\n “In June 2023, Google’s security team reported that 60% of the\u00a0exploits<\/a>\u00a0submitted to their\u00a0bug bounty program<\/a>\u00a0in 2022 were exploits of the Linux kernel’s io_uring vulnerabilities. As a result,\u00a0 <\/p>\n Bonne fin de journ\u00e9e !<\/p>\n Le 25 septembre dernier, PostgreSQL sortait sa toute derni\u00e8re version, PostgreSQL 18. Cette version apporte de nombreux correctifs mais aussi des nouveaut\u00e9s et des am\u00e9liorations sur les performances globales. Une nouveaut\u00e9 est particuli\u00e8rement pertinente pour cette version. Il s’agit… Continuer la lecture
\nMalheureusement, avec PostgreSQL, ce m\u00e9canisme ne permet pas de monter les pages dans le “shared_buffer<\/strong>“, mais s’appuie sur le cache disque.<\/p>\n
\nUn parall\u00e8le peut \u00eatre fait avec le m\u00e9canisme d’offloading fait par Oracle Exadata et les “smart scans” mont\u00e9s directement vers la PGA.<\/p>\nParam\u00e9trage<\/h2>\n
\n
\nJe vous invite \u00e0 lire cet article<\/a> pour plus de pr\u00e9cisions sur ce m\u00e9canisme.<\/li>\n<\/ul>\n
\nPar d\u00e9faut, le nombre est de 3, mais nous pouvons monter au-del\u00e0.<\/p>\nSyst\u00e8me<\/span><\/h4>\n
$ cat \/proc\/sys\/kernel\/io_uring_disabled\r\n0<\/pre>\n
# echo 0 > \/proc\/sys\/kernel\/io_uring_disabled<\/pre>\n
# cat \/boot\/config-6.12.48+deb13-cloud-amd64 | grep -i io_uring\r\nCONFIG_IO_URING=y<\/pre>\n
PostgreSQL<\/span><\/h4>\n
# .\/configure --with-liburing\r\n# make\r\n# make install\r\n<\/pre>\n
Benchmark<\/h2>\n
\nNous allons cr\u00e9er un jeu de test avec un facteur de 500 sur le nombre de lignes cr\u00e9\u00e9es par d\u00e9faut dans les tables. Notre plus grosse table “pgbench_accounts” devrait donc d\u00e9passer les 50M de lignes.<\/p>\n$ pgbench -i pgbench -s 500\r\ndropping old tables...\r\nNOTICE: table "pgbench_accounts" does not exist, skipping\r\nNOTICE: table "pgbench_branches" does not exist, skipping\r\nNOTICE: table "pgbench_history" does not exist, skipping\r\nNOTICE: table "pgbench_tellers" does not exist, skipping\r\ncreating tables...\r\ngenerating data (client-side)...\r\nvacuuming...\r\ncreating primary keys...\r\ndone in 42.40 s (drop tables 0.00 s, create tables 0.01 s, client-side generate 25.13 s, vacuum 3.35 s, primary keys 13.92 s).<\/pre>\n
PostgreSQL 17<\/h4>\n
$ select count(abalance) from "pgbench_accounts";\r\ncount\r\n----------\r\n50000000\r\n(1 row)\r\n\r\nTime: 48937.120 ms (00:48.937)<\/pre>\n
$ explain (analyze, buffers) select count(abalance) from "pgbench_accounts";\r\nQUERY PLAN\r\n-------------------------------------------------------------------------------------------------------------------------------------------------------------\r\nFinalize Aggregate (cost=1081089.88..1081089.89 rows=1 width=8) (actual time=69053.114..69053.219 rows=1 loops=1)\r\nBuffers: shared hit=2518 read=817155\r\n- Gather (cost=1081089.67..1081089.88 rows=2 width=8) (actual time=69051.505..69053.209 rows=3 loops=1)\r\nWorkers Planned: 2\r\nWorkers Launched: 2\r\nBuffers: shared hit=2518 read=817155\r\n- Partial Aggregate (cost=1080089.67..1080089.68 rows=1 width=8) (actual time=69021.569..69021.571 rows=1 loops=3)\r\nBuffers: shared hit=2518 read=817155\r\n- Parallel Seq Scan on pgbench_accounts (cost=0.00..1028006.33 rows=20833333 width=4) (actual time=4.259..41669.680 rows=16666667 loops=3)\r\nBuffers: shared hit=2518 read=817155\r\nPlanning Time: 0.056 ms\r\nExecution Time: 69053.251 ms<\/pre>\n
PostgreSQL 18<\/h4>\n
pgbench=# select count(abalance) from "pgbench_accounts";\r\ncount\r\n----------\r\n10000000\r\n(1 row)\r\n\r\nTime: 49704.009 ms (00:49.704)<\/pre>\n
- Parallel Seq Scan on public.pgbench_accounts (cost=0.00..205601.67 rows=4166667 width=4) (actual time=0.838..42937.512 rows=3333333.33 loops=3)\r\nOutput: aid, bid, abalance, filler\r\nBuffers: shared read=163935\r\nBuffers: shared read=54826<\/pre>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2025\/11\/temps-2.jpg\")
<\/p>\n$ select * from pg_aios;\r\npid | io_id | io_generation | state | operation | off | length | target | handle_data_len | raw_result | result | target_desc | f_sync | f_localmem | f_buffered\r\n-------+-------+---------------+-----------+-----------+-----------+--------+--------+-----------------+------------+---------+--------------------------------------------------+--------+------------+------------\r\n41329 | 192 | 9233 | SUBMITTED | readv | 570818560 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200752..200767 in file "base\/16440\/16456" | f | f | t\r\n41329 | 193 | 9290 | SUBMITTED | readv | 570556416 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200720..200735 in file "base\/16440\/16456" | f | f | t\r\n41329 | 194 | 9239 | SUBMITTED | readv | 570949632 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200768..200783 in file "base\/16440\/16456" | f | f | t\r\n41329 | 195 | 9229 | SUBMITTED | readv | 570687488 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200736..200751 in file "base\/16440\/16456" | f | f | t\r\n41329 | 197 | 9225 | SUBMITTED | readv | 571473920 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200832..200847 in file "base\/16440\/16456" | f | f | t\r\n41329 | 198 | 6372 | SUBMITTED | readv | 569638912 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200608..200623 in file "base\/16440\/16456" | f | f | t\r\n41329 | 200 | 6420 | SUBMITTED | readv | 571080704 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200784..200799 in file "base\/16440\/16456" | f | f | t\r\n41329 | 201 | 9247 | SUBMITTED | readv | 571211776 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200800..200815 in file "base\/16440\/16456" | f | f | t\r\n41329 | 202 | 9248 | SUBMITTED | readv | 571604992 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200848..200863 in file "base\/16440\/16456" | f | f | t\r\n41329 | 203 | 9221 | SUBMITTED | readv | 569769984 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200624..200639 in file "base\/16440\/16456" | f | f | t\r\n41329 | 207 | 9223 | SUBMITTED | readv | 569507840 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200592..200607 in file "base\/16440\/16456" | f | f | t\r\n41329 | 208 | 9226 | SUBMITTED | readv | 571736064 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200864..200879 in file "base\/16440\/16456" | f | f | t\r\n41329 | 210 | 282085 | SUBMITTED | readv | 571342848 | 131072 | smgr | 16 | NULL | UNKNOWN | blocks 200816..200831 in file "base\/16440\/16456" | f | f | t\r\n(13 rows)<\/pre>\n
Conclusion<\/h2>\n
\nCertains sites comme celui-ci<\/a> font \u00e9tats de potentiels processus de type “malwares” qui pourraient s’attaquer au kernel et mettre en p\u00e9ril la s\u00e9curit\u00e9 du serveur.<\/p>\nio_uring<\/code>\u00a0was disabled for apps in\u00a0Android<\/a>, and disabled entirely in\u00a0ChromeOS<\/a>\u00a0as well as Google servers.[<\/span>11]<\/span><\/a><\/sup>\u00a0Docker<\/a>\u00a0also consequently disabled io_uring from their default\u00a0seccomp<\/a> profile”<\/em><\/p>\n<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"