Cuộc khủng hoảng hiệu suất lúc 2 giờ sáng
Dashboard Grafana của tôi đỏ rực. Lúc đó là 2 giờ sáng, một cơ sở dữ liệu PostgreSQL có lưu lượng truy cập cao vốn đang ổn định trong nhiều tháng bỗng nhiên trở nên quá tải. Thời gian truy vấn tăng gấp ba lần. I/O wait vọt lên mức 40%. Mặc dù vậy, trang trạng thái của nhà cung cấp đám mây vẫn hiển thị một màu xanh mướt, khẳng định rằng “Lưu trữ NVMe cao cấp” của họ vẫn ổn định. Nhưng cửa sổ terminal lại kể một câu chuyện khác.
Kinh nghiệm quản lý hàng chục máy chủ Linux đã dạy tôi một điều: đừng bao giờ tin vào bảng thông số kỹ thuật. Một ổ đĩa được quảng cáo là “Hiệu suất cao” có thể có tốc độ tuần tự ấn tượng khi xử lý video 4K, nhưng lại gục ngã dưới sức ép của hàng ngàn lượt ghi ngẫu nhiên từ cơ sở dữ liệu. Để tìm ra sự thật, tôi sử dụng fio (Flexible I/O Tester). Đây là tiêu chuẩn trong ngành để mô phỏng áp lực thực tế lên phần cứng lưu trữ.
Tại sao dd là một công cụ benchmark tồi
Nhiều quản trị hệ thống thường dùng dd để kiểm tra tốc độ đĩa. Có lẽ bạn đã thấy lệnh này: dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct. Mặc dù dd ổn để kiểm tra nhanh trong 5 giây, nhưng nó vô dụng trong việc lập kế hoạch vận hành thực tế. Nó chỉ kiểm tra việc ghi tuần tự. Nó bỏ qua sự phức tạp của các bộ điều khiển lưu trữ hiện đại và sự hỗn loạn khi có nhiều truy cập đồng thời.
Trong môi trường thực tế, ổ đĩa của bạn không chỉ làm một việc tại một thời điểm. Nó xử lý hàng trăm yêu cầu đồng thời. Một tiến trình đọc tệp cấu hình, trong khi tiến trình khác ghi log 50MB và tiến trình thứ ba cập nhật index của cơ sở dữ liệu. Để hiểu liệu máy chủ của bạn có chịu được nhiệt hay không, bạn phải theo dõi ba chỉ số cụ thể:
- IOPS (Input/Output Operations Per Second): Số lượng yêu cầu nhỏ (thường là 4KB) mà ổ đĩa hoàn thành mỗi giây. Đây là “mạch máu” của hiệu suất cơ sở dữ liệu.
- Throughput (Băng thông): Lượng dữ liệu được di chuyển mỗi giây (MB/s). Đây là yếu tố quan trọng đối với việc sao lưu và chuyển các tệp lớn.
- Latency (Độ trễ): Thời gian để một yêu cầu I/O duy nhất hoàn thành. Độ trễ thấp giúp máy chủ phản hồi nhanh nhạy.
Cài đặt fio
Fio rất nhẹ và có sẵn trong hầu hết các kho lưu trữ chính thức. Nó sẽ không làm nặng hệ thống hoặc gây rắc rối cho các phụ thuộc của bạn.
Cho người dùng Ubuntu hoặc Debian:
sudo apt update
sudo apt install fio -yCho người dùng RHEL, CentOS, hoặc AlmaLinux:
sudo yum install epel-release -y
sudo yum install fio -yKiểm tra Cơ sở dữ liệu: Đọc/Ghi ngẫu nhiên
I/O ngẫu nhiên là nút thắt cổ chai phổ biến nhất đối với các máy chủ web. Nếu ổ đĩa của bạn không thể xử lý các lượt ghi 4KB ngẫu nhiên, ứng dụng của bạn cuối cùng sẽ bị treo. Lệnh này mô phỏng khối lượng công việc nặng của cơ sở dữ liệu bằng cách buộc ổ đĩa phải làm việc hết công suất với dữ liệu không tuần tự.
fio --name=random-rw --ioengine=libaio --rw=randrw --bs=4k --numjobs=1 --size=2G --runtime=60 --time_based --do_verify=0 --direct=1 --group_reporting --iodepth=64 --filename=fiotest.tmpGiải thích các tham số chính:
--ioengine=libaio: Sử dụng I/O bất đồng bộ gốc của Linux. Điều này mô phỏng cách các ứng dụng hiện đại như MySQL hoặc NGINX tương tác với kernel.--rw=randrw: Thực hiện kết hợp các lượt đọc và ghi ngẫu nhiên cùng lúc.--bs=4k: Đặt kích thước khối (block size) là 4KB, kích thước trang tiêu chuẩn cho hầu hết các hệ thống tệp.--direct=1: Bỏ qua bộ đệm (buffer cache) của hệ điều hành. Điều này đảm bảo bạn đang kiểm tra phần cứng thực tế chứ không phải RAM của máy chủ.--iodepth=64: Duy trì 64 yêu cầu xử lý cùng lúc để kiểm tra khả năng quản lý hàng đợi của ổ đĩa.--filename=fiotest.tmp: Tệp được sử dụng để kiểm tra. Cảnh báo: Đừng bao giờ trỏ lệnh này vào một thiết bị thô như/dev/nvme0n1trừ khi bạn có ý định định dạng lại ổ đĩa!
Kiểm tra Sao lưu: Băng thông tuần tự
Nếu bạn cần biết tốc độ di chuyển các tệp log 100GB hoặc chạy sao lưu hệ thống nhanh đến mức nào, bạn cần một bài kiểm tra tuần tự với kích thước khối lớn hơn (1MB).
fio --name=sequential-write --ioengine=libaio --rw=write --bs=1m --numjobs=1 --size=2G --runtime=60 --time_based --do_verify=0 --direct=1 --group_reporting --iodepth=32 --filename=fiotest.tmpTrong kịch bản này, hãy nhìn vào kết quả BW (Bandwidth). Một ổ NVMe Gen4 hiện đại có thể dễ dàng vượt qua mức 3.000 MB/s. Một ổ SSD SATA tiêu chuẩn thường đạt giới hạn khoảng 540 MB/s. Nếu bạn thấy các con số dưới 100 MB/s, có khả năng bạn đang đối mặt với một volume đám mây bị giới hạn băng thông hoặc một ổ cứng cơ học cũ kỹ.
Đọc kết quả mà không thấy đau đầu
Fio tạo ra rất nhiều văn bản, nhưng bạn chỉ cần tập trung vào một vài dòng. Đây là kết quả điển hình cho một ổ SSD tầm trung:
read: IOPS=15.4k, BW=60.2MiB/s (63.1MB/s)(3612MiB/60001msec)
lat (usec) : min=412, max=15432, avg=1024.05, stdev=342.1215.4k IOPS có tốt không? Đối với một VPS đám mây cơ bản (như volume AWS gp3 với cài đặt mặc định), 3.000 IOPS là mức cơ sở. Các ổ NVMe cao cấp có thể vượt quá 500.000 IOPS. Nếu bộ lưu trữ “Enterprise” của bạn đạt mức dưới 1.000 IOPS khi chịu tải, chắc chắn có gì đó không ổn.
Kiểm tra độ trễ: Hãy nhìn vào giá trị avg. Nó được đo bằng micro giây (usec) hoặc mili giây (msec). Đối với một cơ sở dữ liệu thực tế, bạn muốn độ trễ trung bình duy trì dưới 1ms hoặc 2ms. Nếu độ trễ max thường xuyên nhảy vọt trên 100ms, người dùng của bạn sẽ cảm nhận được sự chậm trễ rõ rệt.
Kết luận
Sau khi chạy fio trên máy chủ đang gặp sự cố lúc 2 giờ sáng đó, kết quả là không thể chối cãi. Chỉ số IOPS dậm chân tại chỗ ở mức 500 — xấp xỉ tốc độ của một ổ đĩa laptop từ năm 2012. Tôi đã gửi log của fio cho đội ngũ hỗ trợ của nhà cung cấp. Đối mặt với dữ liệu thực tế, họ thừa nhận rằng node vật lý có bộ điều khiển RAID bị lỗi. Họ đã di chuyển instance của tôi sang một hypervisor mới ngay lập tức. Mười phút sau, I/O wait giảm xuống còn 0,5% và cơ sở dữ liệu đã hoạt động trở lại with tốc độ tối đa.
Đừng đợi đến khi có khủng hoảng mới tìm hiểu về phần cứng của mình. Hãy chạy các bài benchmark này trước khi triển khai. Dữ liệu không nói dối, ngay cả khi những lời quảng cáo có thể làm vậy.
