Khi bộ nhớ cạn, Linux chọn tiến trình dùng nhiều bộ nhớ nhất và buộc kết thúc (kill) nó. Thường đó là server game.
Vì sao Bộ nhớ cạn do rò rỉ hoặc tăng đột biến, hoặc container chạm giới hạn bộ nhớ → Dẫn đến Kernel buộc kết thúc tiến trình server game → Trên màn hình Mọi người trên server đó cùng mất kết nối, tiến độ gần nhất có thể bị rollback
Phụ trách chính Phát triển server (Đội phát triển game) · Phối hợp Hạ tầng server (Đội hạ tầng)
Việc cần làm (Đội phát triển game)
Sửa rò rỉ, đặt ngưỡng trên cho mức dùng bộ nhớ và có quy trình lưu dữ liệu rồi tắt server đúng cách khi gần chạm ngưỡng.
Việc cần làm (Đội hạ tầng)
Cảnh báo bộ nhớ, đặt giới hạn bộ nhớ của container khớp với mức dùng thực tế, điều chỉnh thứ tự tiến trình bị kill trước (oom_score_adj).
Con số tham khảo
Log kernel (dmesg) ghi lại “Out of memory: Killed process”, còn trên Kubernetes sẽ thấy trạng thái OOMKilled. Windows không có OOM killer; ở đó server thường chết vì lỗi khi cấp phát bộ nhớ thất bại.
Trên đồ thị
Rớt kết nối hàng loạt · Số kết nối, mức dùng bộ nhớ
Chỗ cần xem
Bản ghi “Out of memory: Killed process” trong dmesg, trạng thái OOMKilled của pod nếu dùng Kubernetes, hoặc mức tăng oom_kill trong memory.events nếu dùng cgroup v2, đối chiếu với thời điểm mất kết nối
Đúng nếu
vào lúc kết nối rớt hàng loạt có bản ghi kill tiến trình server game, và ngay trước đó mức dùng bộ nhớ tăng lên chạm giới hạn
Loại trừ nếu
không có bản ghi OOM mà tiến trình vẫn chết → xem crash log và core dump như ở “Server crash”
Cách kiểm tra
Kiểm tra bằng công cụ hạ tầng (không cần code game)
Nguồn
mm/oom_kill.c (Linux v6.12)Linux kernel Tiến trình dùng nhiều bộ nhớ nhất nhận điểm cao nhất (có tính oom_score_adj); khi kill, kernel ghi “Out of memory: Killed process …”
Pushing the Limits of Windows: Virtual MemoryMicrosoft Trên Windows, khi chạm commit limit, các lần cấp phát commit bộ nhớ sẽ thất bại, có thể dẫn đến lỗi ứng dụng hoặc sự cố hệ thống
Control Group v2Linux kernel oom_kill trong memory.events: số tiến trình trong cgroup này bị OOM killer kill