PostgreSQL 18'de async I/O varsayılan olarak açık — rehber, test etmeye değer ayarları anlatıyor

Async I/O zaten çalışıyor

PostgreSQL 18, bir asynchronous I/O alt sistemi getirdi ve varsayılan ayarlarla etkin şekilde geldiği için, yükseltilmiş bir sunucu bunu, kimse ayar yapmasa bile kullanıyor. Oleksandr Kuryzhev tarafından dev.to'da (aslen kuryzhev.cloud'da) yayımlanan pratik rehber de bu çerçeveden yola çıkıyor; yazar, yararlı sorunun özelliği etkinleştirmek olup olmadığı değil, hangi birkaç ayarın gerçek veriler üzerinde kontrollü bir testi hak ettiği olduğunu savunuyor.

Alt sistem neleri kapsıyor

18'den önce bir backend kernel'den bir blok istiyor ve bekliyordu; read-ahead ve posix_fadvise ipuçları yer yer yardımcı oluyordu ama okumalar backend'in bakış açısından senkron kalıyordu. Yeni alt sistem, bir backend'in birkaç okuma isteği gönderip işlemler sürerken çalışmaya devam etmesini sağlıyor.

Bunun nasıl gerçekleşeceğini iki şey belirliyor. io_method ayarı mekanizmayı seçiyor: varsayılan olan worker, okumaları adanmış I/O worker süreçlerine devrediyor; io_uring, Linux kernel'ının ring arayüzünü doğrudan backend'den kullanıyor; sync ise eski bloklayan davranışı koruyor. İkinci etken ise hangi kod yollarının bunu kullandığı. Makaleye göre başlıca yararlananlar sequential scan'ler, bitmap heap scan'ler ve vacuum; yazma işlemleri ve WAL bu değişikliğin parçası olmadığından yazma ağırlıklı OLTP çok az kazanç elde ediyor.

İlgili varsayılanlar da 18'de değişti: effective_io_concurrency ve maintenance_io_concurrency yükseltildi, dolayısıyla yükseltilmiş bir sunucu kimse bir ayara dokunmadan farklı davranabilir.

Kısa tavsiye

Yazarın pratik kuralı, iki koşul birlikte sağlanmadıkça io_method = worker ile devam etmek: Linux'ta olmanız ve kernel'ın ile PostgreSQL build'inin (liburing desteğiyle derlenmiş) io_uring'i etkinleştirmesi, ayrıca sorgularınızın okuma ağırlıklı ve working set'inin soğuk ya da büyük olması. İkisi de geçerliyse, worker ile io_uring'i A/B testinden geçirin, ardından io_workers, sonra effective_io_concurrency — her seferinde tek değişiklik. Sıcak veri shared_buffers'a ve OS cache'e sığıyorsa, az ya da hiç kazanç beklemeyin.

Yaygın hata biçimleri

Rehber dört tekrarlayan hatayı sıralıyor. Bir tuning parçacığını kopyalayıp birkaç değeri değiştirerek production'ı yeniden başlatmak, hangi ayarın yardımcı olduğunu, zarar verdiğini ya da hiçbir şey yapmadığını kimsenin bilememesine yol açıyor; olası bir gerileme, aşırı büyük worker sayısının CPU için sorgu backend'leriyle rekabet etmesi. Sıcak bir cache üzerinde benchmark yapmak, çakışacak okuma I/O'su kalmadığından her yöntemi aynı gösterirken, tek bir dropped-caches çalışması, çoğunlukla cache'lenmiş bir iş yükünde kararlı durum davranışı sanılabilir. io_uring'in basitçe hızlı seçenek olduğunu düşünmek, kernel desteğine, liburing etkin bir build'e ve syscall'lere izin veren bir runtime'a bağlı olduğunu göz ardı ediyor — varsayılan seccomp profilleri ve sertleştirilmiş hostlar io_uring'i sıkça kısıtlar, bu yüzden bir VM'de çalışan ayar bir container içinde başarısız olabilir. Son olarak, seçici index aramalarında, yazma ağırlıklı alımlarda ya da WAL'a bağlı iş yüklerinde kazanç beklemek, 18'in alt sisteminin bu yolları hedeflemediğini gözden kaçırıyor.

Doğru test nasıl yapılır

Önerilen prosedür bir baseline ile başlıyor: pg_settings'dan io_method, io_workers, io_max_concurrency, io_combine_limit, effective_io_concurrency, maintenance_io_concurrency ve track_io_timing değerlerini sorgulayın ve pg_stat_activity'de io worker süreçlerinin var olduğunu doğrulayın. track_io_timing'i etkinleştirin ki sayılar EXPLAIN çıktısında ve pg_stat_io'da görünsün; aday değişiklikleri kolayca geri alınabilmesi için bir drop-in config dosyasında hazırlayın. io_method ve io_max_concurrency yeniden başlatma gerektirirken, io_workers bir reload ile değiştirilebilir.

Test, soğuk cache'li, production dışı bir hostta yapılmalı — PostgreSQL'i yeniden başlatın ve OS page cache'i temizleyin — aynı sorguları EXPLAIN (ANALYZE, BUFFERS, SETTINGS) ile çalıştırın, her durumu birkaç kez tekrarlayın ve en iyi çalışmayı değil ortancaları karşılaştırın. Dikkat çekici bir ayrıntı: io_uring kullanılamıyorsa sunucu sessizce geri düşmek yerine başlamayı reddediyor; ya build'de liburing yoktur ya da kernel ya da seccomp syscall'leri engelliyordur.

Eşzamanlılık, depolama ve gözlemlenebilirlik

Bir yöntem seçildikten sonra eşzamanlılığı depolamaya göre ayarlayın. Düşük gecikmeli yerel NVMe çoğu zaman ağ depolamasından daha düşük eşzamanlılıkta faydalı sınırına ulaşırken, bulut block-store volume'ları IOPS ya da throughput tavanlarına kadar daha fazla bekleyen isteği ödüllendiriyor — gerçek tavan PostgreSQL değil o sınır olabilir. Worker modunda io_workers'ı CPU başına göre boyutlandırın, çünkü her worker backend'lerle rekabet eden bir süreçtir. Vacuum okumaları maintenance_io_concurrency tarafından yönetildiğinden, staging bir kopyada şişmiş bir tablonun vacuum'ı temiz ve yalıtılmış bir test olur.

Canlı gözlem için pg_aios view'ı uçuştaki I/O'yu gösteriyor (superuser ya da pg_read_all_stats gerektirir) ve pg_stat_io backend türü başına okuma hacmini ve süreyi raporluyor. Makale, 18'in read_bytes gibi byte sütunları eklediği uyarısını yapıyor; bu yüzden izleme sorguları PostgreSQL 18 dokümanına karşı doğrulanmalı.

Neden önemli

Async I/O, rutin bir büyük sürüm yükseltmesi sırasında örtük olarak devreye giren bir performans özelliği. Ayarları atlayan operatörler yine de yeni davranış elde ediyor — yeni varsayılanlar, yeni arka plan süreçleri, değişen I/O desenleri — dolayısıyla gerçek çıktı, aynı sorgular üzerinde bir önce/sonra karşılaştırması. Rehberin tek değişken, soğuk cache'ler ve ortanca sonuçlar disiplini, daha hızlı scan'ler hakkındaki bir manşeti kanıta dönüştüren şeydir ve production sistemlerini kimsenin bağlayamayacağı, ticket kaynaklı değişikliklerden korur. Kazançların cache'lenmemiş veri üzerindeki büyük sequential scan'lerde yoğunlaşmasını bekleyin; CPU'ya bağlı sorgular ve point lookup'lar kıpırdamaz.