目前最好的文章.
When Linux Runs Out of Memory
另一份不錯的文章
Taming the OOM killer
這篇文章有講到可以設權值. userspace 去處理 OOM 問題等等.

原因
或許是 fragment memory 造成的, 也有可能 kernel 佔去太多 memory.

解決方案
完全啟用 Linux kernel over commit 機制.
echo 1 > /proc/sys/vm/overcommit_memory

其他參考文件
Dynamic memory management
Another approach, called buddy memory allocation, is a faster memory technique that divides memory into power-of-2 partitions and attempts to allocate memory requests using a best-fit approach. When memory is freed by the user, the buddy block is checked to see if any of its contiguous neighbors have also been freed. If so, the blocks are combined to minimize fragmentation. This algorithm tends to be a bit more time efficient but can waste memory due to the best-fit approach.
* 註: Linux 己經使用這個機制.

分析檔案

其他
Memory Fragmentation
Memory

The post OOM – Out of Memory. appeared first on richliu's blog.

smbd: page allocation failure. order:2, mode:0x20
Backtrace:
[<c002fd30>] (dump_backtrace+0x0/0x108) from [<c02ac488>] (dump_stack+0x18/0x1c)
[<c02ac470>] (dump_stack+0x0/0x1c) from [<c0075734>] (__alloc_pages_nodemask+0x3d0/0x55c)
[<c0075364>] (__alloc_pages_nodemask+0x0/0x55c) from [<c008f5d8>] (cache_alloc_refill+0x2b0/0x598)
[<c008f328>] (cache_alloc_refill+0x0/0x598) from [<c008f978>] (__kmalloc+0xb8/0xd8)
[<c008f8c0>] (__kmalloc+0x0/0xd8) from [<c0227a6c>] (__alloc_skb+0x54/0x138)
[<c0227a18>] (__alloc_skb+0x0/0x138) from [<c022879c>] (dev_alloc_skb+0x20/0x44)
[<c022877c>] (dev_alloc_skb+0x0/0x44) from [<c01e643c>] (cns3xxx_receive_packet+0x228/0x3c8)
[<c01e6214>] (cns3xxx_receive_packet+0x0/0x3c8) from [<c01e661c>] (cns3xxx_poll+0x40/0xd4)
[<c01e65dc>] (cns3xxx_poll+0x0/0xd4) from [<c022f264>] (net_rx_action+0xb4/0x184)
[<c022f1b0>] (net_rx_action+0x0/0x184) from [<c0048544>] (__do_softirq+0x90/0x11c)
[<c00484b4>] (__do_softirq+0x0/0x11c) from [<c0048614>] (irq_exit+0x44/0x4c)
[<c00485d0>] (irq_exit+0x0/0x4c) from [<c002b04c>] (_text+0x4c/0x90)
[<c002b000>] (_text+0x0/0x90) from [<c002bab8>] (__irq_svc+0x38/0x80)
Exception stack(0xc7acbcc0 to 0xc7acbd08)
bcc0: c7acbd1c c7829960 c7acbd28 00000000 00000001 c7b53980 c7b539e4 c7acbd1c
bce0: 00000000 00000000 c7acbf08 c7acbd14 c7acbd28 c7acbd08 c0222314 c0057a0c
bd00: 60000013 ffffffff
[<c00579b0>] (finish_wait+0x0/0x6c) from [<c0222314>] (sk_wait_data+0xcc/0xec)
[<c0222248>] (sk_wait_data+0x0/0xec) from [<c0255fc0>] (tcp_recvmsg+0x600/0x8a8)
[<c02559c0>] (tcp_recvmsg+0x0/0x8a8) from [<c0221208>] (sock_common_recvmsg+0x48/0x5c)
[<c02211c0>] (sock_common_recvmsg+0x0/0x5c) from [<c021e7d8>] (sock_aio_read+0x138/0x144)
[<c021e6a0>] (sock_aio_read+0x0/0x144) from [<c0092918>] (do_sync_read+0xc4/0x110)
[<c0092854>] (do_sync_read+0x0/0x110) from [<c00936ac>] (vfs_read+0x164/0x16c)
[<c0093548>] (vfs_read+0x0/0x16c) from [<c0093790>] (sys_read+0x44/0x74)
[<c009374c>] (sys_read+0x0/0x74) from [<c002be40>] (ret_fast_syscall+0x0/0x2c)
Mem-info:
Normal per-cpu:
CPU    0: hi:   42, btch:   7 usd:  32
Active_anon:570 active_file:9598 inactive_anon:576
inactive_file:17657 unevictable:0 dirty:3503 writeback:0 unstable:0
free:419 slab:2389 mapped:1587 pagetables:87 bounce:0
Normal free:1676kB min:1440kB low:1800kB high:2160kB active_anon:2280kB inactive_anon:2304kB active_file:38392kB inactive_file:70628kB unevictable:0kB present:130048kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 345*4kB 25*8kB 6*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1676kB
27277 total pagecache pages
32768 pages of RAM
543 free pages
1251 reserved pages
2389 slab pages
29382 pages shared
0 pages swap cached

可以加大 kernel 預留的 Buffer, 我系統上原來是 1117, 可以用指令

echo 8192 > /proc/sys/vm/min_free_kbytes

加大到 8Mbytes, 這樣可以減少 page allocation 失敗的機率, 在我們的測試內, 某些時候 8MByte 仍會出現, 可以考慮加大到 16Mbytes.

原因是因為在 interrupt 中, 向系統一次要求大塊的記憶體. 這時可以透過增加 min_free_kbytes 參數去避過這個問題.
調整 slab 的參數或許也有用 ( echo x y z > /proc/slab)

Ref.
http://lime-technology.com/forum/index.php?topic=3999.0
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-01/0059.html

The post [Linux][Kernel][Memory] smbd: page allocation failure. order:2, mode:0x20 appeared first on richliu's blog.