Как контролировать использование Огромных Страниц для каждого процесса

Если Вы уверены это

  1. ошибка вызывается в рамках сценария
  2. вызов sudo корректен

затем проблема по всей вероятности не sudo. Существует несколько случаев, в которых корню не позволяют удалить файл:

  1. Файл находится на объеме, который смонтирован только для чтения (см. cat /proc/mounts).
  2. Файл защищен атрибутами файловой системы (см. lsattr "$path").
  3. Родительский каталог защищен атрибутами файловой системы.
  4. Представьте себе прошедший материал ядра (SELinux, Apparmor).

Может также быть полезно добавить несколько секунд времени ожидания в сценарии и присоединении с strace к нему (как корень): strace -f -p $PID

4
23.05.2017, 15:40
4 ответа

Я нашел дискуссию на ServerFault, который обсуждает это. В основном

$ sudo grep huge /proc/*/numa_maps
/proc/4131/numa_maps:80000000 default file=/anon_hugepage\040(deleted) huge anon=4 dirty=4 N0=3 N1=1
/proc/4131/numa_maps:581a00000 default file=/anon_hugepage\040(deleted) huge anon=258 dirty=258 N0=150 N1=108
/proc/4131/numa_maps:7f6c40400000 default file=/anon_hugepage\040(deleted) huge
/proc/4131/numa_maps:7f6ce5000000 default file=/anon_hugepage\040(deleted) huge anon=1 dirty=1 N0=1
/proc/4153/numa_maps:80000000 default file=/anon_hugepage\040(deleted) huge anon=7 dirty=7 N0=6 N1=1
/proc/4153/numa_maps:581a00000 default file=/anon_hugepage\040(deleted) huge anon=265 dirty=265 N0=162 N1=103
/proc/4153/numa_maps:7f3dc8400000 default file=/anon_hugepage\040(deleted) huge
/proc/4153/numa_maps:7f3e00600000 default file=/anon_hugepage\040(deleted) huge anon=1 dirty=1 N0=1

и получение имени процесса

$ ps 4131
  PID TTY      STAT   TIME COMMAND
 4131 ?        Sl     1:08 /var/lib/jenkins/java/bin/java -jar slave.jar
$ ps 4153
  PID TTY      STAT   TIME COMMAND
 4153 ?        Sl     1:09 /var/lib/jenkins/java/bin/java -jar slave.jar

даст вам представление о том, какие процессы используют огромную память.

$ grep HugePages /proc/meminfo
AnonHugePages:   1079296 kB
HugePages_Total:    4096
HugePages_Free:     3560
HugePages_Rsvd:      234
HugePages_Surp:        0

$ sudo ~/bin/counthugepages.pl 4153
273 huge pages
$ sudo ~/bin/counthugepages.pl 4131
263 huge pages

Сумма свободных страниц (3560) плюс страницы из 2 процесса (273 + 263) равна 4096. Все объяснены!

Скрипт Perl для суммирования поля = здесь:

https://serverfault.com/questions/527085/linux-non-transparent-per-process-hugePage- 644471 # 644471

7
27.01.2020, 20:47

Просмотр документации / PROC , я вижу, что огромное использование страницы записывается в / proc / pid / smaps с флагом HT В VMFlags и (кроме страниц, поддерживаемых файлами) с помощью поля .

grep '^VmFlags:.* ht' /proc/[0-9]*/smaps
3
27.01.2020, 20:47

Red Hat рекомендует следующее:

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

Подробнее на мой вопрос по serverfault.

1
27.01.2020, 20:47

Чтобы увидеть использование огромных страниц для данного процесса, запустите

numastat -p PID

с соответствующим идентификатором процесса.

1
22.09.2021, 11:40

Теги

Похожие вопросы