iostat và iotop: chẩn đoán các điểm nghẽn lưu trữ trên Linux

Khi máy chủ Linux chạy chậm, lưu trữ là một trong những nơi đầu tiên cần kiểm tra. iostat cho bạn biết liệu đĩa có bị quá tải hay không; iotop cho bạn biết quá trình nào đang gây ra tải. Khi sử dụng cùng nhau, chúng trả lời hai câu hỏi quan trọng: liệu đĩa có thực sự là điểm nghẽn hay không, và nếu có, điều gì đang gây áp lực lên nó? Bài viết này bao gồm hướng dẫn cài đặt, cách đọc kết quả (bao gồm cả vị trí của chỉ số %util trên phần cứng hiện đại), và quy trình làm việc để đi từ triệu chứng đến giải pháp khắc phục.

Cài đặt iostat và iotop

iostat đi kèm với gói sysstat; iotop được phân phối riêng. Cài đặt cả hai:

# Debian/Ubuntu
sudo apt install sysstat iotop
 
# RHEL, AlmaLinux, Rocky, CentOS Stream
sudo dnf install sysstat iotop
 
# Arch
sudo pacman -S sysstat iotop

Trên Ubuntu, sysstat được cài đặt ở chế độ tắt. Để thu thập dữ liệu nền để phân tích sau này bằng sar, hãy chỉnh sửa /etc/default/sysstat, đặt ENABLED="true", và khởi động lại dịch vụ:

sudo systemctl restart sysstat

iotop phải chạy với quyền root. Trên RHEL 9 và các phiên bản mới hơn, tính năng theo dõi độ trễ bị tắt theo mặc định, điều này khiến IO và SWAPIN trống. Kích hoạt tính năng này bằng lệnh:

echo 1 | sudo tee /proc/sys/kernel/task_delayacct

Thêm kernel.task_delayacct = 1 vào /etc/sysctl.conf để thiết lập này được duy trì sau khi khởi động lại.

Đọc kết quả đầu ra của iostat

Chạy iostat với thống kê mở rộng và bỏ qua mẫu đầu tiên, mẫu này chỉ hiển thị các giá trị trung bình kể từ khi khởi động:

iostat -xz 2

Tham số -x thêm thống kê mở rộng, -z ẩn các thiết bị không hoạt động, và 2 cập nhật mỗi hai giây. Các cột quan trọng:

• await: thời gian trung bình tính bằng mili giây để hoàn tất một yêu cầu I/O, bao gồm cả thời gian chờ trong hàng đợi. Đây là con số quan trọng nhất khi người dùng phàn nàn về tình trạng chậm chạp.
• r/s và w/s: IOPS đọc và ghi. Kết hợp với rkB/s và wkB/s , các thông số này cho bạn biết khối lượng công việc của bạn là ngẫu nhiên (IOPS cao, thông lượng thấp) hay tuần tự (IOPS thấp, thông lượng cao).
• aqu-sz: độ sâu hàng đợi trung bình. Đối với ổ cứng HDD, bất kỳ giá trị nào duy trì trên 1 đều có nghĩa là ổ đĩa không thể theo kịp.
• %util: tỷ lệ phần trăm thời gian thiết bị có ít nhất một I/O đang xử lý. Có ích đối với ổ cứng HDD, nhưng dễ gây hiểu lầm đối với NVMe (xem bên dưới).

Tham khảo ngưỡng nhanh:

Vị trí của %util

%util là chỉ số mà hầu hết mọi người thường xem xét đầu tiên, và trên NVMe, nó thực sự gây hiểu lầm. Hệ điều hành tính %util "bất kỳ hoạt động I/O nào đang diễn ra tại bất kỳ thời điểm nào", điều này phù hợp với đĩa cứng quay truyền thống xử lý từng yêu cầu một nhưng lại vô nghĩa đối với các thiết bị NVMe xử lý hàng nghìn yêu cầu song song qua các hàng đợi phần cứng. Một ổ NVMe có thể hiển thị 100% %util trong khi chỉ hoạt động ở mức 5% công suất thực tế.

Trên NVMe, hãy tin r_await, w_await, và aqu-sz thay vào đó. Nếu r_await dưới 1 ms và độ sâu hàng đợi nằm thoải mái dưới độ sâu hàng đợi phần cứng của thiết bị (thường là 1024 hoặc cao hơn), ổ đĩa thực tế không bị quá tải bất kể %util nói gì.

Để xem tốc độ NVMe nhanh theo đơn vị MB/s thay vì kB/s:

iostat -xm 1

Đối với việc thu thập dữ liệu dài hạn, bạn có thể đối chiếu với nhật ký ứng dụng sau này:

iostat -x -t 5 720 > /var/log/iostat.log

Điều này lấy mẫu mỗi 5 giây trong một giờ. sar từ cùng gói sysstat sẽ cung cấp cho bạn dữ liệu tương đương với lưu trữ lịch sử liên tục và là lựa chọn tốt hơn cho việc giám sát liên tục.

Xác nhận với CPU iowait

Nếu iostat hiển thị tình trạng quá tải lưu trữ, hãy đối chiếu với %iowait cột trong phần tóm tắt CPU ở đầu cùng kết quả đầu ra đó. %iowait trên 15-20% cùng với giá trị cao await sẽ xác nhận điểm nghẽn là bộ nhớ. Nếu %iowait cao nhưng await trông bình thường, hãy chạy vmstat 1 và kiểm tra si và so . Hoạt động trao đổi khác 0 có nghĩa là bạn đang bị giới hạn bởi bộ nhớ và lưu lượng đĩa là do phân trang, không phải do I/O của ứng dụng.

Đọc kết quả đầu ra của iotop

Khi iostat xác nhận có sự tắc nghẽn lưu trữ, iotop sẽ cho bạn biết quá trình nào là nguyên nhân. Bắt đầu với:

sudo iotop -o

Cờ -o cờ này ẩn các tiến trình nhàn rỗi, chỉ để lại những tiến trình đang thực hiện I/O tích cực. Các cột cần theo dõi:

• DISK READ / DISK WRITE: thông lượng thời gian thực cho mỗi tiến trình. Xác định các tiến trình tiêu tốn nhiều tài nguyên nhất.
• IO: tỷ lệ phần trăm thời gian quá trình bị chặn do I/O. Một quá trình chỉ ghi 50 kB/s có thể hiển thị 99% IO nếu nó đang thực hiện các lệnh đồng bộ nhỏ fsync() . Cột này quan trọng hơn thông lượng thô.
• SWAPIN: tỷ lệ phần trăm thời gian chờ các trang hoán đổi. Giá trị khác 0 ở đây có nghĩa là hệ thống đang thực hiện phân trang và "vấn đề lưu trữ" của bạn thực chất là vấn đề bộ nhớ.

Đối với các ứng dụng đa luồng (MySQL, PostgreSQL, khối lượng công việc Java), tổng hợp các luồng trở lại thành các tiến trình bằng -P, và cộng -a để tính tổng tích lũy kể từ khi iotop bắt đầu:

sudo iotop -oPa

Cờ -a là mẹo để phát hiện các tải công việc đột biến như các tác vụ sao lưu chỉ chạy trong vài giây mỗi lần và nếu không sẽ khó phát hiện trong chế độ xem trực tiếp.

Để ghi nhật ký tự động trong các khung giờ ban đêm khi không có ai theo dõi:

sudo iotop -botqq -d 10 > /var/log/iotop.log

Điều này sẽ ghi lại một bản chụp nhanh không tương tác cứ sau 10 giây. Kết hợp nó với dấu thời gian từ các tác vụ sao lưu hoặc cron của bạn để tìm ra nguyên nhân sau khi sự việc xảy ra.

Quy trình chẩn đoán

Hầu hết các cuộc điều tra về I/O đĩa đều tuân theo cùng một quy trình:

1. iostat -xz 2 để xác nhận rằng đĩa thực sự là điểm nghẽn. Xem await, aqu-szvà %iowait. Nếu các chỉ số này bình thường, vấn đề không nằm ở bộ lưu trữ và bạn nên tìm kiếm nguyên nhân ở một nơi hoàn toàn khác.
2. iotop -oPa để tìm ra quy trình gây ra tải. Hãy chú ý đến cột IO hơn là cột thông lượng. Các tác nhân gây ra vấn đề nghiêm trọng nhất thường là các chương trình thực hiện nhiều thao tác ghi đồng bộ nhỏ, chứ không phải những chương trình di chuyển nhiều byte nhất.
3. lsof -p <pid> để xem quá trình đó đang tác động đến những tệp nào. Điều này thường giúp xác định ngay loại khối lượng công việc: nhật ký ghi trước cơ sở dữ liệu, tệp nhật ký ứng dụng, điểm gắn kết sao lưu, tệp tạm thời.

Hai mẫu đáng chú ý.

Nếu bạn thấy các luồng kernel như jbd2/... (nhật ký ext4) hoặc txg_sync (ZFS) ở đầu danh sách các tác nhân ghi của iotop, chúng đang phản hồi các thao tác ghi từ các tiến trình khác, chứ không phải là khởi xướng chúng. Tiến trình không gian người dùng gây ra lưu lượng nhật ký mới là nguyên nhân thực sự; hãy tiếp tục tìm hiểu.

Trên một VPS, await kết hợp với thấp %util là dấu hiệu điển hình của "hàng xóm ồn ào". Một người thuê khác đang chiếm dụng bộ nhớ chia sẻ và I/O của bạn đang xếp hàng chờ ở phía hypervisor, chứ không phải trên đĩa ảo của bạn. Bạn có thể xác nhận nhưng không thể khắc phục vấn đề này từ bên trong máy khách; giải pháp là báo cáo lên nhà cung cấp hoặc chuyển sang một máy chủ có bộ nhớ được cách ly.

Khắc phục các điểm nghẽn I/O phổ biến

Khi bạn đã biết nguyên nhân gây ra sự cố trên đĩa, các biện pháp khắc phục thường rất đơn giản.

Hãy giảm mức độ ưu tiên của các I/O không quan trọng. ionice đưa một quá trình vào lớp lập lịch nhàn rỗi, nơi nó chỉ sử dụng băng thông đĩa khi không có gì khác cần đến:

ionice -c 3 -p <pid>
sudo ionice -c 3 rsync -a /data /backup

Hình thức đầu tiên thay đổi một quá trình đang chạy; hình thức thứ hai khởi chạy một quá trình mới đã có trong lớp nhàn rỗi. Trong iotop, bạn có thể thay đổi mức độ ưu tiên của một quá trình đang chạy một cách tương tác bằng cách nhấn i.

Chuyển các tác vụ nặng sang bộ nhớ nhanh hơn. Nếu iostat cho thấy đĩa SATA bị quá tải do các thao tác ghi cơ sở dữ liệu và có một ổ NVMe nhàn rỗi trong cùng một máy chủ, hãy di chuyển thư mục dữ liệu cơ sở dữ liệu sang đó. Sự chênh lệch về IOPS lên đến hàng chục lần khiến đây trở thành giải pháp mang lại hiệu quả cao nhất.

Đặt bộ lập lịch I/O phù hợp. Các kernel hiện đại có cài đặt mặc định hợp lý, nhưng vẫn đáng để kiểm tra. Đối với NVMe và SSD, hãy đặt bộ lập lịch thành none. Thiết bị xử lý xếp hàng trong phần cứng tốt hơn so với nhân hệ điều hành:

echo none > /sys/block/nvme0n1/queue/scheduler

Đối với các ổ HDD xử lý tải công việc hỗn hợp, mq-deadline thường là lựa chọn thông thường.

Gắn kết với noatime. Mỗi lần đọc sẽ cập nhật dấu thời gian truy cập lần cuối của tệp theo mặc định, tạo ra một lần ghi cho mỗi lần đọc. Trên các hệ thống tệp có nhiều thao tác đọc, đây là I/O không cần thiết. Thêm noatime vào các tùy chọn gắn kết trong /etc/fstab:

UUID=... /data ext4 defaults,noatime 0 2

Điều chỉnh writeback cho các thao tác ghi đột biến. Trên các máy chủ có nhiều RAM, các ngưỡng trang bẩn mặc định cho phép bộ đệm trang tích lũy hàng gigabyte dữ liệu chưa ghi, sau đó xả nó trong một lần lớn gây tắc nghẽn. Giảm các ngưỡng trong /etc/sysctl.conf để làm mượt quá trình này:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

Bản thân đĩa thường không phải là vấn đề. Khi iostat hiển thị IOPS cao và thông lượng thấp, khối lượng công việc đang thực hiện I/O ngẫu nhiên trên dữ liệu có thể là tuần tự, hoặc chạy nhiều thao tác ghi nhỏ có thể được gộp lại. Hãy xem xét ứng dụng trước khi đổ lỗi cho phần cứng.

Nếu bạn đang chạy các tác vụ nặng về lưu trữ trên một máy chủ mà mạng có thể chạy nhanh hơn đĩa, các máy chủ chuyên dụng được hỗ trợ bởi NVMe của FDC sẽ cung cấp cho bạn dung lượng để áp dụng các điều chỉnh trên một cách hiệu quả.