Cuộc gọi báo động lúc 2 giờ sángĐiện thoại của bạn reo vang lúc 2 giờ sáng. Một node production đã chết. Bạn không thể SSH vào, và giao diện console là một bức tường văn bản bị đóng băng. Hãy nhìn kỹ vào cuối nhật ký hệ thống, bạn có thể sẽ phát hiện ra thủ phạm này:
kernel: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
Về cơ bản, một lõi CPU đã bị kẹt trong một vòng lặp ở cấp độ kernel quá lâu. Theo mặc định, Linux sẽ mất kiên nhẫn sau 20 giây. Nếu một tác vụ không giải phóng tài nguyên trước thời điểm đó, watchdog sẽ cảnh báo. Trên một VPS đơn nhân, điều này gây đóng băng hoàn toàn hệ thống. Trên các máy chủ lớn hơn, nó gây ra các đợt tăng độ trễ khủng khiếp trước khi toàn bộ hệ thống bị nghẽn.
Tóm tắt: Bản vá khẩn cấpNếu bạn vẫn có thể nhập lệnh, hãy cho kernel một chút "không gian để thở". Việc tăng ngưỡng watchdog sẽ không giải quyết được lỗi gốc rễ, nhưng nó có thể ngăn hệ thống bị sập ngay lập tức. Điều này giúp bạn có thời gian để điều tra mà không bị tình trạng máy chủ khởi động lại liên tục.
# Kiểm tra giới hạn hiện tại (thường là 20 giây)
cat /proc/sys/kernel/softlockup_thresh
# Tăng ngay lên 60 giây
sudo sysctl -w kernel.softlockup_thresh=60
Để giành lại quyền kiểm soát một hệ thống đang bị giật lag nghiêm trọng, bạn có thể cần tạm thời tắt các backtrace:
sudo sysctl -w kernel.softlockup_all_cpu_backtrace=0
sudo sysctl -w kernel.watchdog_thresh=0
Điều gì thực sự đang "bẫy" CPU của bạn?Lỗi soft lockup xảy ra khi kernel dành quá nhiều thời gian trong một 'vùng tới hạn' (critical section) mà không cho phép bộ lập lịch (scheduler) hoạt động. Các nguyên nhân phổ biến bao gồm:
- NFS/Độ trễ mạng: Một mount từ xa bị treo, và kernel bị chặn trong khi chờ phản hồi.
- Tài nguyên đám mây bị dùng quá mức: Trên AWS hoặc Azure, hiện tượng 'Noisy Neighbors' có thể chiếm dụng chu kỳ CPU vật lý của bạn, khiến VM có cảm giác như bị đóng băng.
- Tải ngắt (Interrupt) nặng: Một card mạng (NIC) bị lỗi làm tràn ngập hệ thống với hơn 50,000 ngắt mỗi giây.
- Lưu lượng truy cập tăng đột biến: Lưu lượng truy cập cơ sở dữ liệu tăng vọt gấp 10 lần khiến stack I/O bị quá tải tức thì.
Bước 1: Tìm kiếm trong đống đổ nátKernel thường xuất một bản stack trace ra dmesg ngay khi phát hiện lỗi lockup. Bạn cần xác định tiến trình cụ thể nào đang hoạt động khi đồng hồ đếm ngược kết thúc.
dmesg | grep -C 5 "soft lockup"
Hãy tìm dòng có đánh dấu CPU: 0 PID: 1234 Comm: .... Nếu giá trị Comm là java hoặc python, mã ứng dụng của bạn có khả năng đang kích hoạt các syscall nặng. Nếu đó là kworker, gần như chắc chắn bạn đang gặp phải vấn đề về nghẽn I/O đĩa hoặc lỗi driver.
Bước 2: Cấu hình bản vá vĩnh viễnNếu khối lượng công việc của bạn thường xuyên có các đợt tăng cường độ cao, bạn nên nâng giới hạn này vĩnh viễn. Chỉnh sửa tệp /etc/sysctl.conf để giữ các cài đặt này sau khi khởi động lại:
# Tăng ngưỡng để xử lý các đợt tải nặng đột biến
kernel.softlockup_thresh = 60
kernel.watchdog_thresh = 30
Áp dụng thay đổi cấu hình:
sudo sysctl -p
Bước 3: Kiểm tra độ trễ ảo hóaTrên các máy ảo, 'Clocksource' rất quan trọng. Nếu đồng hồ máy chủ (host) và máy khách (guest) bị lệch, kernel sẽ rơi vào tình trạng panic. Kiểm tra nguồn hiện tại của bạn:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
Nếu bạn đang dùng máy ảo và thấy tsc, hãy thử chuyển sang kvm-clock nếu có sẵn. Ngoài ra, hãy chạy lệnh top và quan sát cột %st (steal time). Nếu steal time liên tục ở mức 5% hoặc cao hơn, nhà cung cấp dịch vụ đám mây của bạn đã chia sẻ tài nguyên phần cứng quá mức. Bạn sẽ cần di chuyển VM sang một host khác hoặc nâng cấp loại instance.
Bước 4: Phát hiện "cơn bão" ngắtĐôi khi phần cứng bị lỗi làm tràn ngập CPU với các yêu cầu. Sử dụng lệnh cat /proc/interrupts để xem liệu có một IRQ cụ thể nào đang tăng vọt hay không:
watch -n 1 "cat /proc/interrupts"
Theo dõi các con số. Nếu bạn thấy một IRQ cụ thể tăng thêm hàng chục nghìn đơn vị chỉ trong vài giây trong khi hệ thống bị giật, bạn đã tìm thấy lỗi phần cứng hoặc driver.
Xác minh: Kiểm tra khả năng chịu tải của bản váSau khi tinh chỉnh, hãy theo dõi các bản nhật ký trong 24 giờ. Bạn có thể mô phỏng khối lượng công việc nặng bằng công cụ stress để xem các ngưỡng mới có chịu được áp lực hay không.
# Cài đặt công cụ stress
sudo apt install stress
# Cảnh báo: Không chạy lệnh này trên hệ thống production đang hoạt động!
# Ép tải 4 lõi CPU trong 60 giây
stress --cpu 4 --timeout 60
Nếu dmesg không xuất hiện cảnh báo nào trong quá trình kiểm tra này, ngưỡng mới của bạn là phù hợp. Nếu lỗi quay trở lại, hãy ngừng điều chỉnh sysctl và bắt đầu kiểm tra hệ thống phụ I/O bằng lệnh iostat -xz 1 để tìm hiểu lý do tại sao đĩa bị nghẽn.