У меня очень странный случай использования памяти на нашем сервере ubuntu. Один процесс (который выполняется с помощью sphinxsearch) выделил почти всю доступную память, а его VSize, RSS и SHR почти равны (около 18 ГБ). Но что меня действительно удивляет, так это то, что эта команда 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 делает некоторые хитрые трюки, чтобы сохранить память, но в то же время она доступна для системы, когда это необходимо. И, возможно, это не работает полностью, как ожидалось. Но это только мое безумное предположение, и здесь я могу ошибаться.
Запись «Кэшировано» подсчитывает количество страниц, помеченных как «общие». Указанные сопоставления помечены как общие.
Ядро внутренне не видит разницы в памяти, которая установлена с помощью флага общего доступа, и файла, который просто был загружен операционной системой и сохранен в кеше (все файлы в кеше фактически являются общими сопоставлениями).
Тот факт, что это поддерживается / dev / zero, несущественен. Причина, по которой они являются общими, почти наверняка связана с тем, что одни и те же данные в памяти должны быть доступны для всех дочерних процессов, которые изменяют данные.
С точки зрения семантики он ведет себя как обычно выделяемая память (или анонимная память), учитывая, что на самом деле нет пригодного для использования файла, в который вы можете удалить страницы (/ dev / zero - это не тот файл, в который вы можете сохранять), и страницы будут перемещены в поменять местами, если они не использовались.
Так что - что сбивает с толку - учетные записи данных как «кэшированные», но фактически обрабатываются как анонимно поддерживаемая память.
Вы можете убедиться, что это именно так в вашем меминфо:
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.
«файл» на самом деле является тем, что файл поддерживается, «анон» - это то, что не имеет файла, поддерживающего его - как и ваши сопоставления.