Postgres 18 का इंतज़ार: asynchronous I/O से disk read speed में सुधार

 (pganalyze.com)
4 पॉइंट द्वारा GN⁺ 2025-05-08 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • अभी beta1 में मौजूद Postgres 18, asynchronous I/O (Asynchronous I/O) सपोर्ट जोड़ता है, जिससे खासकर cloud environment में read performance काफी बेहतर होती है
  • नई setting io_method के जरिए पारंपरिक sync method के अलावा worker और io_uring methods चुने जा सकते हैं
  • AWS benchmark नतीजों के अनुसार, io_uring इस्तेमाल करने पर disk read performance अधिकतम 3 गुना तक बेहतर हुई
  • लेकिन asynchronous processing की वजह से मौजूदा query analysis (EXPLAIN ANALYZE) में I/O timing को समझना और कठिन हो जाता है
  • नई monitoring view (pg_aios) और tuning parameter (effective_io_concurrency) के जरिए performance optimization की जरूरत है

Postgres 18 में asynchronous I/O की शुरुआत

  • परंपरागत रूप से Postgres blocking I/O model का उपयोग करता है, जिसमें हर disk read पूरा होने तक इंतज़ार करना पड़ता है
  • network-based storage (जैसे EBS) में अधिक latency के कारण cloud environment में bottleneck पैदा होता है
  • asynchronous I/O से कई disk reads को parallel में process करना संभव होता है, जिससे CPU utilization और overall throughput बढ़ता है

Postgres 17 की तैयारी: Read Stream API

  • Postgres 17 में read_stream API जोड़ा गया, जिससे read operations की abstraction को standardize किया गया
  • लेकिन यह अभी भी OS page cache पर निर्भर रहता है और Postgres के अपने shared buffer में सीधे reflect नहीं होता
  • Postgres 18 में kernel hint के बजाय direct asynchronous reads संभव हो जाती हैं

नई setting: io_method

  • Postgres 18, postgresql.conf में io_method setting जोड़ता है, और निम्न 3 options देता है:

io_method = sync

  • मौजूदा Postgres जैसा ही synchronous तरीका
  • posix_fadvise() आधारित read-ahead request method का उपयोग

io_method = worker (default)

  • I/O के लिए dedicated worker processes asynchronous तरीके से data पढ़ते हैं और उसे shared buffer तक पहुंचाते हैं
  • main process read operation के दौरान बिना रुके चलता रह सकता है
  • default worker count 3 है, जिसे io_workers setting से बदला जा सकता है

io_method = io_uring

  • Linux kernel 5.1 या उससे ऊपर में उपलब्ध high-performance I/O interface
  • worker process के बिना भी kernel के साथ shared ring buffer के जरिए direct asynchronous read कर सकता है
  • इसके लिए नया kernel, filesystem और उपयुक्त configuration चाहिए

asynchronous I/O का performance benchmark (AWS के आधार पर)

  • test environment:
    • AWS c7i.8xlarge (32 vCPU, 64GB RAM)
    • 100GB io2 EBS, 20,000 IOPS
    • 3.5GB आकार की table पर SELECT COUNT(*) चलाया गया

Cold cache performance comparison:

संस्करण/setting execution time (ms)
Postgres 17 (sync) 15,831
Postgres 18 (sync) 15,071
Postgres 18 (worker) 10,052
Postgres 18 (io_uring) 5,723
  • io_uring, sync की तुलना में 2.8 गुना performance improvement देता है
  • cloud में disk latency कम करने में खास तौर पर प्रभावी

effective_io_concurrency tuning

  • Postgres 18 में यह parameter internal asynchronous read-ahead requests की संख्या को प्रभावित करता है
  • default value 1 → 16 कर दी गई है, और io_combine_limit के साथ गुणा होकर अधिकतम read range तय होती है
  • high-latency cloud environments में बड़ी value फायदेमंद हो सकती है, लेकिन workload के हिसाब से benchmark जरूरी है

नया monitoring tool: pg_aios

  • pg_stat_activity में asynchronous tasks, AioIoCompletion event के रूप में दिखते हैं, जिससे backend wait analysis मुश्किल हो जाती है
  • io_uring के मामले में, क्योंकि kernel सीधे काम करता है, I/O state Postgres के भीतर दिखाई नहीं देती
  • pg_aios view के जरिए मौजूदा asynchronous requests की detailed जानकारी देखी जा सकती है 
    SELECT * FROM pg_aios;
  • SUBMITTED, COMPLETED_IO जैसी states और target block information देखी जा सकती है

सावधानी: I/O timing information की व्याख्या में बदलाव

  • पहले EXPLAIN ANALYZE में दिखने वाले I/O Timings सिर्फ synchronous mode में ही भरोसेमंद माने जा सकते हैं
  • asynchronous worker, io_uring इस्तेमाल करने पर parallel processing और worker distribution की वजह से timing interpretation विकृत हो सकती है
  • वास्तविक I/O effort समझने के लिए shared read buffer count और pg_aios का उपयोग करने की सलाह दी जाती है

निष्कर्ष

  • Postgres 18, read-heavy workloads की performance बढ़ाने में वास्तविक योगदान देता है
  • खासकर cloud environments में high-latency disks इस्तेमाल करने पर इसका बड़ा फायदा मिल सकता है
  • साथ ही observability metrics की व्याख्या, performance tuning और settings लागू करने के तरीकों को फिर से सीखने की जरूरत होगी
  • आगे Postgres 19 में asynchronous write support की भी उम्मीद है

संबंधित पढ़ाई

2 टिप्पणियां

 
jujumilk3 2025-05-09

Postgres सच में सबसे बेहतरीन है
 
GN⁺ 2025-05-08
Hacker News टिप्पणियाँ
  • Linux में preadv2(..., RWF_NOWAIT) का उपयोग करके page cache से asynchronous read किया जा सकता है। यह io_method = worker में latency कम करने के लिए उपयोगी हो सकता है
    • सुझाव है कि main thread में पहले NOWAIT के साथ read की कोशिश की जाए और केवल failure होने पर ही उसे worker thread को offload किया जाए
  • यह सवाल उठाया गया कि क्या यह नया asynchronous I/O फीचर सिर्फ Linux तक सीमित है
    • Windows में IOCP और उसकी अपनी IORing implementation है, और macOS POSIX AIO को support करता है
    • यह भी कहा गया कि Windows की IORing implementation का ज़िक्र ज़्यादा नहीं दिखता
  • FreeBSD के aio(4) पर काफी काम हुआ है, और यह दिलचस्प होगा क्योंकि इसमें Linux/glibc aio की कमियाँ नहीं हैं
  • MySQL के InnoDB से इसकी समानता को लेकर सवाल है
  • io_uring की security issues को लेकर चिंता जताई गई, और पूछा गया कि क्या कई Linux admins या distributions इसे disable कर रहे हैं
  • एक राय यह है कि इस फीचर को NVMe पर production में लागू करना अच्छा होगा, और उम्मीद है कि बड़े cloud providers इसे ASAP उपलब्ध कराएँगे
    • performance improvement बहुत आकर्षक है
  • Hetzner EX-44 server पर Postgres deploy करने का अनुभव साझा किया गया
    • price-to-performance ratio बेहतरीन है, और कम लागत में enterprise-level capacity मिलती है
    • TailScale का उपयोग करके security मजबूत की गई और public network exposure पूरी तरह हटा दिया गया
    • optimization approach में PGTune के जरिए workload-specific configuration, PgHero के जरिए real-time performance monitoring, और pgcron के जरिए automated VACUUM ANALYZE jobs शामिल हैं
    • ZSTD compressed backups के लिए एक custom CLI utility बनाई गई, जो high compression ratio और high throughput बनाए रखते हुए automatic S3 upload को support करती है
    • यह setup stable है, high-performance है, और growth के लिए पर्याप्त गुंजाइश रखता है
  • AWS instance के 20k IOPS पर हल्के-फुल्के अंदाज़ में टिप्पणी की गई
    • consumer NVMe लगभग ~1 million+ IOPS देता है, और PCIe 5.0 NVMe के कारण इसके और बढ़ने की उम्मीद है
    • राय है कि cloud की मनमानी सीमाएँ कई समस्याएँ पैदा करती हैं
    • asynchronous IO बहुत उपयोगी है, लेकिन 1 million IOPS NVMe पर इसकी अहमियत कुछ कम हो सकती है
    • cloud cost बहुत महंगी है, और सस्ते consumer hardware की तुलना में performance gap बड़ा है
  • Postgres, MariaDB, और Percona के बीच performance comparison को लेकर सवाल है
    • यह जानने की उत्सुकता है कि कौन-सा database किन परिस्थितियों में बेहतर है
  • यह भी पूछा गया कि अधिक concurrent connections की अनुमति देने वाला update कब आएगा
    • उम्मीद है कि तब pgbouncer का उपयोग बंद किया जा सकेगा