Linux (não transparente) contabilidade de página de página por processo

Question

Eu recentemente converti alguns aplicativos java para rodar com as páginas do Linux configuradas manualmente, como descrito aqui . Eu indico "configurados manualmente" porque eles não são hugepages transparentes , o que nos deu algumas problemas de desempenho .

Então, agora, tenho cerca de 10 tomcat em execução em um sistema e estou interessado em saber quanto de memória cada um está usando.

Eu posso obter informações resumidas de /proc/meminfo , conforme descrito em Contabilidade de uso de páginas enormes do Linux .

Mas não consigo encontrar nenhuma ferramenta que me informe sobre o uso real da página de passagem por processo.

Eu procurei em /proc/pid/numa_stat e encontrei algumas informações interessantes que me levaram a essa grosseria:

function pshugepage () {
    HUGEPAGECOUNT=0
    for num in 'grep 'anon_hugepage.*dirty=' /proc/$@/numa_maps | awk '{print $6}' | sed 's/dirty=//'' ; do
        HUGEPAGECOUNT=$((HUGEPAGECOUNT+num))
    done
    echo process $@ using $HUGEPAGECOUNT huge pages
}

ou isso, em perl:

sub counthugepages {
    my $pid=$_[0];
    open (NUMAMAPS, "/proc/$pid/numa_maps") || die "can't open numa_maps";
    my $HUGEPAGECOUNT=0;
    while (my $line=<NUMAMAPS>) {
        next unless ($line =~ m{ huge }) ;
        next unless ($line =~ m{dirty=});
        chomp $line;
        $line =~ s{.*dirty=}{};
        $line =~ s{\s.*$}{};
        $HUGEPAGECOUNT+=$line;
    }
    close NUMAMAPS;
    # we want megabytes out, but we counted 2-megabyte hugepages
    return ($HUGEPAGECOUNT*2);
}

Os números que isso me dá são plausíveis, mas estou longe de ter certeza de que esse método está correto.

Ambiente é um dell de quatro CPUs, 64GB de RAM, RHEL6.3, oracle jdk 1.7.x (atual a partir de 20130728)

    

Answer 1

Atualização: A Red Hat agora recomenda este método para contabilidade de página de processo no RHEL5 / 6:

grep -B 11 'KernelPageSize:     2048 kB' /proc/[PID]/smaps \
   | grep "^Size:" \
   | awk 'BEGIN{sum=0}{sum+=$2}END{print sum/1024}'

Eu perguntei isso na lista de discussão dos desenvolvedores do procps-ng. Foi-me dito:

The hugepage support has been introduced in the procps-ng/pmap tool several months ago (switches -XX, -C, -c, -N, -n should allow you to configure and display any entries supported by the running kernel).

Eu experimentei um pouco com isso com o procps-3.3.8 no fedora 19. Eu não acho que isso me deu qualquer informação que eu não recebi das coisas que eu sugeri na minha pergunta, mas pelo menos tem a aura de autoridade.

FWIW Acabei com o seguinte:

Arquivo .pmaprc contendo:

[Fields Display]
Size
Rss
Pss
Referenced
AnonHugePages
KernelPageSize
Mapping

[Mapping]
ShowPath

E então eu usei o seguinte comando para puxar a informação da hugepage:

pmap -c [process id here] | egrep 'Add|2048'

no grep, "Add" é para a linha de cabeçalho. "2048" vai pegar qualquer coisa com um tamanho de página do kernel de 2048, ou seja, páginas enormes. Também vai pegar coisas não relacionadas.

Veja um exemplo de saída:

     Address    Size   Rss   Pss Referenced AnonHugePages KernelPageSize Mapping
    ed800000   22528     0     0          0             0           2048 /anon_hugepage (deleted)
    f7e00000   88064     0     0          0             0           2048 /anon_hugepage (deleted)
    fd400000   45056     0     0          0             0           2048 /anon_hugepage (deleted)
7f3753dff000    2052  2048  2048       2048          2048              4 [stack:1674]
7f3759000000    4096     0     0          0             0           2048 /anon_hugepage (deleted)
7f3762d68000    2048     0     0          0             0              4 /usr/lib64/libc-2.17.so
7f376339b000    2048     0     0          0             0              4 /usr/lib64/libpthread-2.17.so

Nós nos preocupamos apenas com as linhas do kernelPageSize 2048.

Acho que está me dizendo que aloquei 159744 Kbytes (22528 + 88064 + 45056 + 4096) de RAM em páginas enormes. Eu disse ao java para usar exatamente 128M para seu heap, e ele tem alguns outros pools de memória, então esse é um número plausível. Rss & O referenciado 0 não faz muito sentido, no entanto, o programa Java de teste é extremamente simples, por isso também é plausível.

Ele não concorda com o número que recebo do meu snippet perl acima, porque o perl está pesquisando apenas páginas "sujas" - aquelas que foram realmente usadas. E / ou porque o perl está errado, não sei.

Eu também tentei o procps 3.3.9 em uma máquina RHEL6 com alguns tomcats ativos usando muita memória hugepage. O Rss & Colunas referenciadas foram todas 0. Isso pode muito bem ser culpa do kernel em vez de procps, eu não sei.

    

Answer 2

Melhor script perl

#!/usr/bin/perl
#
sub counthugepages {
    my $pid=$_[0];
    open (NUMAMAPS, "/proc/$pid/numa_maps") || die "can't open numa_maps";
    my $HUGEPAGECOUNT=0;
    while (<NUMAMAPS>) {
        if (/huge.*dirty=(\d+)/) {
          $HUGEPAGECOUNT+=$1;
        }
    }
    close NUMAMAPS;
    return ($HUGEPAGECOUNT);
}

printf "%d huge pages\n",counthugepages($ARGV[0]);