Hay mucha memoria libre, pero estas zonas están totalmente fragmentadas:
Node 0 Normal: 1648026*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6592104kB
Node 1 Normal: 8390977*4kB 1181188*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB
Quedan muy pocas páginas de pedido distintas de cero, ninguna en una zona en absoluto.
No puedo garantizar nada, pero es posible que desee intentar desactivar ksmd y volver a compactar la memoria. La compactación solo se llama automáticamente en asignaciones de páginas de orden superior y nunca llama a oom-killer, por lo que asumo que el sistema ha intentado asignar memoria de los pedidos 2 o 3 y se atascó.
Para compactar la memoria, ejecute echo 1 >/proc/sys/vm/compact_memory
No hay mucho que hacer en esta pregunta, pero sospecho que ksmd está causando la fragmentación al buscar páginas duplicadas en ambas máquinas virtuales y cambiarlas por todas partes.
La respuesta de @Matthew debe marcarse como solución para este problema. El /proc/buddyinfo muestra claramente fragmentación (debido a ksmd u otro comportamiento). La compactación de memoria es una solución válida.
Acabamos de encontrar el mismo problema en nuestro servidor:
# cat /proc/buddyinfo
Node 0, zone DMA 1 0 1 0 0 1 0 0 0 1 3
Node 0, zone DMA32 4941 14025 10661 1462 1715 154 1 0 0 0 0
Node 0, zone Normal 420283 217678 3852 3 1 0 1 1 1 0 0
Node 1, zone Normal 1178429 294431 21420 340 7 2 1 2 0 0 0
Esto muestra claramente la fragmentación, ya que la mayor parte de la memoria está fragmentada en muchos bloques pequeños de memoria (un gran número a la izquierda, cero a la derecha).
Ahora la compactación resuelve esto:
# echo 1 >/proc/sys/vm/compact_memory
# cat /proc/buddyinfo
Node 0, zone DMA 1 0 1 0 0 1 0 0 0 1 3
Node 0, zone DMA32 485 1746 8588 3311 2076 505 98 19 3 0 0
Node 0, zone Normal 83764 22474 8597 3130 1971 1421 1090 808 556 358 95
Node 1, zone Normal 51928 36053 36093 29024 21498 13148 5719 1405 151 8 0