|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 08 May 2005 13:31:56
To : Eugene Gladchenko
Subject : Re: RSS и shared memory
--------------------------------------------------------------------------------
>>> Eugene Gladchenko wrote:
EG>>> Как во FreeBSD я могу определить, какая часть из RSS процесса
EG>>> является на самом деле shared? ps(1) этого не показывает, top(1)
EG>>> тоже. В портах раньше был GTop.pm, который вроде через libgtop
EG>>> умел доставать эту информацию, но его уже год как убрали. Что
EG>>> делать?
VN>> А что именно ты пытаешься получить на основании этих данных?
EG> Вроде ж вопрос звучал: мне интересно знать, сколько реально памяти занимает
EG> некоторая группа процессов. Поскольку, просто просуммировав все RSS, я не
EG> получу искомое число (часть этих RSS разделена между процессами, причем не
EG> между всеми, а только некоторыми из них).
Видишь ли... в неё войдёт, например, libc.so, которая наверняка своей
заметной частью будет в RAM, но которую считать в потребление памяти
апачами при наличии дофига других процессов, которые хотят libc.so, будет
бессмысленно. Может быть ещё несколько таких библиотек - libcrypto
(как минимум её хочет sshd), libssl... Ответь на вопрос - ты их будешь
считать в этот потребляемый объём или нет? А если sshd убрать?
А считать разделяемые страницы как будешь? Есть страницы, которые
разделяются между двумя процессами, есть - между тремя, есть - между
половиной апачей, есть - между всеми. Их считаем одинаково?
Или возвращаясь к libc: если она не вся отображена - что будем считать и
почему? А если через секунду окажется отображено на 200K больше, потому
что управление пошло по необычной ветке?
Я к чему всё это веду - в mach-styled VM, которую реализует и FreeBSD и
большинство современных юниксов, и в которой RAM считается как кэш диска
(неважно, у тебя отображён файл, часть свопа или отображение
предоставляемое устройством) - все эти характеристики, которые ты хочешь -
они 1) условны, 2) временны (могут быстро меняться в зависимости от массы
посторонних факторов), 3) при всём при этом непрямо влияют на реальную
картину. И ко всему прочему они не масштабируются.
EG> Я, например, хочу знать, сколько я могу насоздавать детей Apache, чтобы все
EG> они при этом помещались в определенном количестве физической памяти.
Ты эти данные не получишь пока не определишь профиль нагрузки, который
будет влиять 1) на долю подгруженных страниц из бинарников и библиотек,
2) на характер использования и дублирования данных памяти. И когда
разделишь тот же объём RSS страниц процесса на файловый маппинг (скорее
всего, бинарники и библиотеки) и выделенную процессам память, у тебя
появятся только приблизительные данные от которых можно плясать (если
потребление swap-paged областей пересчитать линейно пропорционально
количеству процессов, а file-paged - не пересчитывать или увеличить совсем
незначительно). И всё равно финальный ответ даст только эксперимент.
EG> Или еще вот
EG> интересно узнать, насколько "распухают" мои httpd после запуска в результате
EG> copy-on-write. Или, по-другому, какая часть RSS поделена между всеми httpd.
EG> И сколько вообще реально памяти тратится на мою mod_perl-составляющую в
EG> процессе ее работы, то есть какая часть остается shared, а какая нет.
Гм... ну если найдёшь инструмент который в состоянии рассказывать по
memory map процесса сколько страниц в каждом отображении сидят в RAM -
тогда будет чем получить эти данные. Hо я боюсь, что этого никто не делал
по одной простой причине - эти данные на качество реальной работы влияют
слишком слабо.
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: RSS и shared memory