Gỡ lỗi hết bộ nhớ với / var / log / message

Báo cáo sau đây được ném vào nhật ký tin nhắn của tôi:

kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child
kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB

Không quan trọng nếu vấn đề này là cho httpd, mysqldhoặc postfixnhưng tôi tò mò làm thế nào tôi có thể tiếp tục gỡ rối vấn đề.

Làm thế nào tôi có thể biết thêm thông tin về lý do tại sao PID 9163 bị giết và tôi không chắc liệu linux có giữ lịch sử cho các PID bị chấm dứt ở đâu đó không.

Nếu điều này xảy ra trong tệp nhật ký tin nhắn của bạn, làm thế nào bạn sẽ khắc phục vấn đề này từng bước?

# free -m

             total       used       free     shared    buffers     cached
Mem:          1655        934        721          0         10         52
-/+ buffers/cache:        871        784
Swap:          109          6        103`

Kernel sẽ ghi lại một loạt các thứ trước khi điều này xảy ra, nhưng hầu hết trong số đó có thể sẽ không ở trong /var/log/messages, tùy thuộc vào cách (r)syslogdcấu hình của bạn . Thử:

grep oom /var/log/*
grep total_vm /var/log/*

Cái trước sẽ xuất hiện một loạt các lần và cái sau chỉ ở một hoặc hai nơi. Đó là tập tin bạn muốn xem.

Tìm dòng "Hết bộ nhớ" ban đầu trong một trong các tệp cũng chứa total_vm. Ba mươi giây đến một phút (có thể nhiều hơn, có thể ít hơn) trước khi dòng đó bạn sẽ tìm thấy một cái gì đó như:

kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

Bạn cũng nên tìm một bảng ở đâu đó giữa dòng đó và dòng "Hết bộ nhớ" với các tiêu đề như thế này:

[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name

Điều này có thể không cho bạn biết nhiều hơn những gì bạn đã biết, nhưng các trường là:

• pid ID tiến trình.
• uid User ID.
• tgid ID nhóm chủ đề.
• Total_vm Sử dụng bộ nhớ ảo (trong 4 trang kB)
• rss Sử dụng bộ nhớ thường trú (trong 4 trang kB)
• nr_ptes Mục trang bảng
• swapents Trao đổi mục
• oom_score_adj Thường là 0; một con số thấp hơn cho thấy quá trình sẽ ít có khả năng chết hơn khi kẻ giết OOM được gọi.

Bạn hầu như có thể bỏ qua nr_ptesvà swapentsmặc dù tôi tin rằng đây là những yếu tố quyết định ai sẽ bị giết. Đây không nhất thiết là quá trình sử dụng nhiều bộ nhớ nhất, nhưng rất có khả năng là vậy. Để biết thêm về quá trình lựa chọn, xem tại đây . Về cơ bản, quá trình kết thúc với số điểm oom cao nhất sẽ bị giết - đó là "điểm số" được báo cáo trên dòng "Hết bộ nhớ"; Thật không may, các điểm số khác không được báo cáo nhưng bảng đó cung cấp một số manh mối về các yếu tố.

Một lần nữa, điều này có lẽ sẽ không làm được gì nhiều ngoài việc làm sáng tỏ điều hiển nhiên: hệ thống hết bộ nhớ và mysqldđược chọn chết vì giết nó sẽ giải phóng nhiều tài nguyên nhất . Điều này không cần thiết có nghĩa mysqldlà làm bất cứ điều gì sai. Bạn có thể nhìn vào bảng để xem liệu có bất cứ điều gì khác xảy ra vào thời điểm đó không, nhưng có thể không có thủ phạm rõ ràng nào: hệ thống có thể hết bộ nhớ chỉ vì bạn đánh giá sai hoặc định cấu hình sai các quy trình đang chạy.

Chìa khóa cho vấn đề này nằm ở chính thông điệp - Hết bộ nhớ . Khi nhân Linux bị bỏ đói bộ nhớ ảo (RAM vật lý cộng với trao đổi), nó sẽ bắt đầu giết các tiến trình và đó chính xác là những gì đã xảy ra ở đây. Có vẻ như mysqldđã sử dụng hơn 2GB bộ nhớ ảo.

Hệ thống có bao nhiêu RAM và trao đổi? Tôi sẽ xem xét thêm RAM bổ sung hoặc, nếu không thể, thêm trao đổi thêm. Là một sửa chữa nhanh chóng để ít nhất ngăn chặn các quá trình bị chấm dứt, bạn có thể thêm một tệp hoán đổi.

Cập nhật: Nhìn vào dung lượng RAM bạn có, bạn có thể thấy ngay vấn đề. Bạn có ~ 1.6GB RAM và 100MB trao đổi nhưng MySQL đang sử dụng nhiều RAM hơn thế. Điều đó giải thích tại sao bạn đang thấy các quá trình bị chấm dứt.