Estou respondendo à tag linux . Minha resposta é específica apenas para Linux .
Sim, páginas enormes são mais propensas a fragmentação. Existem duas visões de memória, aquela que seu processo obtém (virtual) e aquela que o kernel gerencia (real). Quanto maior for qualquer página, mais difícil será agrupar (e manter) os vizinhos, especialmente quando o serviço estiver sendo executado em um sistema que também tenha que suportar outros que, por padrão, alocam e gravam mais memória do que na verdade acabam usando.
O mapeamento do kernel de endereços concedidos (reais) é privado. Há uma boa razão pela qual o userspace os vê como o kernel os apresenta, porque o kernel precisa ser capaz de supercomprimir sem confundir o espaço do usuário. O seu processo obtém um espaço de endereçamento contíguo, "Disneyfied" , no qual trabalhar, alheio ao que o kernel está realmente fazendo com essa memória nos bastidores.
O motivo pelo qual você vê desempenho degradado em servidores de longa execução é mais provável porque os blocos alocados que não foram explicitamente bloqueados (por exemplo, mlock() / mlockall() ou posix_madvise() ) e não modificados em um tempo foram paginou , o que significa que o seu serviço desliza para o disco quando é necessário lê-lo. Modificar esse comportamento torna seu processo um vizinho ruim , e é por isso que muitas pessoas colocam seu RDBMS em um servidor completamente diferente de web / php / python / ruby / whatever. A única maneira de consertar isso, no mínimo, é reduzir a competição por blocos contíguos.
A fragmentação só é realmente perceptível (na maioria dos casos) quando a página A está na memória e a página B foi movida para swap. Naturalmente, reiniciar seu serviço pareceria "curar" isso, mas somente porque o kernel ainda não teve a oportunidade de mostrar o processo (agora) recém alocados blocos dentro dos limites de sua taxa de supercomprometimento.
Na verdade, reiniciar (digamos) o 'apache' sob uma carga alta provavelmente enviará blocos de propriedade de outros serviços diretamente para o disco. Então, sim, o 'apache' melhoraria por um curto período de tempo, mas o 'mysql' poderia sofrer ... pelo menos até que o kernel faça com que sofram igualmente quando houver simplesmente falta de memória física suficiente.
Adicione mais memória ou divida-se exigindo malloc() consumidores :) Não é apenas a fragmentação que você precisa analisar.
Teste vmstat para obter uma visão geral do que realmente está sendo armazenado.