Kỹ sư AWS báo cáo hiệu năng PostgreSQL trên Linux 7.0 giảm còn một nửa – có thể không dễ khắc phục

 (phoronix.com/news)
7 điểm bởi GN⁺ 16 ngày trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Một hồi quy hiệu năng nghiêm trọng đã được kỹ sư Amazon/AWS phát hiện trên kernel phát triển Linux 7.0, khi thông lượng của máy chủ cơ sở dữ liệu PostgreSQL giảm xuống còn khoảng một nửa so với kernel trước đó
  • Kết quả đo trên máy chủ Graviton4 cho thấy Linux 7.0 chỉ cung cấp khoảng 0,51 lần thông lượng so với kernel trước, và nguyên nhân được xác định là thời gian tiêu tốn trong spinlock ở user space tăng lên đáng kể
  • Nguyên nhân của hồi quy là thay đổi giới hạn chế độ preemption của kernel được thực hiện trong Linux 7.0; một bản vá khôi phục PREEMPT_NONE làm giá trị mặc định đã được gửi lên, nhưng khả năng được chấp nhận vẫn chưa rõ ràng
  • Tác giả ban đầu Peter Zijlstra cho biết thay vì sửa kernel, PostgreSQL nên được chỉnh sửa để tận dụng phần mở rộng time slice của RSEQ (Restartable Sequences)
  • Phiên bản ổn định Linux 7.0 dự kiến phát hành sau khoảng 2 tuần và cũng sẽ được dùng làm kernel nền tảng cho Ubuntu 26.04 LTS, làm dấy lên lo ngại về suy giảm hiệu năng trên diện rộng cho đến khi PostgreSQL thích nghi

Phát hiện vấn đề và mức độ ảnh hưởng

  • Kỹ sư Amazon/AWS Salvatore Dipietro đã báo cáo hồi quy về thông lượng và độ trễ của PostgreSQL
  • Theo phép đo trên máy chủ Graviton4, Linux 7.0 chỉ mang lại 0,51 lần thông lượng so với kernel hiện tại
    • Nguyên nhân được xác nhận là do tiêu tốn nhiều thời gian hơn đáng kể trong spinlock ở user space

Nguyên nhân hồi quy: giới hạn chế độ preemption

  • Kết quả bisecting cho thấy nguyên nhân là thay đổi giới hạn chế độ preemption của kernel trong Linux 7.0
  • Thay đổi này được thực hiện theo hướng chỉ giữ lại chế độ Full và Lazy preemption cho các kiến trúc CPU mới, và được đưa vào như một phần của bản cập nhật scheduler của Linux 7.0

Bản vá đã được gửi và phản ứng của maintainer kernel

  • Một bản vá khôi phục PREEMPT_NONE làm chế độ preemption mặc định đã được gửi lên mailing list của Linux kernel với lý do đây là một hồi quy nghiêm trọng
  • Tuy nhiên, Peter Zijlstra, người viết đoạn mã gốc, tỏ ra không ủng hộ việc chấp nhận bản vá này và cho rằng giải pháp là PostgreSQL tận dụng phần mở rộng time slice của RSEQ (Restartable Sequences)
    • Phần mở rộng time slice của RSEQ cũng là một tính năng được đưa vào Linux 7.0
    • Zijlstra giải thích rằng "điều này có thể hạn chế việc lock holder bị đưa vào trạng thái preempt"

Phạm vi ảnh hưởng và lịch phát hành

  • Nếu quan điểm này được giữ nguyên, hiệu năng PostgreSQL trong một số kịch bản trên bản ổn định Linux 7.0 có thể suy giảm mạnh cho đến khi PostgreSQL được cập nhật
  • Phiên bản ổn định Linux 7.0 dự kiến phát hành sau khoảng 2 tuần
  • Linux 7.0 sẽ là kernel nền tảng của Ubuntu 26.04 LTS, vì vậy Ubuntu 26.04 LTS dự kiến phát hành vào cuối tháng 4 cũng có khả năng chịu ảnh hưởng tương tự

Bài viết liên quan

2 bình luận

 
unstabler 16 ngày trước

Nghe nói các nhà phát triển kernel đã nói với các nhà phát triển PostgreSQL suốt gần 10–20 năm rằng "spinlock ở userspace không được khuyến khích, nên mong họ cân nhắc lại"..

https://x.com/kosaki55tea/status/2040458791536497035
 
GN⁺ 16 ngày trước
Ý kiến trên Hacker News

  • Đáng đọc bài viết tiếp theo trên LKML của Andres Freund, một nhà phát triển Postgres

    • Nếu vấn đề hiệu năng là một hồi quy (regression) có thể tái hiện được, thì việc chỉ có thể khắc phục bằng cách tắt các tính năng mới được thêm vào ở 7.0 là một tình huống kỳ lạ
    • Không chỉ một bài viết đơn lẻ, mà nếu theo dõi toàn bộ thread thì sẽ có nhiều thông tin bổ sung
    • Không nên ép buộc dùng các tính năng cấp thấp mới được đưa vào ở 7.0 để giải quyết hồi quy chỉ xuất hiện trên 7.0
      Có ý kiến cho rằng các maintainer của Linux nên ưu tiên hỗ trợ các ứng dụng cốt lõi như PostgreSQL
      Điều này gợi nhớ đến trường hợp trước đây Fedora chặn cập nhật khi cài Wine
    • Giải pháp “hãy dùng hugepages” luôn được đưa ra, nhưng đa số người dùng sẽ bỏ qua điều đó
    • Chỉ trên máy ARM64 96 lõi thì hiệu năng giảm xuống còn 0,51 lần, còn trên AMD64 thì không tái hiện được
      Tức là đây không phải vấn đề mà mọi người dùng PostgreSQL nâng lên kernel mới nhất đều sẽ gặp phải

  • Có ý kiến rằng dùng spinlock trong user space mà không có hỗ trợ từ kernel thì chẳng khác nào tự chuốc lấy suy giảm hiệu năng

    • Tôi cũng không thích việc Postgres dùng spinlock và đang dần loại bỏ nó
      Tuy nhiên, lock dựa trên futex lại gây hồi quy hiệu năng do tăng memory barrier
      Ngoài ra, Postgres vẫn phải tính đến các nền tảng chưa hỗ trợ phép toán nguyên tử 8 byte, nên khó thay thế
      Spinlock gây ra vấn đề đã được loại bỏ gần đây, và khi dùng huge pages thì nút thắt cổ chai gần như biến mất
    • Có phép ví von rằng dùng spinlock trong user space là “tự lấy búa đập vào mặt mình”
    • Cũng có ý kiến cho rằng PostgreSQL đã dùng spinlock để duy trì tương thích với các kernel cũ, nhưng giờ là lúc nên dừng lại

  • Cũng có người nói rằng “không ai dùng kernel mới nhất trong production”
    Nhưng trên thực tế, Ubuntu 26.04 LTS sẽ sớm phát hành dựa trên Linux 7.0, nên nhiều người dùng sẽ sớm sử dụng nó
    Vấn đề hiện tại là cần bản vá kernel chứ không phải sysctl

    • Dù vậy, vẫn cần có người thử nghiệm kernel mới nhất để phát hiện sớm các vấn đề như thế này
    • Nếu PostgreSQL bị ảnh hưởng, thì các ứng dụng khác cũng có khả năng bị ảnh hưởng
    • Cũng có ý kiến chỉ ra rằng trong môi trường Docker thì phải dùng chung kernel của host, nên không có quyền lựa chọn
    • Tham khảo thêm, tùy chọn PREEMPT_NONE đã bị loại bỏ trên đa số nền tảng

  • Có thể xem bối cảnh về PREEMPT_LAZY trong bài viết của LWN

  • Có bình luận đùa rằng “đã kiểm tra xem gần đây Jia Tan có gửi bản vá kernel nào chưa chưa?”,
    và có người đáp lại rằng “không cần đâu, lỗ hổng đã quá nhiều rồi”

  • Có ý kiến thắc mắc liệu I/O bất đồng bộ và tối ưu hóa truy vấn song song của PostgreSQL 18 có thể bù lại mức suy giảm hiệu năng lần này hay không
    Có thể xem nội dung liên quan trong ghi chú phát hành PostgreSQL 18

  • Cũng có người đặt câu hỏi vì sao lại cần chế độ preemption động như PREEMPT_LAZY
    Ý là lợi ích mà người dùng thông thường nhận được không rõ ràng

    • Có phản hồi giải thích rằng đây là thiết kế nhằm tăng throughput mà không làm tăng độ trễ
      Kernel sẽ nhận được thông tin rõ ràng hơn để cải thiện các quyết định scheduling

  • Có bình luận nói rằng họ đo được mức giảm hiệu năng 10% giữa FreeBSD 14 và 15.0, và nhìn trường hợp lần này thấy cũng được an ủi phần nào

    • Sau đó có người phản ứng: “ít nhất thì có thêm từng ấy tính năng không?”

  • Cũng có chỉ trích rằng Phoronix đã đăng bài mà không kiểm chứng đầy đủ
    Trong email tiếp theo, kết luận là bản thân benchmark có vấn đề và thực tế không phải chuyện nghiêm trọng

    • Tuy vậy, hồi quy chỉ xảy ra khi không dùng huge pages
      Có thể PostgreSQL sẽ không bị ảnh hưởng lớn, nhưng những ứng dụng khác không thể dùng huge pages thì vẫn có thể bị tác động
      Vì vậy không phải chuyện có thể đơn giản bỏ qua

  • Một liên kết thread LKML cũ cũng được chia sẻ kèm theo