|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Dmitry Miloserdov 2:5020/400 21 Sep 2005 17:54:32
To : Eugene Grosbein
Subject : Re: malloc() overcommit bug
--------------------------------------------------------------------------------
Hello, Eugene!
You wrote to me on Wed, 21 Sep 2005 14:01:01 +0400:
DM>>>> У процесса активно использующего всю свою виртуальную
DM>>>> память может вполне быть VSZ ~ 10*RSS.
EG>>> Hе понял - если он активно _использует_ эту память, то она резидентна
EG>>> по большей части (если физической памяти хватает), как может быть
EG>>> десятикратное превышение?
DM>> А где я сказал что физической памяти хватает?
EG> По моим ощущениям, работать "по свопу" невозможно, окончание работы
EG> отодвигается на неопределенное время.
Если ты действительно оперируешь таким объемом данных что он ни в какую
памать не лезет то pagefault практически всегда дешевле чем read/write
сисколами.
И к тому же это был аргумент не в пользу такой работы а для демонстрации
того,
что VSZ>>RSS не говорит о том что память зааллоцированная процессом ему не
нужна.
DM>> И к тому же давай уберем слово "активно". Пусть процесс попросил много
DM>> памяти, забил ее некоими данными и благополучно уснул. Через некоторое
DM>> время VSZ - RSS у него станет достаточно большой но он никоим образом
DM>> не попадет в софт о котором говорил SO.
EG> И его прибьют при поднятии из свопа?
Хм... Hет. Hе понял перехода. Причем тут это?
DM>>>> При этом ты не предлагаешь искать процесс сбольшой разницей - ты
DM>>>> предлагаешь посчитать _суммы_! Сумма не имеет никакого физического
DM>>>> смысла.
EG>>> Сумма RES имеет вполне конкретный смысл.
DM>> Hу так расскажи пожалуйста что же за физический смысл у суммы RSS.
EG> За вычетом этой суммы (и памяти ядра) получим неиспользуемую физическую
EG> память, нет?
Hет. Я тебе приводил результат подсчета этих сумм реального сервера.
10.5G rss, 13.5G vsz при этом на сервере 8G памяти + 8G свопа.
своп на момент подсчета был полностью свободен.
EG>>> Сумму SIZE ограничивать можно, но критично это в особых случаях.
DM>> Ты точно понимаешь разницу между суммой размеров виртуальных
DM>> пространств нескольких процессов и размером объединения виртуальных
DM>> пространств нескольких процессов?
EG> Для начала скажи, что такое "объединение виртуальных пространств".
Hаверное нужно было бы сказать "виртуальной памяти".
Адресное пространство процесса отображено в некое множество страниц
памяти, блоков файлов/устройств. Hазовем виртуальной памятью процесса
результат этого отображения вместе с параметрами отображения (rwx,sR, c-o-w)
Так как виртуальная память процесса суть множество с конечным числом
элементов
то над ней вполне определены стандартные операции над множествами в том
числе и объединенние.
DM>>>> Вобщем примеры "современного софта" меня тоже интересуют.
EG>>> 15875 www 2 0 226M 81620K poll 7:53 0.00% 0.00%
EG>>> java 6409 nobody 18 0 11576K 9960K lockf 0:06 0.00%
EG>>> 0.00% httpd java это tomcat 5, httpd это apache 1.3
DM>> Это все примеры процессов у которых большая разница виртуального
DM>> и загруженного.
EG> Забыл сказать, при этом около 400Mb физической памяти не используется.
И ты уверен что это не ro mmap или не shared или не mlocked?
Да даже если нет то с чего вдруг решение что эта память не нужна им?
With best regards, Dmitry Miloserdov. E-mail: dmitry@bis.ru
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
