Một developer sáng tạo đã đảo ngược hoàn toàn việc tối ưu hóa cơ sở dữ liệu bằng cách làm giảm hiệu suất PostgreSQL một cách có hệ thống chỉ thông qua các thay đổi cấu hình. Điều bắt đầu như một thí nghiệm của một lập trình viên thất nghiệp đã trở thành một khám phá thú vị về cách hiểu biết về thất bại có thể dẫn đến các chiến lược tối ưu hóa tốt hơn.
Học Hỏi Thông Qua Kỹ Thuật Đảo Ngược
Thí nghiệm này đã tạo được tiếng vang mạnh mẽ trong cộng đồng developer, những người nhận ra giá trị giáo dục của cách tiếp cận ngược này. Nhiều developer đã lưu ý rằng việc hiểu điều gì làm cho hệ thống thất bại thường cung cấp những hiểu biết sâu sắc hơn so với việc chỉ đơn giản tuân theo các hướng dẫn tối ưu hóa. Kỹ thuật học tập không gian âm này có tiền lệ lịch sử - nó đã được sử dụng trong Thế chiến thứ hai khi các nhà khí tượng học xác định các điều kiện thời tiết tồi tệ nhất có thể để giúp các chỉ huy nhiệm vụ tránh chúng, cuối cùng đã cứu sống nhiều phi công.
Cách tiếp cận này phản ánh các kỹ thuật được sử dụng trong các lớp viết sáng tạo, nơi học sinh phân tích văn bản kém và cố ý viết lại nội dung tốt một cách tệ hại. Những bài tập này thường chứng minh hiệu quả hơn các phương pháp truyền thống bởi vì chúng buộc người học phải hiểu các nguyên tắc cơ bản thay vì chỉ ghi nhớ các thực hành tốt nhất.
Quy Trình Phá Hủy Có Hệ Thống
Phương pháp của developer bao gồm bốn lĩnh vực phá hoại chính. Đầu tiên, họ đã giảm mạnh buffer cache từ 128MB xuống chỉ còn 8MB, buộc PostgreSQL phải đọc từ đĩa liên tục thay vì sử dụng bộ nhớ đệm RAM hiệu quả. Chỉ riêng điều này đã tạo ra một tác động hiệu suất đáng kể bằng cách loại bỏ một trong những lợi thế tốc độ chính của cơ sở dữ liệu.
Tiếp theo là thao tác xử lý nền tích cực. Bằng cách cấu hình autovacuum chạy liên tục - theo nghĩa đen là mười lần mỗi giây trên mọi bảng - hệ thống trở nên quá tải với các tác vụ bảo trì không cần thiết. Những hoạt động này tiêu thụ tài nguyên khổng lồ trong khi hầu như không hoàn thành gì, vì rất ít dữ liệu đã thay đổi giữa các lần chạy.
Cuộc tấn công thứ ba nhắm vào hệ thống Write-Ahead Log ( WAL ). Bằng cách buộc các checkpoint thường xuyên và tối đa hóa độ chi tiết của WAL , developer đã tạo ra một kịch bản trong đó PostgreSQL dành nhiều thời gian viết log hơn là xử lý các giao dịch thực tế. Các checkpoint xảy ra chỉ cách nhau 0.7 mili giây, thường xuyên hơn nhiều so với bất kỳ cấu hình hợp lý nào.
Write-Ahead Log (WAL): Một hệ thống trong đó PostgreSQL ghi các thay đổi vào tệp log trước khi áp dụng chúng vào cơ sở dữ liệu thực tế, đảm bảo tính toàn vẹn dữ liệu trong trường hợp hệ thống bị crash.
Các Thay Đổi Cấu Hình Chính Đã Thực Hiện:
shared_buffers: Giảm từ 128MB xuống 8MB (sau đó xuống 1MB)- Cài đặt autovacuum: Tối đa hóa tần suất và tối thiểu hóa ngưỡng
- Cài đặt WAL: Buộc checkpoint thường xuyên và độ chi tiết tối đa
- Chi phí query planner:
random_page_costvàseq_page_costđược điều chỉnh để vô hiệu hóa việc sử dụng index - Cấu hình I/O:
io_method = workervớiio_workers = 1(tính năng PostgreSQL 16)
Đòn Cuối Cùng: I/O Đơn Luồng
Thay đổi tàn phá nhất đến từ các tùy chọn cấu hình I/O mới của PostgreSQL 16 . Bằng cách buộc tất cả các hoạt động input/output thông qua một worker thread duy nhất, developer đã tạo ra một nút thắt cổ chai khổng lồ. Điều này có hiệu quả biến một hệ thống đa lõi hiện đại thành một máy chủ cơ sở dữ liệu đơn luồng, khiến các giao dịch phải xếp hàng và thất bại.
Kết quả rất ấn tượng: từ mức cơ sở 7.582 giao dịch mỗi giây xuống chỉ còn 0.1 TPS. Trong số 100 kết nối chạy trong 120 giây, chỉ có 11 giao dịch hoàn thành thành công. Phần còn lại thất bại do lỗi hết bộ nhớ hoặc timeout.
Kết quả suy giảm hiệu suất:
- Cơ sở: 7.582 TPS (giao dịch mỗi giây)
- Sau khi giảm buffer cache: ~1/60 tốc độ ban đầu
- Sau khi thao tác autovacuum: 293 TPS (~1/700 tốc độ ban đầu)
- Sau khi thay đổi cấu hình WAL: TPS ở mức hai chữ số
- Sau khi thao tác chi phí index: <1 TPS (chậm hơn >7.600 lần)
- Kết quả cuối cùng với I/O đơn luồng: 0,1 TPS (chậm hơn 42.000 lần)
Phản Ứng Của Cộng Đồng Và Ứng Dụng Thực Tế
Cộng đồng developer đã đón nhận cách tiếp cận giáo dục cơ sở dữ liệu độc đáo này. Nhiều người nhận ra rằng việc cố ý phá vỡ hệ thống cung cấp những hiểu biết có giá trị về hoạt động bình thường của chúng. Một số đề xuất điều này có thể trở thành một phương pháp giảng dạy, với các cuốn sách dành riêng cho cách làm cho mọi thứ tệ hơn như một con đường để hiểu về cải thiện.
Nếu bạn muốn nắm bắt được việc tối ưu hóa một cái gì đó, tại sao không làm ngược lại trước hoặc như một sự đối lập?
Thí nghiệm cũng làm nổi bật mức độ thiệt hại có thể được gây ra chỉ thông qua cấu hình, mà không cần chạm vào các index, phần cứng hoặc mã ứng dụng. Điều này vừa là cảnh báo về sức mạnh của cấu hình cơ sở dữ liệu vừa là hướng dẫn về những gì cần tránh trong môi trường sản xuất.
Bài tập này chứng minh rằng việc hiểu các ranh giới hệ thống và chế độ thất bại có thể có giá trị không kém việc biết các kỹ thuật tối ưu hóa. Đối với các quản trị viên cơ sở dữ liệu và developer, việc nhìn thấy các điểm phá vỡ của PostgreSQL cung cấp bối cảnh quan trọng để đưa ra các quyết định điều chỉnh có thông tin trong các kịch bản thực tế.
Tham khảo: Making Postgres 42,000x slower because I am unemployed