Несоответствие в использовании памяти POD и RSS от PS узла - PullRequest
Новая
       7

Несоответствие в использовании памяти POD и RSS от PS узла

0 голосов
/ 23 марта 2020

Я развернул metrics-server в моем кластере K8s (версия 1.15)
Я понял, что это стандартный способ выполнения простых проверок использования mem

У меня есть POD, который содержит несколько процессов ( dumb-init

Я хочу узнать точное текущее использование памяти моего POD.

Вывод kube-capacity --util --pods: 

NODE      NAMESPACE           POD                               CPU REQUESTS   CPU LIMITS   CPU UTIL      MEMORY REQUESTS   MEMORY LIMITS   MEMORY UTIL
sj-k8s1   kube-system         kube-apiserver-sj-k8s1            250m (6%)      0m (0%)      77m (1%)      0Mi (0%)          0Mi (0%)        207Mi (2%)

...
sj-k8s3   salt-provisioning   salt-master-7dcf7cfb6c-l8tth      0m (0%)        0m (0%)      220m (5%)     1536Mi (19%)      3072Mi (39%)    1580Mi (20%)

Показывает, что POD salt-master в настоящее время использует ~ 1,6 Ги, а Kubeapi использует ~ 200Mi * ​​1014 *

Однако при выполнении sj-k8s3 команда ps aux | awk '$12 ~ /salt-master/ {sum += $6} END {print sum}' (сумма RSS из вывода PS): 

2051208

Что составляет ~ 2 Ги, вывод /sys/fs/cgroup/memory/memory.stats: 

cache 173740032
rss 1523937280
rss_huge 0
shmem 331776
mapped_file 53248
dirty 4096
writeback 0
pgpgin 34692690
pgpgout 34278218
pgfault 212566509
pgmajfault 6
inactive_anon 331776
active_anon 1523916800
inactive_file 155201536
active_file 18206720
unevictable 0
hierarchical_memory_limit 2147483648
total_cache 173740032
total_rss 1523937280
total_rss_huge 0
total_shmem 331776
total_mapped_file 53248
total_dirty 4096
total_writeback 0
total_pgpgin 34692690
total_pgpgout 34278218
total_pgfault 212566509
total_pgmajfault 6
total_inactive_anon 331776
total_active_anon 1523916800
total_inactive_file 155201536
total_active_file 18206720
total_unevictable 0

Этот POD на самом деле содержит два docker контейнера, поэтому фактическая сумма RSS составляет: 

2296688

, что еще больше: 2.3Gi

На узле apiserver выполнение только ps aux показывает, что процесс RSS имеет вид: 447948 Вывод /sys/fs/cgroup/memory/memory.stats: 

cache 78499840
rss 391188480
rss_huge 12582912
shmem 0
mapped_file 69423104
dirty 0
writeback 0
pgpgin 111883
pgpgout 1812
pgfault 100603
pgmajfault 624
inactive_anon 0
active_anon 215531520
inactive_file 253870080
active_file 270336
unevictable 0
hierarchical_memory_limit 8361357312
total_cache 78499840
total_rss 391188480
total_rss_huge 12582912
total_shmem 0
total_mapped_file 69423104
total_dirty 0
total_writeback 0
total_pgpgin 111883
total_pgpgout 1812
total_pgfault 100603
total_pgmajfault 624
total_inactive_anon 0
total_active_anon 215531520
total_inactive_file 253870080
total_active_file 270336
total_unevictable 0

Может кто-нибудь объяснить, почему Заявленное использование памяти POD отличается от простого ps почти на 40% (для процесса apiserver на 100)?

РЕДАКТИРОВАТЬ: Я обновил сообщенные значения памяти, чтобы включить вывод /sys/fs/cgroup/memory/memory.stat, который, кажется, + - соответствует использованию POD, сообщенному kube-capacity
Как предложено в первом комментарии: означает ли это, что разница является общей памятью только (сообщается PS, но не метриками POD / cgroup)?
Разница довольно большая

1 Ответ

1 голос
/ 25 марта 2020

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

Понимание использования памяти на Linux - очень хорошая статья, описывающая, как работает использование памяти в Linux и что на самом деле сообщает ps.

Почему ps является "неправильным"

В зависимости от того, как вы на это смотрите, ps не сообщает о реальном использовании памяти процессами. На самом деле он показывает, сколько реальной памяти каждый процесс занимал бы , если бы это был единственный процесс, выполняющий . Конечно, типичная машина Linux имеет несколько десятков процессов, работающих в любой момент времени, что означает, что номера VSZ и RSS, сообщаемые ps, почти определенно неверны .

Именно поэтому ps не следует использовать для некоторых подробных данных о потреблении памяти.

Альтернативой ps будет smem. Он сообщает об использовании физической памяти с учетом страниц с общей памятью. Затем о неразделенной памяти сообщается в USS (уникальный размер набора). Таким образом, вы можете использовать USS, если хотите игнорировать разделяемую память.

Доля неразделенной памяти (USS) плюс доля общей памяти процесса указана в PSS (Размер пропорционального набора). По существу, он добавляет USS вместе с долей общей памяти, деленной на количество процессов, разделяющих эту память.

С другой стороны RSS (Resident Set Size) - это объем общей памяти плюс неразделенная память, используемая каждым процессом. Если какие-либо процессы совместно используют память, это приведет к короткому сообщению об объеме памяти, который фактически используется.

Linux использует технику управления ресурсами, используемую в программировании, для эффективной реализации операции duplicate или copy. Это называется copy-on-write. Поэтому, когда у вас есть родительский и дочерний процессы, они оба будут показывать одинаковые RSS. С copy-on-write linux гарантирует, что оба процесса действительно используют одну и ту же память.

...