Kẻ giết người OOM giết chết mọi thứ với rất nhiều (?) RAM miễn phí

Kẻ giết người OOM dường như đang giết chết mọi thứ mặc dù có quá nhiều RAM miễn phí trên hệ thống của tôi:

(Giải pháp đầy đủ)

(Giải pháp đầy đủ)

27 phút và 408 quá trình sau đó, hệ thống bắt đầu phản hồi lại. Tôi đã khởi động lại nó khoảng một giờ sau đó và ngay sau đó việc sử dụng bộ nhớ trở lại bình thường (đối với máy này).

Khi kiểm tra, tôi đã có một vài quy trình thú vị đang chạy trên hộp của mình:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
[...snip...]
root      1399 60702042  0.2 482288 1868 ?     Sl   Feb21 21114574:24 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
[...snip...]
mysql     2022 60730428  5.1 1606028 38760 ?   Sl   Feb21 21096396:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
[...snip...]

Máy chủ cụ thể này đã được chạy cho khoảng. 8 giờ và đây là hai quá trình duy nhất có ... giá trị lẻ như vậy. Sự nghi ngờ của tôi là "một cái gì đó khác" đang diễn ra, có khả năng liên quan đến các giá trị phi cảm tính này. Cụ thể, tôi nghĩ rằng hệ thống nghĩ rằng nó hết bộ nhớ, trong thực tế, nó không phải là. Rốt cuộc, nó nghĩ rằng rsyslogd đang sử dụng CPU 55383984% một cách nhất quán, khi tối đa lý thuyết là 400% trên hệ thống này.

Đây là bản cài đặt CentOS 6 đầy đủ cập nhật (6.2) với RAM 768MB. Bất kỳ đề xuất về làm thế nào để tìm hiểu tại sao điều này đang xảy ra sẽ được đánh giá cao!

chỉnh sửa: đính kèm vm. sysctl tunables .. Tôi đã chơi với swappiness (hiển nhiên là 100) và tôi cũng đang chạy một kịch bản hoàn toàn khủng khiếp để loại bỏ bộ đệm và bộ đệm của tôi (hiển nhiên bởi vm.drop_caches là 3) + đồng bộ hóa đĩa mỗi 15 phút. Đây là lý do tại sao sau khi khởi động lại, dữ liệu được lưu trong bộ nhớ cache đã tăng lên kích thước hơi bình thường, nhưng sau đó nhanh chóng bị loại bỏ một lần nữa. Tôi nhận ra rằng có bộ nhớ cache là một điều rất tốt, nhưng cho đến khi tôi nhận ra điều này ...

Một điều thú vị nữa là trong khi pagefile của tôi phát triển trong sự kiện này, nó chỉ đạt ~ 20% tổng mức sử dụng có thể, điều này không ảnh hưởng đến các sự kiện OOM thực sự. Ở phía bên kia của quang phổ, đĩa đã hoạt động hoàn toàn trong cùng khoảng thời gian, đó là đặc điểm của một sự kiện OOM khi pagefile đang hoạt động.

sysctl -a 2>/dev/null | grep '^vm':

vm.overcommit_memory = 1
vm.panic_on_oom = 0
vm.oom_kill_allocating_task = 0
vm.extfrag_threshold = 500
vm.oom_dump_tasks = 0
vm.would_have_oomkilled = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.dirty_background_ratio = 10
vm.dirty_background_bytes = 0
vm.dirty_ratio = 20
vm.dirty_bytes = 0
vm.dirty_writeback_centisecs = 500
vm.dirty_expire_centisecs = 3000
vm.nr_pdflush_threads = 0
vm.swappiness = 100
vm.nr_hugepages = 0
vm.hugetlb_shm_group = 0
vm.hugepages_treat_as_movable = 0
vm.nr_overcommit_hugepages = 0
vm.lowmem_reserve_ratio = 256   256     32
vm.drop_caches = 3
vm.min_free_kbytes = 3518
vm.percpu_pagelist_fraction = 0
vm.max_map_count = 65530
vm.laptop_mode = 0
vm.block_dump = 0
vm.vfs_cache_pressure = 100
vm.legacy_va_layout = 0
vm.zone_reclaim_mode = 0
vm.min_unmapped_ratio = 1
vm.min_slab_ratio = 5
vm.stat_interval = 1
vm.mmap_min_addr = 4096
vm.numa_zonelist_order = default
vm.scan_unevictable_pages = 0
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1

chỉnh sửa: và đính kèm tin nhắn OOM đầu tiên ... khi kiểm tra kỹ hơn, nó nói rằng một cái gì đó rõ ràng đã đi ra ngoài để ăn toàn bộ không gian trao đổi của tôi.

Feb 21 17:12:49 host kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
Feb 21 17:12:51 host kernel: mysqld cpuset=/ mems_allowed=0
Feb 21 17:12:51 host kernel: Pid: 2777, comm: mysqld Not tainted 2.6.32-71.29.1.el6.x86_64 #1
Feb 21 17:12:51 host kernel: Call Trace:
Feb 21 17:12:51 host kernel: [<ffffffff810c2e01>] ? cpuset_print_task_mems_allowed+0x91/0xb0
Feb 21 17:12:51 host kernel: [<ffffffff8110f1bb>] oom_kill_process+0xcb/0x2e0
Feb 21 17:12:51 host kernel: [<ffffffff8110f780>] ? select_bad_process+0xd0/0x110
Feb 21 17:12:51 host kernel: [<ffffffff8110f818>] __out_of_memory+0x58/0xc0
Feb 21 17:12:51 host kernel: [<ffffffff8110fa19>] out_of_memory+0x199/0x210
Feb 21 17:12:51 host kernel: [<ffffffff8111ebe2>] __alloc_pages_nodemask+0x832/0x850
Feb 21 17:12:51 host kernel: [<ffffffff81150cba>] alloc_pages_current+0x9a/0x100
Feb 21 17:12:51 host kernel: [<ffffffff8110c617>] __page_cache_alloc+0x87/0x90
Feb 21 17:12:51 host kernel: [<ffffffff8112136b>] __do_page_cache_readahead+0xdb/0x210
Feb 21 17:12:51 host kernel: [<ffffffff811214c1>] ra_submit+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8110e1c1>] filemap_fault+0x4b1/0x510
Feb 21 17:12:51 host kernel: [<ffffffff81135604>] __do_fault+0x54/0x500
Feb 21 17:12:51 host kernel: [<ffffffff81135ba7>] handle_pte_fault+0xf7/0xad0
Feb 21 17:12:51 host kernel: [<ffffffff8103cd18>] ? pvclock_clocksource_read+0x58/0xd0
Feb 21 17:12:51 host kernel: [<ffffffff8100f951>] ? xen_clocksource_read+0x21/0x30
Feb 21 17:12:51 host kernel: [<ffffffff8100fa39>] ? xen_clocksource_get_cycles+0x9/0x10
Feb 21 17:12:51 host kernel: [<ffffffff8100c949>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
Feb 21 17:12:51 host kernel: [<ffffffff8113676d>] handle_mm_fault+0x1ed/0x2b0
Feb 21 17:12:51 host kernel: [<ffffffff814ce503>] do_page_fault+0x123/0x3a0
Feb 21 17:12:51 host kernel: [<ffffffff814cbf75>] page_fault+0x25/0x30
Feb 21 17:12:51 host kernel: Mem-Info:
Feb 21 17:12:51 host kernel: Node 0 DMA per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    1: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:    0, btch:   1 usd:   0
Feb 21 17:12:51 host kernel: Node 0 DMA32 per-cpu:
Feb 21 17:12:51 host kernel: CPU    0: hi:  186, btch:  31 usd:  47
Feb 21 17:12:51 host kernel: CPU    1: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    2: hi:  186, btch:  31 usd:   0
Feb 21 17:12:51 host kernel: CPU    3: hi:  186, btch:  31 usd: 174
Feb 21 17:12:51 host kernel: active_anon:74201 inactive_anon:74249 isolated_anon:0
Feb 21 17:12:51 host kernel: active_file:120 inactive_file:276 isolated_file:0
Feb 21 17:12:51 host kernel: unevictable:0 dirty:0 writeback:2 unstable:0
Feb 21 17:12:51 host kernel: free:1600 slab_reclaimable:2713 slab_unreclaimable:19139
Feb 21 17:12:51 host kernel: mapped:177 shmem:84 pagetables:12939 bounce:0
Feb 21 17:12:51 host kernel: Node 0 DMA free:3024kB min:64kB low:80kB high:96kB active_anon:5384kB inactive_anon:5460kB active_file:36kB inactive_file:12kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:14368kB mlocked:0kB dirty:0kB writeback:0kB mapped:16kB shmem:0kB slab_reclaimable:16kB slab_unreclaimable:116kB kernel_stack:32kB pagetables:140kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:8 all_unreclaimable? no
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 741 741 741
Feb 21 17:12:51 host kernel: Node 0 DMA32 free:3376kB min:3448kB low:4308kB high:5172kB active_anon:291420kB inactive_anon:291536kB active_file:444kB inactive_file:1092kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:759520kB mlocked:0kB dirty:0kB writeback:8kB mapped:692kB shmem:336kB slab_reclaimable:10836kB slab_unreclaimable:76440kB kernel_stack:2520kB pagetables:51616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:2560 all_unreclaimable? yes
Feb 21 17:12:51 host kernel: lowmem_reserve[]: 0 0 0 0
Feb 21 17:12:51 host kernel: Node 0 DMA: 5*4kB 4*8kB 2*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3028kB
Feb 21 17:12:51 host kernel: Node 0 DMA32: 191*4kB 63*8kB 9*16kB 2*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 3396kB
Feb 21 17:12:51 host kernel: 4685 total pagecache pages
Feb 21 17:12:51 host kernel: 4131 pages in swap cache
Feb 21 17:12:51 host kernel: Swap cache stats: add 166650, delete 162519, find 1524867/1527901
Feb 21 17:12:51 host kernel: Free swap  = 0kB
Feb 21 17:12:51 host kernel: Total swap = 523256kB
Feb 21 17:12:51 host kernel: 196607 pages RAM
Feb 21 17:12:51 host kernel: 6737 pages reserved
Feb 21 17:12:51 host kernel: 33612 pages shared
Feb 21 17:12:51 host kernel: 180803 pages non-shared
Feb 21 17:12:51 host kernel: Out of memory: kill process 2053 (mysqld_safe) score 891049 or a child
Feb 21 17:12:51 host kernel: Killed process 2266 (mysqld) vsz:1540232kB, anon-rss:4692kB, file-rss:128kB

Tôi chỉ nhìn vào bãi chứa nhật ký oom và tôi đặt câu hỏi về tính chính xác của biểu đồ đó. Lưu ý dòng 'Node 0 DMA32' đầu tiên. Nó nói free:3376kB, min:3448kBvà low:4308kB. Bất cứ khi nào giá trị miễn phí giảm xuống dưới giá trị thấp, kswapd có nghĩa vụ bắt đầu hoán đổi mọi thứ cho đến khi giá trị đó trở lại trên giá trị cao. Bất cứ khi nào miễn phí giảm xuống dưới mức tối thiểu, hệ thống sẽ đóng băng về cơ bản cho đến khi kernel lấy lại được giá trị tối thiểu. Thông điệp đó cũng chỉ ra rằng trao đổi đã được sử dụng hoàn toàn ở nơi nó nói Free swap = 0kB.
Vì vậy, về cơ bản kswapd đã kích hoạt, nhưng trao đổi đã đầy, vì vậy nó không thể làm gì và giá trị page_free vẫn nằm dưới giá trị Pages_min, vì vậy lựa chọn duy nhất là bắt đầu giết mọi thứ cho đến khi có thể sao lưu trang_free.
Bạn chắc chắn đã hết bộ nhớ.

http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html có một lời giải thích thực sự tốt về cách thức hoạt động. Xem phần 'Thực hiện' ở phía dưới.

Loại bỏ tập lệnh drop_caches. Ngoài ra, bạn nên đăng các phần có liên quan của bạn dmesgvà /var/log/messagesđầu ra hiển thị các thông báo OOM.

Tuy nhiên, để ngăn chặn hành vi này, tôi khuyên bạn nên thử điều sysctlchỉnh này . Đây là hệ thống RHEL / CentOS 6 và rõ ràng đang chạy trên các tài nguyên bị hạn chế. Có phải là một máy ảo?

Hãy thử sửa đổi /proc/sys/vm/nr_hugepagesvà xem nếu các vấn đề vẫn còn. Đây có thể là một vấn đề phân mảnh bộ nhớ, nhưng hãy xem liệu cài đặt này có tạo ra sự khác biệt không. Để thay đổi vĩnh viễn, hãy thêm vm.nr_hugepages = valuevào /etc/sysctl.confvà chạy sysctl -pđể đọc lại tệp cấu hình ...

Xem thêm: Giải thích các thông báo "lỗi phân bổ trang" nhân mã hóa

Không có dữ liệu có sẵn trên biểu đồ từ khi kẻ giết người OOM bắt đầu cho đến khi nó kết thúc. Tôi tin vào khung thời gian mà đồ thị bị gián đoạn rằng trên thực tế mức tiêu thụ bộ nhớ tăng đột biến và không còn bộ nhớ khả dụng nữa. Nếu không, kẻ giết người OOM sẽ không được sử dụng. Nếu bạn xem biểu đồ bộ nhớ miễn phí sau khi kẻ giết người OOM dừng lại, bạn có thể thấy nó đi xuống từ một giá trị cao hơn trước. Ít nhất nó đã làm công việc của nó đúng cách, giải phóng bộ nhớ.

Lưu ý rằng không gian hoán đổi của bạn gần như được sử dụng đầy đủ cho đến khi khởi động lại. Đó gần như là điều không bao giờ tốt và một dấu hiệu chắc chắn chỉ còn lại ít bộ nhớ trống.

Lý do không có dữ liệu cho khung thời gian cụ thể đó là vì hệ thống quá bận rộn với những thứ khác. Giá trị "Hài hước" trong danh sách quy trình của bạn có thể chỉ là kết quả, không phải là nguyên nhân. Nó không phải là chưa từng nghe thấy.

Kiểm tra /var/log/kern.log và / var / log / message, bạn có thể tìm thấy thông tin gì ở đó?

Nếu việc ghi nhật ký cũng dừng lại, hãy thử những thứ khác, kết xuất danh sách quy trình vào một tệp mỗi giây hoặc lâu hơn, cùng với thông tin hiệu suất hệ thống. Chạy nó với mức độ ưu tiên cao để nó vẫn có thể thực hiện công việc của mình (hy vọng) khi tải tăng đột biến. Mặc dù nếu bạn không có hạt nhân ưu tiên (đôi khi được chỉ định là hạt nhân "máy chủ"), bạn có thể không gặp may trong vấn đề đó.

Tôi nghĩ rằng bạn sẽ thấy rằng quá trình sử dụng hầu hết CPU% trong khoảng thời gian các vấn đề của bạn bắt đầu là (là) nguyên nhân. Tôi chưa bao giờ thấy rsyslogd cũng không mys mys hành xử theo cách đó. Nhiều khả năng thủ phạm là các ứng dụng java và các ứng dụng điều khiển gui như trình duyệt.