SYSTEM PERFORMANCE CASE STUDY: SLOW DISKS IN DATABASE (1)

Scott hiện là một sysadmin cho một công ty vừa. Anh ấy vừa nhận được một yêu cầu hỗ trợ (support ticket) từ đội database cho vấn đề đĩa cứng chạy chậm (slow disk) trên một trong các server của họ.

Bước đầu tiên là Scott cần tìm hiểu thêm về tình huống này, tổng hợp các thông tin để làm báo cáo cho đội database. Nội dung trong ticket chỉ nói là disk chạy chậm nhưng không cho biết gì thêm rằng điều này có liên quan tới database đang nằm trên đó hay không. Do vậy, Scott liền phản hồi lại bằng các câu hỏi sau:

1) Server này có đang gặp vấn đề hiệu năng (performance) của database không? Nếu có thì các thông số nào làm minh chứng và tại sao lại phán đoán là do slow disk gây nên?
2) Slow disk xảy ra trong bao lâu rồi?
3) Database gần đây có thay đổi gì không?

Đây là câu trả lời mà Scott nhận được từ đội database: “Chúng tôi có một log để ghi nhận các truy vấn (query) mất trên 1 giây để hoàn tất. Trước giờ khá là ổn nhưng suốt một tuần qua thì chúng tôi nhận thấy trong một giờ có tới hàng chục query bị chậm như vậy. AcmeMon thể hiện rằng các disk đang hoạt động bận rộn.”

Qua đó Scott thấy đúng là performance của database đang có vấn đề nhưng nguyên nhân từ disk mới chỉ là nghi vấn mà thôi. Rõ ràng Scott cần kiểm tra disk ngay nhưng cũng không nên bỏ qua các resource khác (RAM, CPU, network) mà có thể là “root cause” của vấn đề.

Ở trên có nhắc tới AcmeMon, đây là một hệ thống mà công ty của Scott sử dụng để giám sát server với các chức năng cơ bản. Nó cung cấp các biểu đồ (graph) thể hiện lược sử performance của server dựa trên các thông số đầu vào có được từ các công cụ của hệ điều hành như mpstat, iostat, v.v… Scott liền đăng nhập vào AcmeMon để tìm hiểu kỹ hơn.

Scott bắt đầu với một phương thức được gọi là USE (Utilization – Saturation – Error) để giúp kiểm tra nhanh xem resource nào đang là điểm bottleneck. Đúng như thông tin từ đội database, utilization (viết tắt là util) của các disk đang ở mức khá cao, chừng 80%, trong khi đó các resource khác (CPU, network) có util thấp hơn nhiều. Dữ liệu trong quá khứ (historical data) cũng cho biết rằng disk util tăng dần trong suốt tuần qua, trong khi CPU util thì giữ ở mức ổn định. AcmeMon không cung cấp các thông kê còn lại cho saturation (mức độ “extra workload” mà resource không thể đáp ứng ngay được và tạm thời phải đưa vào queue) và error. Vì vậy mà để hoàn tất quy trình USE thì Scott buộc phải đăng nhập vào server database để có thể chạy thêm một số dòng lệnh.

Anh ấy kiểm tra bộ counter cho disk error từ /proc; chúng toàn là zero cả, OK ổn. Tiếp đó Scott chạy iostat với chu kỳ là 1 giây và quan sát các thông số utilization và saturation theo thời gian thực. AcmeMon báo cáo là 80% util nhưng với chu kỳ là 1 phút. Còn ở mức 1 giây, Scott thấy là disk util dao động khá lớn, có lúc chạm ngưỡng 100% và khiến cho tình trạng saturation xảy ra và làm tăng disk I/O latency.

Để có thể xác tín thêm là chính slow disk đang làm database xử lý query chậm, Scott chạy một script được viết dựa trên cơ chế “dynamic tracing” để mỗi khi database được deschedule bởi OS kernel thì liền ghi nhận lại các mốc thời gian (timestamp) với các “database stack trace” tương ứng. Kết quả cho thấy mỗi khi database xử lý một query mà cần đọc dữ liệu từ file system thì thường bị ngưng lại trong nhiều mili giây. Chừng này chứng cứ có lẽ đã đủ với Scott.

Câu hỏi kế đến là: tại sao lại có tình trạng slow disk này? Là do disk bị trục trặc hay do đâu? Thống kê cho thấy slow disk đi cùng với high disk load (xảy ra khi lượng I/O request hoặc I/O size lớn). Scott thực hiện nhận dạng “workload pattern” để hiểu thêm về chỗ này, sử dụng iostat để đo lường IOPS, throughput, average I/O latency, read/write ratio. Từ những tham số này, anh ấy cũng tính được average I/O size và ước tính “access pattern”: random hay sequential. Nếu cần chi tiết hơn, Scott có thể sử dụng thêm các công cụ khác để theo dõi ở mức disk I/O; tuy nhiên, tới lúc này thì anh ấy thỏa mãn với trường hợp bị chậm là do high load disk chứ bản thân disk đó không có vấn đề.

Scott bắt đầu cập nhật cho ticket các chi tiết mà anh ấy đã kiểm tra và kèm theo đó là ảnh chụp màn hình của những dòng lệnh được dùng. Thế nhưng cái gì đã gây ra high load cho disk? Scott tiếp tục với luồng suy đoán đơn giản: có phải là do workload đẩy xuống cho database tăng không? Đội database nói rằng không phải, vì tần suất query (AcmeMon không thu thập số liệu này) hồi giờ vẫn ổn định và điều này khớp với thông tin ban đầu có được là CPU util cũng ổn định.

Scott nghĩ tới các khả năng khác mà có thể gây ra high disk I/O load nhưng không làm tăng CPU util và đã đem vấn đề này ra trao đổi với các đồng nghiệp của anh ấy. Một trong số họ gợi ý rằng thử kiểm tra xem hiện trạng phân mảnh dữ liệu (fragmentation) thế nào, điều này dễ xảy ra khi file system đã tới ngưỡng 100% capacity và vì thế làm cho việc đọc/ghi lên disk trở nên chậm chạp hơn. Nhưng rất tiếc, Scott thấy rằng capacity của disk chỉ mới đạt 30% mà thôi.

Scott biết rằng mình có thể tiến hành phân tích kỹ hơn để hiểu chính xác điều gì đang xảy ra nhưng cho là làm như vậy sẽ tốn thì giờ quá. Do vậy, anh ấy gắng nghĩ về các lý giải khác đơn giản hơn mà có thể kiểm tra được ngay dựa trên hiểu biết của bản thân về kernel I/O stack. Anh nhớ lại là đã từng có tình huống disk I/O kiểu này phát sinh khi có nhiều “miss page cache” trong file system.

OK, Scott liền kiểm tra tỉ lệ hit cache của filesystem và thấy là đạt 91%. Con số này tương đối cao nhưng anh ấy lại không có dữ liệu lược sử để có sự so sánh. Scott đăng nhập tiếp vào các server database khác với cùng workload tương đương và thấy là tỉ lệ hit cache của chúng đều hơn 97%. Anh ấy cũng nhận thấy rằng cache size của file system trên server bị slow disk là lớn hơn nhiều so với các server kia.

Dò xét trên đã chuyển trọng tâm của vấn đề sang cache size của file system và memory usage của server, Scott nhận ra là còn một thứ đã bị bỏ qua: có một dự án phát triển ứng dụng mới ở dạng prototype đang tiêu hao nhiều memory mặc dù nó chưa được chạy trong môi trường production. Lượng memory này bị chiếm dụng từ phần vốn dành cho page cache dẫn tới tỉ lệ hit giảm, do vậy mà làm tăng disk I/O và hệ quả là ảnh hưởng tới database production đang chạy.

Scott liên hệ với đội phát triển ứng dụng và đề nghị họ tắt cái prototype kia đi và chuyển nó sang một server khác. Tới đây thì mọi thứ đã trở nên sáng tỏ hơn, sau hành động trên, AcmeMon báo disk util đã giảm khi mà file system cache đã lấy lại kích thước ban đầu dành cho nó. Slow query gần về zero và ticket coi như đã được giải quyết.