Linux: объем памяти процесса соответствует кэшированному объему
У меня очень странный случай использования памяти на нашем сервере ubuntu. Один процесс (который является searchd от sphinxsearch) выделил почти всю доступную память, а его VSize, RSS и SHR почти равны (около 18 ГБ). Но что меня действительно удивляет, так это то, что команда free обрабатывает большую часть этой памяти как «кэшированную» «- который я всегда считал« принадлежащим ядру », то есть - не привязанным к конкретному процессу. Кроме того, в то же время он отмечен как« общий », хотя других процессов с таким высоким использованием памяти нет.
Итак, free -h показывает:
root@st3:/proc/31633# free -h
total used free shared buffers cached
Mem: 23G 22G 649M 18G 62M 18G
-/+ buffers/cache: 4.4G 19G
Swap: 0B 0B 0B
Но для процесса searchd у нас есть:
VmPeak: 20451512 kB
VmSize: 20413352 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 20325488 kB
VmRSS: 20287332 kB
VmData: 1344768 kB
VmStk: 136 kB
VmExe: 4268 kB
VmLib: 16204 kB
VmPTE: 39924 kB
VmSwap: 0 kB
Поэтому я не могу понять, что здесь на самом деле используется - похоже, большая часть памяти используется только для кеширования, поэтому не должно быть проблемой, OTOH мы уже столкнулись с несколькими сбоями с "Невозможно выделить память" для простой вилки, поэтому я пытаюсь понять Это.
Если вам нужно больше, вот полный meminfo с этого компьютера , а вот полный список отображений памяти процесса searchd .
И глядя на последний, я вижу много:
7f7c905b7000-7f7c90713000 rw-s 00000000 00:05 226801755 /dev/zero (deleted)
7f7c90713000-7f7c91fff000 rw-s 00000000 00:05 225400928 /dev/zero (deleted)
7f7c92055000-7f7c921c7000 rw-s 00000000 00:05 226767567 /dev/zero (deleted)
7f7c921da000-7f7c92338000 rw-s 00000000 00:05 226774289 /dev/zero (deleted)
... так что я могу только догадываться, что это может быть точка, что searchd проделывает некоторые хитрые трюки, чтобы сохранить память, но в той же точке она доступны для системы при необходимости. И, возможно, это не работает полностью, как ожидалось.Но это только мое безумное предположение, и здесь я могу ошибаться.
Запись 'Cached' (кэшированная) подсчитывает количество страниц, помеченных как 'общие'. Приведенные связки помечены как shared.
Внутренне ядро не видит разницы в памяти, которая установлена флагом shared и файлом, который просто каталогизируется операционной системой и хранится в кэше (все файлы в кэше фактически являются связками shared).
Тот факт, что это поддерживается /dev/zero, несущественен. Причина, по которой они совместно используются, почти наверняка заключается в том, что одни и те же данные памяти должны быть доступны всем дочерним процессам, которые изменяют данные.
С семантической точки зрения, он ведет себя как обычно выделенная память (или анонимная память), поскольку на самом деле нет файла, в который можно выселить страницы (/dev/zero - это не совсем тот файл, в который можно сохранить), и страницы перемещались бы в подкачку, если бы они не использовались.
Так что - путаница - учетные записи данных 'кэшируются', но на самом деле обрабатываются как анонимная память.
Вы можете видеть, что именно так и происходит в вашем meminfo:
root@st3:/proc/31633# cat /proc/meminfo
MemTotal: 24690512 kB
...
Cached: 19504260 kB
...
Active(anon): 3734376 kB
Inactive(anon): 18973184 kB
Active(file): 227128 kB
Inactive(file): 365828 kB
...
Mapped: 19237684 kB
Shmem: 18985464 kB
...
То же самое происходит, если вы используете разделяемую память IPC.
'file' на самом деле - это то, что бэк-файл, 'anon' - это то, что не имеет файла бэк-файла -- как ваши отображения.
.