Giải thích về loadavg trên Linux Image Giải thích về loadavg trên Linux

Bài viết này sẽ giải thích về Loadavg (Load Averages) và sự ra đời của nó trên hệ điều hành Linux.

1. Sự ra đời của Loadavg

Tải trung bình ban đầu chỉ hiển thị nhu cầu sử dụng CPU: với các tiến trình đang chạy và các tiến trình đang chờ để chạy. Mô tả cho điều này trong RFC 546 có tiêu đề "Trung bình tải TENEX", tháng 8 năm 1973.

Trung bình tải TENEX là thước đo nhu cầu sử dụng CPU. Trung bình tải là trung bình của số lượng các tiến trình có thể chạy trong một khoảng thời gian nhất định.

Trung bình tải được vẽ tay từ tháng 7 năm 1973, cho thấy điều này đã được theo dõi trong nhiều thập kỷ:

Trung bình tải vẽ tay từ tháng 7 năm 1973

Ngày nay, mã nguồn cho các hệ điều hành cũ cũng có thể được tìm thấy trực tuyến. Đây là một ngoại lệ của macro DEC từ TENEX (đầu những năm 1970) SCHED.MAC:

Ngoại lệ của macro DEC từ TENEX

Biểu đồ 3 số 1 5 15

Linux ngày nay cũng khó mã hoá các số 1 phút, 5 phút và 15 phút.

Ví dụ về trung bình tải của Linux hiện tại:

Trung bình tai của Linux hiện tại

2. Loadavg cơ bản trên Linux

Chắc hẳn chúng ta khá quen với loadavg trên Linux, chúng ta có thể dễ dàng xem được bằng lệnh top hoặc uptime tương tự như ảnh sau:

Xem loadavg trên Linux

Vậy thì 3 con số này có ý nghĩa như thế nào? Ở mức nào thì hệ thống hoạt động ổn định? Ở mức nào thì hệ thống gặp vấn đề? Chúng ta sẽ tìm hiểu vấn đề này với một hệ thống chỉ có 1 CPU duy nhất làm ví dụ cho đơn giản.

2.1. Ví dụ thực tế đời thường

Thử tưởng tượng chúng ta có một cái cầu bắt qua sông, có một làn xe duy nhất và có thể chứa 10 chiếc xe. Sẽ có các trường hợp sau:

  • Loadavg của chiếc cầu đang là 0.00: có nghĩa là cầu đang trống hoàn toàn, không có chiếc xe nào chạy qua cả.
  • Loadavg của chiếc cầu đang là 1.00: có nghĩa là cầu đang hoạt động 100% sức chứa của nó, mọi chuyện đều tốt, giao thông hơi đông đút.
  • Loadavg hơn 1.00, ví dụ là 2.00: có nghĩa là có đủ 1 làn xe đang đi trên cầu và 1 làn xe đang đợi đi sang cầu.

Loadavg của cái cầu 1.00 Loadavg = 1.00

Loadavg của cái cầu 0.50 Loadavg = 0.50

Loadavg của cái cầu 1.70 Loadavg = 1.70

Vì thế với loadavg trên Linux thì giống như các tiến trình(process) đang sử dụng CPU và những tiến trình đã vào queue chờ để dùng CPU. Như cái cầu ở ví dụ trên, thì loadavg phải dưới 1.00, có thể trên 1.00 vài thời điểm, nếu trên 1.00 quá lâu thì bạn nên bắt đầu lo lắng.

2.2. Vấn đề loadavg 1.00

Nếu hệ thống của chúng ta có 1 CPU và loadavg đang là 1.00 thì có nghĩa chúng ta không còn trống CPU, vì thế thông thường chúng ta sẽ bắt đầu kiểm tra hệ thống nếu vượt 0.70

  • "Cần kiểm tra": nếu loadavg > 0.70 thì phải kiểm tra tìm hiểu nguyên nhân trước khi nó đi quá cao.

  • "Khắc phục ngay bây giờ": nếu loadavg > 1.00

  • "Đang gắp vấn đề": nếu loadavg > 5.00, nếu loadavg > 5.00 thì hệ thống chúng ta đang chậm hẳn đi, chúng ta cần khắc phục và tìm nguyên nhân ngay.

2.3. Loadavg trên hệ thống nhiều CPU

Nếu hệ thống chúng ta dùng Quad-Core CPU và loadavg vẫn tốt ở mức 3.00

Trên hệ thống nhiều CPU Cores, thì loadavg có liên hệ với số lượng CPU Cores đang có trên hệ thống. "Dùng hết 100%" là loadavg 1.00 trên hệ thống 1 CPU core, 2.00 trên hệ thống Dual Core, 4.00 trên hệ thống Quad-core...vv. Cũng giống như ví dụ về cái cầu bên trên, nếu chúng ta xây cái cầu có 2 làn xe, thì lúc đó loadavg của cầu là 1.00 thì có nghĩa cầu mới dùng được 50% sức chứa của nó.

2.4. Ví dụ thực tế

Hãy xem kết quả loadavg của ví dụ sau:

22:23:55 up 216 days, 21:49,  1 user,  load average: 0.14, 0.05, 0.01

Một phút trước loadavg là 0.14, năm phút trước là 0.05, 0.01 là mười lăm phút trước.

Một vài phân tích và suy đoán dựa theo các số trên:

  • Nếu loadavg 0.00: hệ thống rãnh rỗi (idle) hoàn toàn.
  • Nếu loadavg của một phút cao hơn năm phút hoặc mười lăm phút thì loadavg đang tăng, ngược lại thì giảm.
  • Nếu loadavg cao hơn số CPU Cores mà hệ thống đang có thì hệ thống đang gặp vấn đề.

Quá dễ phải không ? Nhưng thực tế loadavg trên Linux hiện tại không có đơn giản và rõ ràng thế đâu.

2.5. Loadavg trên Linux bao gồm những gì?

Loadavg trên Linux là "system load averages": cho toàn bộ hệ thống, nó đo đạc những tác vụ đang chạy lẫn những tác vụ chờ để chạy(bao gồm CPU, đĩa, uninterruptible locks). Nói cách khác,nó bao gồm những tác vụ không ở trạng thái nghỉ(idle) hoàn toàn.

2.6. Loadavg nào là lý tưởng?

Một số người họ có thể tìm con số loadavg lý tưởng cho hệ thống của họ, ví dụ như khi loadavg lớn hơn con số X nào đó thì độ trễ sẽ tăng, khách hàng sẽ phàn nàn chẳng hạn. Nhưng thực sự không có quy tắc nào cho việc này.

Với loadavg, chúng ta có thể chia với số CPU Cores mà hệ thống có, nếu tỉ lệ hơn 1.0 thì hệ thống có thể gặp vấn đề về hiệu năng. Nó hơi mơ hồ, vì đó là mức trung bình dài hạn (ít nhất một phút) có thể che giấu sự thay đổi. Một hệ thống có tỉ lệ 1.5 có thể hoạt động tốt, trong khi một hệ thống khác ở mức 1.5 nổ trong vòng một phút có thể hoạt động kém.

Loadavg trên Linux: khá mơ hồ vì nó bao gồm khá nhiều nhóm tài nguyên khác nhau, chúng ta không để đơn giản chia với vố CPU Cores hiện có để xác định vấn đề mà chúng ta phải cần kiểm tra các số liệu(metric) khác trên hệ thống.

2.7. Những số liệu(metric) tốt hơn

Khi loadavg trên hệ thống Linux tăng, có nghĩa là hệ thống đang dùng tài nguyên nhiều hơn(CPU, disk, locks....), nhưng chúng ta không chắc là tài nguyên nào. Chúng ta có thể dùng các lệnh của từng nhóm tài nguyên để làm rõ, ví dụ về CPU:

  • per-CPU utilization: có thể dùng mpstat -P ALL 1 để xác định.
  • per-process CPU utilization: có thể dùng op hoặc pidstat để xác định.
  • Độ trễ CPU run queue: có thể dùng lệnh perf sched.

Nhưng loadavg không hẳn là vô dụng, nó giúp các bạn có cái nhìn tổng quan về loadavg của hệ thống, để có cơ sở scale up hệ thống tự động khi dùng các nền tảng cloud, tuy nhiên nó không thực sự hữu dụng khi nói về hiệu năng hệ thống. Ngay cả những maintainer của dự án Linux Kernel cũng comment rõ về vấn đề này ở tập tin loadavg.c ở mã nguồn kernel.

This file contains the magic bits required to compute the global loadavg figure. Its a silly number but people think its important. We go through great pains to make it work on big machines and tickless kernels.

3. Tài liệu tham khảo