Trong lúc chờ Postgres 18: tăng tốc độ đọc đĩa với I/O bất đồng bộ

 (pganalyze.com)
4 điểm bởi GN⁺ 2025-05-08 | 2 bình luận | Chia sẻ qua WhatsApp
  • Postgres 18, hiện đang ở beta1, giới thiệu hỗ trợ I/O bất đồng bộ (Asynchronous I/O), đặc biệt cải thiện đáng kể hiệu năng đọc trong môi trường đám mây
  • Thông qua giá trị cấu hình mới io_method, có thể chọn phương thức worker hoặc io_uring bên cạnh cách sync truyền thống
  • Theo kết quả benchmark trên AWS, khi dùng io_uring, hiệu năng đọc đĩa tăng tối đa 3 lần
  • Tuy nhiên, do được bất đồng bộ hóa, việc diễn giải thời gian I/O trong phân tích truy vấn hiện có (EXPLAIN ANALYZE) trở nên khó hơn
  • Cần tối ưu hiệu năng thông qua view giám sát mới (pg_aios) và tham số tuning (effective_io_concurrency)

Giới thiệu I/O bất đồng bộ trong Postgres 18

  • Theo truyền thống, Postgres sử dụng mô hình I/O chặn (blocking I/O), phải chờ cho đến khi mỗi lần đọc đĩa hoàn tất
  • Do độ trễ cao của storage dựa trên mạng (như EBS), nút thắt cổ chai phát sinh trong môi trường đám mây
  • I/O bất đồng bộ cho phép xử lý song song nhiều lần đọc đĩa, từ đó tăng mức sử dụng CPU và tổng thông lượng

Công việc chuẩn bị trong Postgres 17: Read Stream API

  • Trong Postgres 17, API read_stream được giới thiệu để chuẩn hóa phần trừu tượng của tác vụ đọc
  • Tuy nhiên, nó vẫn phụ thuộc vào page cache của OS và không được phản ánh trực tiếp vào shared buffer của chính Postgres
  • Trong Postgres 18, đọc bất đồng bộ trực tiếp thay vì chỉ dùng kernel hint trở nên khả thi

Cấu hình mới: io_method

  • Postgres 18 bổ sung cấu hình io_method vào postgresql.conf, cung cấp 3 tùy chọn sau:

io_method = sync

  • Phương thức đồng bộ giống như Postgres hiện tại
  • Sử dụng cách yêu cầu đọc đón đầu dựa trên posix_fadvise()

io_method = worker (mặc định)

  • Các tiến trình worker chuyên trách I/O đọc dữ liệu bất đồng bộ rồi chuyển vào shared buffer
  • Tiến trình chính có thể tiếp tục chạy mà không bị gián đoạn bởi tác vụ đọc
  • Số worker mặc định là 3 và có thể điều chỉnh bằng cấu hình io_workers

io_method = io_uring

  • Giao diện I/O hiệu năng cao có thể dùng trên Linux kernel 5.1 trở lên
  • Thực hiện đọc bất đồng bộ trực tiếp thông qua shared ring buffer với kernel mà không cần tiến trình worker
  • Yêu cầu kernel, filesystem và thiết lập hiện đại

Benchmark hiệu năng của I/O bất đồng bộ (theo AWS)

  • Môi trường thử nghiệm:
    • AWS c7i.8xlarge (32 vCPU, 64GB RAM)
    • 100GB io2 EBS, 20,000 IOPS
    • Chạy SELECT COUNT(*) trên bảng có kích thước 3.5GB

So sánh hiệu năng khi cold cache:

Phiên bản/cấu hình Thời gian chạy (ms)
Postgres 17 (sync) 15,831
Postgres 18 (sync) 15,071
Postgres 18 (worker) 10,052
Postgres 18 (io_uring) 5,723
  • io_uring cải thiện hiệu năng 2.8 lần so với sync
  • Rất hiệu quả trong việc giảm độ trễ đĩa trên đám mây

Tuning effective_io_concurrency

  • Trong Postgres 18, tham số này ảnh hưởng đến số lượng yêu cầu read-ahead bất đồng bộ nội bộ
  • Giá trị mặc định được nâng từ 1 → 16, và khi nhân với io_combine_limit sẽ quyết định phạm vi đọc tối đa
  • Trong môi trường đám mây có độ trễ cao, giá trị lớn có thể có lợi, nhưng cần benchmark theo từng workload

Công cụ giám sát mới: pg_aios

  • Trong pg_stat_activity, khi có tác vụ bất đồng bộ, nó xuất hiện dưới dạng sự kiện AioIoCompletion, khiến việc phân tích trạng thái chờ của backend trở nên khó khăn
  • Với io_uring, do kernel xử lý trực tiếp nên trạng thái I/O không hiển thị trong Postgres
  • Có thể kiểm tra thông tin chi tiết về các yêu cầu bất đồng bộ đang diễn ra thông qua view pg_aios 
    SELECT * FROM pg_aios;
  • Có thể kiểm tra các trạng thái như SUBMITTED, COMPLETED_IO và thông tin block đích

Lưu ý: thay đổi trong cách diễn giải thông tin thời gian I/O

  • I/O Timings vốn thấy trong EXPLAIN ANALYZE trước đây chỉ đáng tin cậy trong phương thức đồng bộ
  • Khi dùng worker, io_uring đã được bất đồng bộ hóa, thông tin timing bị méo do xử lý song song và phân tán qua worker
  • Khi đánh giá nỗ lực I/O thực tế, nên dùng số lượng buffer shared read và pg_aios

Kết luận

  • Postgres 18 mang lại đóng góp thực tế cho việc cải thiện hiệu năng của workload thiên về đọc
  • Đặc biệt, có thể thu được lợi ích lớn khi dùng đĩa có độ trễ cao trong môi trường đám mây
  • Đồng thời, cũng đòi hỏi học lại cách diễn giải chỉ số quan sát, tuning hiệu năng và áp dụng cấu hình
  • Trong Postgres 19 tương lai, hỗ trợ ghi bất đồng bộ cũng được kỳ vọng

Bài viết liên quan

2 bình luận

 
jujumilk3 2025-05-09

Postgres đúng là đỉnh của chóp.
 
GN⁺ 2025-05-08
Ý kiến Hacker News
  • Trên Linux có thể dùng preadv2(..., RWF_NOWAIT) để thực hiện đọc bất đồng bộ từ page cache. Điều này có thể hữu ích để giảm độ trễ khi io_method = worker
    • Có đề xuất thử đọc bằng NOWAIT trên luồng chính trước, và chỉ offload sang luồng worker khi thất bại
  • Có câu hỏi liệu tính năng I/O bất đồng bộ mới này có chỉ dành cho Linux hay không
    • Windows có IOCP và triển khai IORing riêng, còn macOS hỗ trợ POSIX AIO
    • Có ý kiến chỉ ra rằng không thấy nhiều nhắc đến triển khai IORing của Windows
  • Đã có nhiều công việc được thực hiện cho aio(4) của FreeBSD, và sẽ rất thú vị khi xem cách nó hoạt động vì nó không có các nhược điểm của aio trên Linux/glibc
  • Có câu hỏi về sự tương đồng với InnoDB của MySQL
  • Có lo ngại về các vấn đề bảo mật của io_uring, cùng câu hỏi liệu nhiều quản trị viên hoặc bản phân phối Linux có đang vô hiệu hóa nó hay không
  • Có ý kiến muốn đưa tính năng này vào production trên NVMe, đồng thời hy vọng các nhà cung cấp cloud lớn sẽ hỗ trợ nó càng sớm càng tốt
    • Mức tăng hiệu năng rất hấp dẫn
  • Chia sẻ kinh nghiệm triển khai Postgres trên máy chủ Hetzner EX-44
    • Tỷ lệ giá/hiệu năng rất tốt, cung cấp năng lực cấp doanh nghiệp với chi phí thấp
    • Dùng TailScale để tăng cường bảo mật và loại bỏ hoàn toàn việc lộ ra mạng công cộng
    • Cách tiếp cận tối ưu hóa gồm cấu hình theo workload bằng PGTune, giám sát hiệu năng thời gian thực bằng PgHero, và tác vụ VACUUM ANALYZE tự động bằng pgcron
    • Đã phát triển tiện ích CLI tùy chỉnh cho backup nén ZSTD, giữ được tỷ lệ nén cao và thông lượng cao, đồng thời hỗ trợ upload S3 tự động
    • Thiết lập này ổn định, hiệu năng tốt và còn nhiều dư địa để tăng trưởng
  • Có bình luận pha chút hài hước về 20k IOPS của instance AWS
    • NVMe tiêu dùng cung cấp khoảng hơn 1 triệu IOPS, và con số này được kỳ vọng còn tăng thêm với NVMe PCIe 5.0
    • Có ý kiến cho rằng các giới hạn mang tính tùy tiện của cloud gây ra nhiều vấn đề
    • Async IO rất hữu ích, nhưng có lẽ sẽ kém quan trọng hơn trên NVMe 1 triệu IOPS
    • Chi phí cloud rất đắt, và chênh lệch hiệu năng so với phần cứng tiêu dùng giá rẻ là rất lớn
  • Có câu hỏi về so sánh hiệu năng giữa Postgres, MariaDB và Percona
    • Muốn biết mỗi cơ sở dữ liệu nổi trội trong những trường hợp nào
  • Có câu hỏi về thời điểm phát hành bản cập nhật cho phép nhiều kết nối đồng thời hơn
    • Hy vọng có thể ngừng sử dụng pgbouncer