Postgres ნელი არ არის. ნელი თქვენი საცავია: POSETTE 2026-ის მოხსენების რეზიუმე

ბენჩმარკის მომზადება

POSETTE 2026-ზე Sai Srirampur-მა წარადგინა მოხსენება „Postgres Isn't Slow. Your Storage Is“, სადაც განიხილა, როგორ მოქმედებს საცავის წარმადობა PostgreSQL-ზე მასშტაბირებისას. პრეზენტაციაში გამოყოფილი იყო ხუთი ხშირი სიმპტომი: ნელი ინგესტი, არათანმიმდევრული წაკითხვის ლატენტურობა, ავტოვაკუუმის ჩამორჩენა, ნელი checkpoint-ები და ლოგიკური რეპლიკაციის ჩამორჩენა. ეს პრობლემები ხშირად ერთსა და იმავე სათავეს იზიარებს საცავის წარმადობაში, როცა სამუშაო ნაკრები ხელმისაწვდომ მეხსიერებას სცდება.

საცავის როგორც ცვლადის გამოსაყოფად, ბენჩმარკში გამოყენებული იყო რვა იდენტური PostgreSQL კლასტერი: ოთხი instance-store NVMe-ზე და ოთხი საბაზისო gp3 EBS-ზე, 3000 IOPS-ით. თითოეული კლასტერი მუშაობდა m6id.4xlarge ინსტანსზე 16 vCPU-ით, 64 GiB RAM-ით და 16 GiB shared_buffers-ით. სამუშაო დატვირთვა იყენებდა 482 GiB pgbench_accounts heap-ს, რომელიც 3,3 მილიარდ სტრიქონს შეიცავდა, და ხუთი წუთის განმავლობაში ასრულებდა მაღალკონკურენტულ random-UPDATE დატვირთვას 64 კლიენტით და 16 worker thread-ით.

რა აჩვენა შედეგებმა

ბენჩმარკმა NVMe კლასტერებისთვის მედიანურად 16 030 TPS აჩვენა, EBS-ზე კი 1 734 TPS, ანუ 9,24-ჯერ განსხვავება. ტრანზაქციის მედიანური ლატენტურობა 36,9 ms-დან 4,0 ms-მდე დაეცა. ტექნიკური ოპერაციებისთვის NVMe-მ 10 GB bloat-ზე VACUUM 366 წამში დაასრულა, EBS-ზე კი 964 წამში, ხოლო 10 GB ლოგიკური რეპლიკაციის ბექლოგი 139 წამში დაასრულა 238-ის ნაცვლად.

ლატენტურობის დაშლამ აჩვენა, რომ გვერდების წაკითხვას EBS-ზე დაახლოებით 19 ms სჭირდებოდა, NVMe-ზე კი 0,3 ms, WAL fsync-ს 11 ms დაემატა 1,5 ms-ის ნაცვლად, ხოლო lock-ისა და scheduler-ის overhead-მა 5 ms შეადგინა 0,2 ms-ის ნაცვლად. CPU-ის მუშაობა ორივე შემთხვევაში დაახლოებით იგივე იყო, დაახლოებით 2 ms. pg_stat_activity-ის snapshot-მა აჩვენა, რომ EBS-ის 64 backend-იდან 29 ელოდა IO:DataFileRead-ს, NVMe-ზე კი ცხრა. 240-წამიანი პროფილირების ფანჯარაში NVMe ჰოსტმა 2 253 CPU-წამი დააგროვა, EBS ჰოსტმა კი მხოლოდ 251, რაც მიანიშნებს, რომ EBS პროცესები გაცილებით მეტ დროს ატარებდნენ CPU-ს გარეთ, საცავის მოლოდინში.

NVMe-ზე დაფუძნებული Postgres პროდაქშენში

მოხსენებაში წარმოდგენილი პროდაქშენ არქიტექტურა პასუხობს instance-store NVMe-ის გამძლეობის შეზღუდვებს სამი მოთხოვნით: გააკეთე მონაცემთა ბაზის რეპლიკაცია, რათა სერვისმა node-ის დაკარგვა გადაიტანოს, შეინახე ბექაპები და აღდგენის მონაცემები ცალკეული მანქანების გარეთ და დაგეგმე სიმძლავრე თითოეულ instance type-ზე ხელმისაწვდომი NVMe-ის მიხედვით.

პირველი პატერნია quorum-ზე დაფუძნებული სინქრონული რეპლიკაცია ორი standby კანდიდატით, კონფიგურაციით, მაგალითად, ANY 1 (standby1, standby2), რაც ტრანზაქციას საშუალებას აძლევს commit გახდეს მას შემდეგ, რაც რომელიმე standby WAL-ს დაადასტურებს. მონაცემთა ბაზის node-ების გარეთ გამძლეობისთვის, ღია კოდის ხელსაწყოები, როგორიცაა WAL-G, შეუძლიათ ფიზიკური base backup-ები და უწყვეტი WAL არქივირება, სამიზნე RPO წამებში. მოხსენება მოჰყავს Instacart-ისა და Datadog-ის საჯარო მაგალითები, რომლებმაც აღწერეს PostgreSQL-ის ლოკალურ NVMe-ზე გაშვება latency-sensitive დატვირთვებისთვის.

წყაროები: clickhouse.com