我一直没有得到解决。 我不知道系统填满了所有的内存（36GB）。 为什么这个系统引发了这种情况？ 我怀疑它与32位Linux系统中的lowmem区域有关。 我怎样才能从内核恐慌和杀手锏分析日志？
最好的祝福，
内核3.10.24
Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0 Dec 27 09:19:05 2013 kernel: : [277622.359069] squid cpuset=/ mems_allowed=0 Dec 27 09:19:05 2013 kernel: : [277622.359074] CPU: 9 PID: 15533 Comm: squid Not tainted 3.10.24-1.lsg #1 Dec 27 09:19:05 2013 kernel: : [277622.359076] Hardware name: Intel Thurley/Greencity, BIOS 080016 10/05/2011 Dec 27 09:19:05 2013 kernel: : [277622.359078] 00000003 e377b280 e03c3c38 c06472d6 e03c3c98 c04d2d96 c0a68f84 e377b580 Dec 27 09:19:05 2013 kernel: : [277622.359089] 000042d0 00000003 00000000 e03c3c64 c04abbda e42bd318 00000000 e03c3cf4 Dec 27 09:19:05 2013 kernel: : [277622.359096] 000042d0 00000001 00000247 00000000 e03c3c94 c04d3d5f 00000001 00000042 Dec 27 09:19:05 2013 kernel: : [277622.359105] Call Trace: Dec 27 09:19:05 2013 kernel: : [277622.359116] [<c06472d6>] dump_stack+0x16/0x20 Dec 27 09:19:05 2013 kernel: : [277622.359121] [<c04d2d96>] dump_header+0x66/0x1c0 Dec 27 09:19:05 2013 kernel: : [277622.359127] [<c04abbda>] ? __delayacct_freepages_end+0x3a/0x40 Dec 27 09:19:05 2013 kernel: : [277622.359131] [<c04d3d5f>] ? zone_watermark_ok+0x2f/0x40 Dec 27 09:19:05 2013 kernel: : [277622.359135] [<c04d2f27>] check_panic_on_oom+0x37/0x60 Dec 27 09:19:05 2013 kernel: : [277622.359138] [<c04d36d2>] out_of_memory+0x92/0x250 Dec 27 09:19:05 2013 kernel: : [277622.359144] [<c04dd1fa>] ? wakeup_kswapd+0xda/0x120 Dec 27 09:19:05 2013 kernel: : [277622.359148] [<c04d6cee>] __alloc_pages_nodemask+0x68e/0x6a0 Dec 27 09:19:05 2013 kernel: : [277622.359155] [<c0801c1e>] sk_page_frag_refill+0x7e/0x120 Dec 27 09:19:05 2013 kernel: : [277622.359160] [<c084b8c7>] tcp_sendmsg+0x387/0xbf0 Dec 27 09:19:05 2013 kernel: : [277622.359166] [<c0469a2f>] ? put_prev_task_fair+0x1f/0x350 Dec 27 09:19:05 2013 kernel: : [277622.359173] [<c0ba7d8b>] ? longrun_init+0x2b/0x30 Dec 27 09:19:05 2013 kernel: : [277622.359177] [<c084b540>] ? tcp_tso_segment+0x380/0x380 Dec 27 09:19:05 2013 kernel: : [277622.359182] [<c086d0da>] inet_sendmsg+0x4a/0xa0 Dec 27 09:19:05 2013 kernel: : [277622.359186] [<c07ff3a6>] sock_aio_write+0x116/0x130 Dec 27 09:19:05 2013 kernel: : [277622.359191] [<c0457acc>] ? hrtimer_try_to_cancel+0x3c/0xb0 Dec 27 09:19:05 2013 kernel: : [277622.359197] [<c050b208>] do_sync_write+0x68/0xa0 Dec 27 09:19:05 2013 kernel: : [277622.359202] [<c050caa0>] vfs_write+0x190/0x1b0 Dec 27 09:19:05 2013 kernel: : [277622.359206] [<c050cbb3>] SyS_write+0x53/0x80 Dec 27 09:19:05 2013 kernel: : [277622.359211] [<c08f72ba>] sysenter_do_call+0x12/0x22 Dec 27 09:19:05 2013 kernel: : [277622.359213] Mem-Info: Dec 27 09:19:05 2013 kernel: : [277622.359215] DMA per-cpu: Dec 27 09:19:05 2013 kernel: : [277622.359218] CPU 0: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359220] CPU 1: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359222] CPU 2: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359224] CPU 3: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359226] CPU 4: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359228] CPU 5: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359230] CPU 6: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359232] CPU 7: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359234] CPU 8: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359236] CPU 9: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359238] CPU 10: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359240] CPU 11: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359242] CPU 12: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359244] CPU 13: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359246] CPU 14: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359248] CPU 15: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359250] CPU 16: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359253] CPU 17: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359255] CPU 18: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359258] CPU 19: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359260] CPU 20: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359262] CPU 21: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359264] CPU 22: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359266] CPU 23: hi: 0, btch: 1 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359268] Normal per-cpu: Dec 27 09:19:05 2013 kernel: : [277622.359270] CPU 0: hi: 186, btch: 31 usd: 34 Dec 27 09:19:05 2013 kernel: : [277622.359272] CPU 1: hi: 186, btch: 31 usd: 72 Dec 27 09:19:05 2013 kernel: : [277622.359274] CPU 2: hi: 186, btch: 31 usd: 40 Dec 27 09:19:05 2013 kernel: : [277622.359276] CPU 3: hi: 186, btch: 31 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359279] CPU 4: hi: 186, btch: 31 usd: 39 Dec 27 09:19:05 2013 kernel: : [277622.359281] CPU 5: hi: 186, btch: 31 usd: 49 Dec 27 09:19:05 2013 kernel: : [277622.359283] CPU 6: hi: 186, btch: 31 usd: 50 Dec 27 09:19:05 2013 kernel: : [277622.359285] CPU 7: hi: 186, btch: 31 usd: 25 Dec 27 09:19:05 2013 kernel: : [277622.359286] CPU 8: hi: 186, btch: 31 usd: 42 Dec 27 09:19:05 2013 kernel: : [277622.359289] CPU 9: hi: 186, btch: 31 usd: 39 Dec 27 09:19:05 2013 kernel: : [277622.359290] CPU 10: hi: 186, btch: 31 usd: 155 Dec 27 09:19:05 2013 kernel: : [277622.359293] CPU 11: hi: 186, btch: 31 usd: 56 Dec 27 09:19:05 2013 kernel: : [277622.359295] CPU 12: hi: 186, btch: 31 usd: 2 Dec 27 09:19:05 2013 kernel: : [277622.359297] CPU 13: hi: 186, btch: 31 usd: 162 Dec 27 09:19:05 2013 kernel: : [277622.359299] CPU 14: hi: 186, btch: 31 usd: 67 Dec 27 09:19:05 2013 kernel: : [277622.359301] CPU 15: hi: 186, btch: 31 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359303] CPU 16: hi: 186, btch: 31 usd: 68 Dec 27 09:19:05 2013 kernel: : [277622.359305] CPU 17: hi: 186, btch: 31 usd: 38 Dec 27 09:19:05 2013 kernel: : [277622.359307] CPU 18: hi: 186, btch: 31 usd: 56 Dec 27 09:19:05 2013 kernel: : [277622.359308] CPU 19: hi: 186, btch: 31 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359310] CPU 20: hi: 186, btch: 31 usd: 54 Dec 27 09:19:05 2013 kernel: : [277622.359312] CPU 21: hi: 186, btch: 31 usd: 35 Dec 27 09:19:05 2013 kernel: : [277622.359314] CPU 22: hi: 186, btch: 31 usd: 2 Dec 27 09:19:05 2013 kernel: : [277622.359316] CPU 23: hi: 186, btch: 31 usd: 60 Dec 27 09:19:05 2013 kernel: : [277622.359318] HighMem per-cpu: Dec 27 09:19:05 2013 kernel: : [277622.359320] CPU 0: hi: 186, btch: 31 usd: 32 Dec 27 09:19:05 2013 kernel: : [277622.359322] CPU 1: hi: 186, btch: 31 usd: 52 Dec 27 09:19:05 2013 kernel: : [277622.359324] CPU 2: hi: 186, btch: 31 usd: 9 Dec 27 09:19:05 2013 kernel: : [277622.359326] CPU 3: hi: 186, btch: 31 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359328] CPU 4: hi: 186, btch: 31 usd: 125 Dec 27 09:19:05 2013 kernel: : [277622.359330] CPU 5: hi: 186, btch: 31 usd: 116 Dec 27 09:19:05 2013 kernel: : [277622.359332] CPU 6: hi: 186, btch: 31 usd: 126 Dec 27 09:19:05 2013 kernel: : [277622.359333] CPU 7: hi: 186, btch: 31 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359336] CPU 8: hi: 186, btch: 31 usd: 79 Dec 27 09:19:05 2013 kernel: : [277622.359338] CPU 9: hi: 186, btch: 31 usd: 34 Dec 27 09:19:05 2013 kernel: : [277622.359340] CPU 10: hi: 186, btch: 31 usd: 111 Dec 27 09:19:05 2013 kernel: : [277622.359341] CPU 11: hi: 186, btch: 31 usd: 144 Dec 27 09:19:05 2013 kernel: : [277622.359343] CPU 12: hi: 186, btch: 31 usd: 15 Dec 27 09:19:05 2013 kernel: : [277622.359345] CPU 13: hi: 186, btch: 31 usd: 166 Dec 27 09:19:05 2013 kernel: : [277622.359347] CPU 14: hi: 186, btch: 31 usd: 185 Dec 27 09:19:05 2013 kernel: : [277622.359349] CPU 15: hi: 186, btch: 31 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359351] CPU 16: hi: 186, btch: 31 usd: 58 Dec 27 09:19:05 2013 kernel: : [277622.359353] CPU 17: hi: 186, btch: 31 usd: 122 Dec 27 09:19:05 2013 kernel: : [277622.359356] CPU 18: hi: 186, btch: 31 usd: 170 Dec 27 09:19:05 2013 kernel: : [277622.359358] CPU 19: hi: 186, btch: 31 usd: 0 Dec 27 09:19:05 2013 kernel: : [277622.359360] CPU 20: hi: 186, btch: 31 usd: 30 Dec 27 09:19:05 2013 kernel: : [277622.359362] CPU 21: hi: 186, btch: 31 usd: 33 Dec 27 09:19:05 2013 kernel: : [277622.359364] CPU 22: hi: 186, btch: 31 usd: 28 Dec 27 09:19:05 2013 kernel: : [277622.359366] CPU 23: hi: 186, btch: 31 usd: 44 Dec 27 09:19:05 2013 kernel: : [277622.359371] active_anon:658515 inactive_anon:54399 isolated_anon:0 Dec 27 09:19:05 2013 kernel: : [277622.359371] active_file:1172176 inactive_file:323606 isolated_file:0 Dec 27 09:19:05 2013 kernel: : [277622.359371] unevictable:0 dirty:0 writeback:0 unstable:0 Dec 27 09:19:05 2013 kernel: : [277622.359371] free:6911872 slab_reclaimable:29430 slab_unreclaimable:34726 Dec 27 09:19:05 2013 kernel: : [277622.359371] mapped:45784 shmem:9850 pagetables:107714 bounce:0 Dec 27 09:19:05 2013 kernel: : [277622.359371] free_cma:0 Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes Dec 27 09:19:05 2013 kernel: : [277622.359384] lowmem_reserve[]: 0 573 36539 36539 Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes Dec 27 09:19:05 2013 kernel: : [277622.359395] lowmem_reserve[]: 0 0 287725 287725 Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Dec 27 09:19:05 2013 kernel: : [277622.359406] lowmem_reserve[]: 0 0 0 0 Dec 27 09:19:05 2013 kernel: : [277622.359410] DMA: 3*4kB (U) 2*8kB (U) 4*16kB (U) 5*32kB (U) 2*64kB (U) 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 2428kB Dec 27 09:19:05 2013 kernel: : [277622.359422] Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB Dec 27 09:19:05 2013 kernel: : [277622.359435] HighMem: 6672*4kB (M) 74585*8kB (UM) 40828*16kB (UM) 17275*32kB (UM) 3314*64kB (UM) 1126*128kB (UM) 992*256kB (UM) 585*512kB (UM) 225*1024kB (UM) 78*2048kB (UMR) 5957*4096kB (UM) = 27529128kB Dec 27 09:19:05 2013 kernel: : [277622.359452] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB Dec 27 09:19:05 2013 kernel: : [277622.359454] 1505509 total pagecache pages Dec 27 09:19:05 2013 kernel: : [277622.359457] 4 pages in swap cache Dec 27 09:19:05 2013 kernel: : [277622.359459] Swap cache stats: add 13, delete 9, find 0/0 Dec 27 09:19:05 2013 kernel: : [277622.359460] Free swap = 35318812kB Dec 27 09:19:05 2013 kernel: : [277622.359462] Total swap = 35318864kB Dec 27 09:19:05 2013 kernel: : [277622.450529] 9699327 pages RAM Dec 27 09:19:05 2013 kernel: : [277622.450532] 9471490 pages HighMem Dec 27 09:19:05 2013 kernel: : [277622.450533] 342749 pages reserved Dec 27 09:19:05 2013 kernel: : [277622.450534] 2864256 pages shared Dec 27 09:19:05 2013 kernel: : [277622.450535] 1501243 pages non-shared Dec 27 09:19:05 2013 kernel: : [277622.450538] Kernel panic - not syncing: Out of memory: system-wide panic_on_oom is enabled Dec 27 09:19:05 2013 kernel: : [277622.450538] 和
# cat /proc/meminfo MemTotal: 37426312 kB MemFree: 28328992 kB Buffers: 94728 kB Cached: 6216068 kB SwapCached: 0 kB Active: 6958572 kB Inactive: 1815380 kB Active(anon): 2329152 kB Inactive(anon): 170252 kB Active(file): 4629420 kB Inactive(file): 1645128 kB Unevictable: 0 kB Mlocked: 0 kB HighTotal: 36828872 kB HighFree: 28076144 kB LowTotal: 597440 kB LowFree: 252848 kB SwapTotal: 35318864 kB SwapFree: 35318860 kB Dirty: 0 kB Writeback: 8 kB AnonPages: 2463512 kB Mapped: 162296 kB Shmem: 36332 kB Slab: 208676 kB SReclaimable: 120872 kB SUnreclaim: 87804 kB KernelStack: 6320 kB PageTables: 42280 kB NFS_Unstable: 0 kB Bounce: 124 kB WritebackTmp: 0 kB CommitLimit: 54032020 kB Committed_AS: 3191916 kB VmallocTotal: 122880 kB VmallocUsed: 27088 kB VmallocChunk: 29312 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 10232 kB DirectMap2M: 901120 kB
sysctl的：
vm.oom_dump_tasks = 0 vm.oom_kill_allocating_task = 1 vm.panic_on_oom = 1 vm.admin_reserve_kbytes = 8192 vm.block_dump = 0 vm.dirty_background_bytes = 0 vm.dirty_background_ratio = 10 vm.dirty_bytes = 0 vm.dirty_expire_centisecs = 3000 vm.dirty_ratio = 20 vm.dirty_writeback_centisecs = 500 vm.drop_caches = 0 vm.highmem_is_dirtyable = 0 vm.hugepages_treat_as_movable = 0 vm.hugetlb_shm_group = 0 vm.laptop_mode = 0 vm.legacy_va_layout = 0 vm.lowmem_reserve_ratio = 256 32 32 vm.max_map_count = 65530 vm.min_free_kbytes = 3084 vm.mmap_min_addr = 4096 vm.nr_hugepages = 0 vm.nr_overcommit_hugepages = 0 vm.nr_pdflush_threads = 0 vm.overcommit_memory = 0 vm.overcommit_ratio = 50 vm.page-cluster = 3 vm.percpu_pagelist_fraction = 0 vm.scan_unevictable_pages = 0 vm.stat_interval = 1 vm.swappiness = 30 vm.user_reserve_kbytes = 131072 vm.vdso_enabled = 1 vm.vfs_cache_pressure = 100
和
# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 292370 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 36728 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 292370 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
我还没有一个完整的答案，但我怀疑这是关于它分配的区域和相对较高的顺序（订单3）分配请求。
当我有时间的时候，我可能会回来重新编辑这个解释。
“大锤”的做法虽然是升级到64位的操作系统（这是32位），因为区域的布局是不同的。
好的，在这里我会试着回答你为什么在这里遇到一个OOM。 这里有很多因素。
如果你看看OOM本身，显然有很多可用的内存，但是OOM杀手被调用了吗？ 为什么？
内核按顺序分配内存。 “订单”是连续RAM的区域，必须满足工作请求。 订单使用algorithm2^(ORDER + 12)按数量级排列（因此名称顺序2^(ORDER + 12) 。 所以，订单0是4096，订单1是8192，订单2是16384等等。
内核有一个被认为是“高阶”（> PAGE_ALLOC_COSTLY_ORDER ）的硬编码值。 这是4级以上（64kb以上是高位）。
高订单满足页面分配不同于低订单。 一个高阶的分配，如果它没有抓住内存，现代内核将会。
您的订单大小在此处列出
Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0
顺序3是低阶请求中最高的，并且（如你所见）调用OOM杀手来试图满足它。
请注意，大多数用户空间分配不使用高阶请求。 通常它的内核需要连续的内存区域。 当用户空间使用巨大的页面时，这可能是一个例外 – 但这不是这种情况。
在你的情况下，内核调用3号分配是为了将一个数据包排入networking堆栈 – 要求32kb的分配。
内核将你的内存区域划分为区域。 这是因为在x86上某些内存区域只能被某些硬件寻址。 例如，较旧的硬件可能仅能够处理“DMA”区域中的存储器。 当我们要分配一些内存时，首先select一个区域，并且在做出分配决定时只考虑来自该区域的空闲内存。
虽然我并不完全了解区域selectalgorithm，但典型的使用情况是从来没有从DMA分配，而是通常select可以满足请求的最低可寻址区域。
在OOM中可以从/proc/zoneinfo收集到大量的区域信息。
Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
您所拥有的区域DMA，Normal和HighMem表示32位平台，因为HighMem区域在64位上不存在。 同样在64位系统上，普通映射到4GB以上，而在32位映射高达896Mb（尽pipe如此，内核报告只pipe理一小部分）： – managed:587540kB 。
有可能通过再次查看第一行来判断这个分配是从哪里来的， gfp_mask=0x42d0告诉我们分配的是什么types。 最后一个字节（0）告诉我们这是来自正常区域的分配。 gfp的含义位于include / linux / gfp.h中 。
内存不足时，回收的操作由水印指定。 它们出现在这里： min:3044kB low:3804kB high:4564kB 。 如果空闲内存达到“低”，则交换将发生，直到我们超过“高”阈值。 如果内存达到“最小”，我们需要杀死东西，以通过OOM杀手释放内存。
为了查看是否可以满足特定内存顺序的请求，内核会计算每个订单的可用页数和可用空间。 这在/proc/buddyinfo是可读的。 OOM杀手报告还吐出了buddyinfo，如下所示：
Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB
为了满足内存分配， 必须有空闲内存可用于所请求的订单大小或更高的分配。 在低订单中有大量的免费数据，而在高订单中没有任何数据意味着你的内存是零碎的。 如果你得到一个非常高的订单分配的可能（即使有大量的可用内存），由于没有高阶页面可用，它不能被满足。 内核可以通过移动大量的低阶页面来对内存进行碎片整理（这就是所谓的内存压缩），所以它们不会在可寻址的内存空间中留下空隙。
所以，如果我们考虑这些事情，我们可以说：
13*32kB (MR) 1*128kB (R) 1*256kB (R) 所以，如果有空闲的内存，其他的命令可以满足要求。 发生了什么？
那么，从一个订单分配更多的东西，而不仅仅是检查该订单或更高的可用内存量。 内核有效地从总空闲行中减去所有低位的内存，然后对剩下的内容进行最小水印检查。
在你的情况下会发生什么事是检查我们必须做的那个区域的空闲内存。
115000 - (5360*4) - (3667*8) - (3964*16) = 800
这个可用内存的数量将与min水印（即3044）进行比较。因此，从技术上说 – 您没有空闲的内存来完成您请求的分配。 这就是你援引OOM杀手的原因。
有两个修复程序。 升级到64位会改变你的区域分区，使得“Normal”为4GB，最高可达36GB，所以你不会将内存分配“拖欠”到一个可能非常分散的区域。 这并不是说你有更多的可寻址内存来修复这个问题（因为你已经使用了PAE），只是你select的区域有更多的可寻址内存。
第二种方式（我从来没有testing过）是试图让内核更积极地压缩你的内存。
如果将vm.extfrag_threshold的值从500更改为100，则更可能会压缩内存以尝试执行高阶分配。 尽pipe之前我从来没有把这个值/sys/kernel/debug/extfrag/extfrag_index但是也取决于你的碎片索引是在/sys/kernel/debug/extfrag/extfrag_index 。 目前我没有一个新的内核来看看显示提供更多的东西。
另外，你也可以运行一些cron工作（这是非常可怕的，非常丑陋的），通过写入/proc/sys/vm/compact_memory手动压缩内存。
但实际上，我不认为确实有办法调整系统来避免这个问题 – 这是内存分配器以这种方式工作的本质。 改变你使用的平台的架构可能是唯一可以从根本上解决的解决scheme。
一开始：你应该真的去一个64位操作系统。 你有足够的理由留在32位吗？
如果不仔细查看系统，最好是在发生故障的时候，很难诊断出这个问题，所以我的（快速）post或多或less是针对32位系统上的内存问题。 我有没有提到64位会使这一切都消失？
你的问题是三重的。
首先，即使在PAE内核上，每个进程的地址空间也被限制在4GiB [1]。 这意味着你的鱿鱼实例将永远不能吃每个进程超过4GiB的RAM。 我不熟悉鱿鱼，但如果这是你的主代理服务器，反正这可能是不够的。
其次，在具有大量RAM的32位系统上，所谓的“ZONE_NORMAL”中的大量内存用于存储在ZONE_HIGHMEM中使用内存所需的数据结构。 这些数据结构本身不能被移动到ZONE_HIGHMEM中，因为内核为了自己的目的而使用的内存必须总是处于ZONE_NORMAL（即在第一个1GiB-ish中）。 您在ZONE_HIGHMEM中拥有的内存越多（就您的情况而言），越是成为问题，因为内核需要越来越多的来自ZONE_NORMAL的内存来pipe理ZONE_HIGHMEM。 随着ZONE_NORMAL中可用内存的数量减less，系统可能会在某些任务中失败，因为ZONE_NORMAL是32位系统上发生的大量事情。 所有与内核有关的内存操作，例如;）
第三，即使在ZONE_NORMAL中还剩下一些内存（我还没有详细logging你的日志），一些内存操作将需要不碎片的内存。 例如，如果你所有的内存都被分割成小块，那么一些需要更多的操作将会失败。 [3]简要介绍一下你的日志在ZONE_DMA和ZONE_NORMAL中会显示相当多的碎片。
编辑：Mlfe上面的答案有详细说明如何工作的一个很好的解释。
再次说明：在64位系统上，所有内存都在ZONE_NORMAL中。 在64位系统上没有HIGHMEM区域。 问题解决了。
编辑：你可以看看这里[4]，看看你是否能告诉凶手离开你的重要stream程独自一人。 这不会解决一切（如果有的话），但它可能是值得一试。
[1] http://en.wikipedia.org/wiki/Physical_address_extension#Design
[2] http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.html和https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html /Tuning_and_Optimizing_Red_Hat_Enterprise_Linux_for_Oracle_9i_and_10g_Databases/sect-Oracle_9i_and_10g_Tuning_Guide-Hardware_Architectures_and_Linux_Kernels-a32_bit_Architecture_and_the_hugemem_Kernel.html
恐慌是因为sysctl“vm.panic_on_oom = 1”被设置 – 想法是重新启动系统将其返回到一个健全的状态。 你可以在sysctl.conf中改变它。
在顶部，我们读到了鱿鱼引诱的凶手。 你可能会检查你的鱿鱼configuration和最大的内存使用情况（或只是移动到64位操作系统）。
/ proc / meminfo显示正在使用的高内存区域，所以你正在运行一个内存为36GB的32位内核。 你也可以看到，在正常区域，为了满足squid对内存的需求，内核扫描了982页没有成功：
pages_scanned:982 all_unreclaimable? yes
@MIfe已经提供了关于如何处理内核中的内存分配的优秀文章 ，并为您提供了正确的解决scheme，例如通过cron /proc/sys/vm/compact_memory切换到64位操作系统和讨厌的hack，如手动内存压缩。
我的2美分将是另一个解决方法，可以帮助你：
我注意到你在你的内核回溯中有tcp_tso_segment ，所以：
# ethtool -K ethX tso off gso off lro off
可以通过迫使它使用更低的订单来减lessmm的压力。
PS 。 所有的卸载清单可以通过# ethtool -k ethX