Я хочу понять отношения
container_memory_working_set_bytes vs process_resident_memory_bytes vs total_rss (container_memory_rss) + file_mapped, чтобы лучше оснащенная система для предупреждения о возможности OOM.
Это кажется противоречащим моему пониманию (что меня сейчас озадачивает), учитывая, если в контейнере / модуле выполняется один процесс, выполняющий скомпилированную программу, написанную на Go.
Почему разница между container_memory_working_set_bytes такая большая (почти в 10 раз) по сравнению с process_resident_memory_bytes
Также отношения между container_memory_working_set_bytes и container_memory_rss + file_mapped здесь странные, чего я не ожидал, прочитав здесь
Общий объем анонимной кэш-памяти и кеш-памяти подкачки (включая прозрачные огромные страницы), равен значению total_rss из файла memory.status. Это не следует путать с истинным размером резидентного набора или объемом физической памяти, используемой контрольной группой. rss + file_mapped даст вам размер резидентного набора cgroup. Он не включает память, которая выгружена. Он действительно включает память из разделяемых библиотек, если страницы из этих библиотек действительно находятся в памяти. Он включает всю стековую и кучную память.
Итак, cgroup общий размер резидентного набора равен rss + file_mapped, почему это значение меньше container_working_set_bytes для контейнера, который работает в данной контрольной группе
Что заставляет меня чувствовать что-то с этой статистикой, что я не прав.
Ниже приведены PROMQL, использованные для построения приведенного выше графика.
- process_resident_memory_bytes {контейнер = sftp-загрузчик}
- container_memory_working_set_bytes {container = sftp-downloader}
- go_memstats_heap_alloc_bytes {контейнер = sftp-downloader}
- container_memory_mapped_file {container = sftp-downloader} + container_memory_rss {container = sftp-downloader}
