link sugere que é um bug do kernel, e há uma correção para o Trusty que tem só muito recentemente foi lançado. Desculpe, mas não posso resolver o problema agora (me afeta também, exatamente o mesmo comportamento).
Alguns detalhes do ambiente primeiro:
Hardware:
Placa para servidor Intel S2600GZ
2 x processador Intel Xeon E5-2620
64GB DDR3 RAM
Controlador Intel RAID RS2BL (LSI SAS2108) com 4 TB de volume LVM feito de discos SAS
Software:
Ubuntu 12.04.4 LTS / Linux 3.11.0-24-genérico x86_64 (com as últimas atualizações)
qemu / KVM (libvirt) com 6 VMs (rodando sem problemas apesar da situação)
glusterfs server 3.4.5 (parece funcionar normalmente também)
outros softwares lightweght soft (por exemplo, bind9, keepalived, openvpn etc.) NO custom / experimental / homegrown!
Já há muito tempo que temos um problema muito estranho com um dos nossos servidores Ubuntu: periodicamente, ele inunda o syslog com mensagens de "falha de alocação" como estas:
Aug 28 07:00:18 srvname kernel: [4210234.157335] irqbalance: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:19 srvname kernel: [4210234.711173] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:20 srvname kernel: [4210235.938599] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:34 srvname kernel: [4210250.307283] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:51 srvname kernel: [4210267.170359] irqbalance: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:01:02 srvname kernel: [4210278.625530] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:01:19 srvname kernel: [4210295.671569] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
As mensagens são registradas aproximadamente a cada 30 segundos e refletem a imagem real: os processos mostrados neste snippet de log estão realmente falhando (por exemplo, o agente do zabbix não consegue transmitir dados para o servidor zabbix). Mas é apenas a ponta do iceberg. Enquanto esta exaustão de memória está acontecendo qualquer processo que precisa ler o diretório /proc (por exemplo, ps , top , mpstat etc.) falha logo após iniciar porque não consegue ler ele ( /proc também não pode ser listado manualmente com ls ) e esse evento é imediatamente registrado no syslog com o mesmo erro de falha de alocação do pedido 4.
Com tudo isso, há bastante RAM livre (1/4 do tamanho total), mas se formos verificar por blocos - os blocos da ordem 4 estão realmente esgotados. MAS , o que eu realmente não consigo entender é PORQUÊ esses processos realmente solicitam blocos tão grandes? Temos outro servidor quase idêntico (por hardware e software) - seus blocos de ordem 4 também estão esgotados - e parece bom, não há falhas de alocação na ordem 4! Além disso, este servidor idêntico está sob MUITO carregamento mais pesado.
Eu pesquisei na Web muitas vezes por "sintomas de falhas de alocação de alta ordem", mas nada parece ser relevante. Nós tentamos jogar com vários parâmetros sysctl (por exemplo, vm.min_free_kbytes , vm.vfs_cache_pressure etc., como sugerido por alguns artigos), mas nada ajuda. Eventualmente, estamos revertendo todas essas mudanças e agora a maioria das configurações de sysctl são padrão do sistema. Também tentamos echo ing para /proc/sys/vm/compact_memory e /proc/sys/vm/drop_caches sem nenhum efeito óbvio (ou prolongado). Depois de um longo período de exaustão, de repente e por si, tudo se torna normal (parece que a memória é desfragmentada e os blocos 4 estão disponíveis, /proc fica disponível também), mas não por muito tempo - depois de algum curto período começa de novo. Uma reinicialização ajuda por um período mais longo (devido à memória totalmente não fragmentada), mas eventualmente tudo acaba do mesmo jeito ...
Em geral, os únicos problemas reais (que estamos cientes de) causados pelo comportamento descrito são a incapacidade de monitorar e gerenciar recursos do servidor, nem remotamente (zabbix), nem localmente ( ps , top , mpstat etc.).
Tanto quanto eu entendo, a falta de ordem 4 blocos é um estado regular normal de memória no Linux. É só que os processos geralmente não devem solicitar tais blocos (especialmente processos que NÃO o fazem em outros servidores). Se alguém tem alguma idéia sobre o que poderia ser a causa de tal comportamento, o que podemos verificar ou onde cavar - nós realmente apreciaríamos! Estamos prontos para fornecer informações adicionais sob demanda.
link sugere que é um bug do kernel, e há uma correção para o Trusty que tem só muito recentemente foi lançado. Desculpe, mas não posso resolver o problema agora (me afeta também, exatamente o mesmo comportamento).
Tem certeza de que isso não é um problema de hardware? Se eu fosse você, suspeitaria de RAM. Tente rodar o memtest ou similar.
Tags memory linux ubuntu linux-kernel