Назад | Перейти на главную страницу

Linux (непрозрачный) учет огромных страниц для каждого процесса

Недавно я преобразовал некоторые Java-приложения для работы с огромными страницами, настроенными в Linux вручную, как описано Вот. Я указываю на "настроенные вручную", потому что они не прозрачные огромные страницы, что дало нам проблемы с производительностью.

Итак, сейчас у меня в системе работает около 10 котов, и мне интересно знать, сколько памяти каждый из них использует.

Я могу получить сводную информацию из /proc/meminfo как описано в Учет использования огромных страниц в Linux.

Но я не могу найти никаких инструментов, которые рассказали бы мне о фактическом использовании огромных страниц для каждого процесса.

Я заглядывал в /proc/pid/numa_stat и нашел интересную информацию, которая привела меня к этой грубости:

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
}

или это в 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);
}

Цифры, которые он дает мне, правдоподобны, но я далеко не уверен, что этот метод верен.

Среда - четырехъядерный процессор dell, оперативная память 64 ГБ, RHEL6.3, oracle jdk 1.7.x (по состоянию на 20130728)

Обновить: Red Hat теперь рекомендует этот метод для обработки огромных страниц на RHEL5 / 6:

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

Я спросил об этом в списке рассылки разработчиков procps-ng. Мне сказали:

Поддержка огромных страниц была представлена в инструменте procps-ng / pmap несколько месяцев назад (переключатели -XX, -C, -c, -N, -n должны позволять вам настраивать и отображать любые записи, поддерживаемые работающим ядром).

Я немного поэкспериментировал с этим с помощью procps-3.3.8 на Fedora 19. Не думаю, что он дал мне какую-либо информацию, которую я не получил из того, что я предложил в своем вопросе, но, по крайней мере, он имеет ауру авторитета.

FWIW В итоге я получил следующее:

.pmaprc файл, содержащий:

[Fields Display]
Size
Rss
Pss
Referenced
AnonHugePages
KernelPageSize
Mapping

[Mapping]
ShowPath

А затем я использовал следующую команду для получения информации об огромных страницах:

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

в grep «Добавить» означает строку заголовка. «2048» захватит все, что имеет размер страницы ядра 2048, т. Е. Огромные страницы. Он также будет захватывать посторонние вещи.

Вот пример вывода:

     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

Мы заботимся только о строках с kernelPageSize 2048.

Думаю, это говорит мне о том, что я выделил 159744 Кбайт (22528 + 88064 + 45056 + 4096) ОЗУ на огромных страницах. Я сказал java использовать ровно 128 МБ для своей кучи, и у нее есть несколько других пулов памяти, так что это вероятное число. Rss & Referenced 0 не совсем понятен, однако тестовая java-программа чрезвычайно проста, так что она тоже правдоподобна.

Это не согласуется с числом, которое я получил из моего фрагмента perl выше, потому что perl ищет только «грязные» страницы - те, которые действительно использовались. И / или потому что Perl просто неправильный, я не знаю.

Я также пробовал procps 3.3.9 на машине RHEL6 с некоторыми активными котами, использующими много огромной памяти страниц. Все столбцы Rss и Referenced были 0. Это вполне может быть ошибкой ядра, а не procps, я не знаю.

Улучшенный скрипт 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]);