Linux OOM Killer là gì? Cách kiểm tra VPS bị kill process

Một dịch vụ đột ngột dừng, website trả lỗi hoặc ứng dụng tự khởi động lại có thể là dấu hiệu VPS đang thiếu bộ nhớ. Trên Linux, khi hệ thống không còn đủ RAM để đáp ứng nhu cầu, Linux OOM Killer có thể chủ động kết thúc một hay nhiều tiến trình nhằm giải phóng bộ nhớ và giúp máy chủ tiếp tục hoạt động.

Tuy nhiên, thấy tiến trình biến mất chưa đủ để kết luận nguyên nhân là OOM. Bài viết này giúp bạn nhận biết dấu hiệu, kiểm tra log hệ thống, tìm tiến trình tiêu thụ RAM và lựa chọn hướng xử lý phù hợp khi gặp tình trạng VPS bị kill process.

Linux OOM Killer là gì?

OOM là viết tắt của “Out of Memory”, nghĩa là hệ thống cạn hoặc gần cạn bộ nhớ khả dụng. Linux có cơ chế OOM Killer để xử lý tình huống này: kernel đánh giá các tiến trình đang chạy rồi chọn một tiến trình để kết thúc, qua đó thu hồi bộ nhớ. Việc này nhằm tránh tình trạng toàn bộ máy chủ bị treo khi không thể cấp phát thêm RAM.

OOM Killer không nhất thiết chọn tiến trình lớn nhất. Kernel cân nhắc nhiều yếu tố, trong đó có mức sử dụng bộ nhớ và điểm OOM của tiến trình. Một tiến trình có điểm OOM cao thường dễ được chọn hơn; một số tiến trình hệ thống quan trọng có thể được bảo vệ bằng cấu hình riêng. Vì vậy, tiến trình bị dừng không phải lúc nào cũng là tiến trình duy nhất gây ra tình trạng thiếu RAM.

Ngoài OOM Killer trong kernel, một số hệ thống có systemd-oomd hoặc giới hạn bộ nhớ ở cấp container, dịch vụ hay cgroup. Các cơ chế này cũng có thể kết thúc tiến trình khi tài nguyên trong phạm vi được cấp phát bị dùng hết. Khi điều tra, cần xem xét cả log kernel lẫn cấu hình giới hạn bộ nhớ của ứng dụng.

Dấu hiệu VPS bị OOM Killer can thiệp

Một số biểu hiện thường gặp gồm:

• Ứng dụng, worker, cơ sở dữ liệu hoặc dịch vụ web đột ngột dừng rồi được trình quản lý dịch vụ khởi động lại.
• Website chập chờn, truy vấn chậm hoặc máy chủ phản hồi kém trong thời điểm tải tăng.
• Log xuất hiện thông báo như Out of memory, Killed process hoặc oom-kill.
• Nhật ký dịch vụ cho thấy tiến trình kết thúc bất thường. Trên một số hệ thống, mã thoát 137 có thể xuất hiện khi tiến trình nhận tín hiệu SIGKILL.
• RAM và swap thường xuyên gần mức sử dụng tối đa, đặc biệt khi nhiều tác vụ chạy đồng thời.

Mã thoát 137 không phải bằng chứng chắc chắn rằng OOM Killer đã dừng tiến trình. Quản trị viên hoặc công cụ khác cũng có thể gửi SIGKILL. Hãy đối chiếu thời điểm tiến trình dừng với log kernel, log dịch vụ và biểu đồ tài nguyên nếu có.

Tương tự, việc RAM đã giảm khi bạn kiểm tra không loại trừ OOM. Tiến trình có thể đã bị kết thúc và bộ nhớ được giải phóng trước lúc bạn đăng nhập. Log hệ thống thường là manh mối quan trọng để xác nhận sự kiện đã xảy ra.

Cách kiểm tra thiếu RAM Linux và tìm log OOM

Trước tiên, kiểm tra thời gian hệ thống và tình trạng tài nguyên hiện tại:

free -h

Lệnh này hiển thị RAM và swap. Hãy chú ý cột available để ước lượng bộ nhớ có thể dùng cho ứng dụng, thay vì chỉ nhìn vào free: Linux tận dụng RAM trống làm cache, nên con số free thấp chưa chắc đồng nghĩa máy chủ sắp hết bộ nhớ.

Để quan sát mức sử dụng theo thời gian thực, có thể dùng top hoặc htop nếu đã cài đặt. Lệnh sau sắp xếp tiến trình theo mức dùng RAM thực tế gần đúng (RSS):

ps aux --sort=-%mem | head -n 15

Để kiểm tra tải và hoạt động swap trong vài khoảng thời gian, dùng:

vmstat 1 5

Nếu các cột si và so liên tục có giá trị, hệ thống đang đọc hoặc ghi dữ liệu qua swap trong lúc lấy mẫu. Điều này có thể cho thấy áp lực bộ nhớ, nhưng cần xem cùng mức tải và tình trạng ứng dụng trước khi kết luận.

Xem log kernel và nhật ký hệ thống

Trên máy dùng systemd, kiểm tra thông báo OOM trong log kernel bằng:

sudo journalctl -k --since "24 hours ago" | grep -Ei 'out of memory|oom|killed process'

Có thể thay khoảng thời gian để truy vấn thời điểm nghi vấn. Nếu cần xem log khởi động hiện tại bằng dmesg, chạy:

sudo dmesg -T | grep -Ei 'out of memory|oom|killed process'

Tùy cấu hình quyền và chính sách lưu log, dmesg có thể không cho người dùng thường truy cập. Một số bản phân phối cũng lưu thông tin trong /var/log/syslog, /var/log/messages hoặc log riêng của kernel. Tên và vị trí tệp có thể khác nhau, vì vậy hãy kiểm tra cấu hình hệ điều hành đang sử dụng.

Thông báo dạng Killed process 1234 (ten-ung-dung) thường cho biết PID và tên tiến trình bị dừng. Hãy đối chiếu PID, tên dịch vụ và thời điểm với nhật ký ứng dụng. PID có thể được sử dụng lại sau khi tiến trình kết thúc, nên không nên chỉ dựa vào PID hiện tại.

Nếu nghi systemd-oomd can thiệp, xem nhật ký của dịch vụ:

sudo journalctl -u systemd-oomd --since "24 hours ago"

Với ứng dụng chạy trong container hoặc bị giới hạn bởi cgroup, kiểm tra giới hạn bộ nhớ và log của môi trường tương ứng. Trên hệ thống cgroup v2, các tệp memory.current, memory.max và memory.events trong thư mục cgroup có thể cho biết lượng bộ nhớ đang dùng, ngưỡng giới hạn và số lần xảy ra sự kiện OOM. Đường dẫn cụ thể phụ thuộc vào cách dịch vụ hoặc container được khởi chạy.

Cách xử lý khi VPS thiếu RAM

Sau khi xác nhận OOM, mục tiêu là tìm nguồn gây áp lực bộ nhớ và giảm nguy cơ tái diễn, thay vì chỉ khởi động lại dịch vụ. Hãy thực hiện theo thứ tự sau:

1. Xác định tiến trình và thời điểm tăng tải

Dựa vào log kernel để biết tiến trình bị chọn, sau đó đối chiếu log ứng dụng, lịch chạy tác vụ và biểu đồ RAM quanh thời điểm đó. Nếu lỗi chỉ xuất hiện khi sao lưu, nhập dữ liệu, chạy cron hoặc có lượng truy cập tăng, hãy kiểm tra tác vụ tương ứng. Tiến trình bị kill có thể là nạn nhân của thiếu RAM chứ không phải nguyên nhân duy nhất.

2. Giảm mức dùng bộ nhớ của ứng dụng

Kiểm tra các giới hạn như số worker, số kết nối đồng thời, kích thước cache và lượng dữ liệu mỗi lần xử lý. Một ứng dụng cấu hình quá nhiều tiến trình con có thể làm tổng mức tiêu thụ RAM tăng nhanh. Với mã nguồn hoặc dịch vụ tự phát triển, kiểm tra dấu hiệu rò rỉ bộ nhớ và giải phóng tài nguyên sau khi xử lý.

Không nên tăng đồng loạt mọi giới hạn chỉ để tránh lỗi trước mắt. Ví dụ, nâng số kết nối cơ sở dữ liệu hoặc số worker có thể làm RAM tăng thêm. Hãy thay đổi từng thông số, theo dõi tác động và giữ lại cấu hình có thể khôi phục.

3. Kiểm tra swap và giới hạn tài nguyên

Swap có thể giúp hệ thống xử lý các đợt tăng bộ nhớ ngắn, nhưng chậm hơn RAM và không thay thế được RAM vật lý. Nếu VPS chưa có swap, quản trị viên có thể cân nhắc cấu hình phù hợp với hệ điều hành, dung lượng lưu trữ và đặc tính ứng dụng. Theo dõi hoạt động swap sau khi thay đổi; nếu hệ thống liên tục phụ thuộc vào swap, cần xử lý nguyên nhân hoặc bổ sung tài nguyên thay vì chỉ tăng swap không giới hạn.

Kiểm tra xem dịch vụ, container hoặc cgroup có đặt giới hạn bộ nhớ thấp hơn tài nguyên của VPS hay không. Ngược lại, nếu nhiều dịch vụ cùng dùng chung máy chủ mà không có giới hạn, một ứng dụng tăng đột biến có thể ảnh hưởng đến các dịch vụ còn lại.

4. Theo dõi và cân nhắc nâng tài nguyên

Sau khi điều chỉnh, tiếp tục quan sát bằng free -h, vmstat, log hệ thống và công cụ giám sát. Nếu tải ứng dụng đã ổn định nhưng mức RAM thường xuyên sát giới hạn, nâng dung lượng bộ nhớ hoặc chuyển sang cấu hình VPS phù hợp hơn có thể là phương án cần xem xét. VibeVPS có các gói VPS AMD EPYC Gen 3 từ 81.000đ/tháng; hãy đối chiếu tài nguyên từng gói với nhu cầu thực tế trước khi lựa chọn.

Câu hỏi thường gặp

VPS bị kill process có phải luôn do thiếu RAM không?

Không. SIGKILL có thể được gửi bởi quản trị viên, trình quản lý dịch vụ, công cụ triển khai hoặc cơ chế giới hạn tài nguyên. Hãy tìm thông báo OOM trong log và đối chiếu thời điểm sự cố để xác định nguyên nhân.

Vì sao RAM còn trống nhưng vẫn có tiến trình bị dừng?

Sự kiện có thể xảy ra trong một cgroup hoặc container có giới hạn riêng, dù máy chủ tổng thể còn bộ nhớ. Ngoài ra, log và trạng thái hiện tại không cùng thời điểm: sau khi một tiến trình bị dừng, RAM có thể đã được giải phóng. Cần kiểm tra log kernel, log systemd-oomd và giới hạn của dịch vụ.

Có nên tắt OOM Killer để tránh ứng dụng bị dừng?

Không nên tắt hoặc vô hiệu hóa cơ chế bảo vệ một cách tùy tiện. Khi thiếu bộ nhớ, hệ thống có thể trở nên mất ổn định hoặc treo. Tốt hơn là xác định tiến trình gây áp lực, điều chỉnh cấu hình và bảo đảm tài nguyên phù hợp với tải.

Kết luận

Linux OOM Killer giúp hệ thống phản ứng khi không thể cấp phát đủ bộ nhớ, nhưng một tiến trình bị dừng không tự động cho biết nguyên nhân gốc. Để kiểm tra thiếu RAM Linux, hãy kết hợp log kernel, nhật ký dịch vụ, mức dùng RAM, swap và giới hạn cgroup; sau đó xử lý cấu hình ứng dụng hoặc cân nhắc bổ sung tài nguyên. Nếu VPS thường xuyên chạm ngưỡng bộ nhớ, đội ngũ VibeVPS có thể hỗ trợ bạn tìm hiểu lựa chọn cấu hình phù hợp với nhu cầu vận hành.