ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Eugene Grosbein                      2:5006/1       21 Sep 2005  22:00:11
 To : Dmitry Miloserdov
 Subject : Re: malloc() overcommit bug
 -------------------------------------------------------------------------------- 
 

 21 сен 2005, среда, в 16:54 KRAST, Dmitry Miloserdov написал(а):
 
  EG>>>> Hе понял - если он активно _использует_ эту память, то она резидентна
  EG>>>> по большей части (если физической памяти хватает), как может быть
  EG>>>> десятикратное превышение?
  DM>>> А где я сказал что физической памяти хватает?
  EG>> По моим ощущениям, работать "по свопу" невозможно, окончание работы
  EG>> отодвигается на неопределенное время.
  DM> Если ты действительно оперируешь таким объемом данных что он ни в какую
  DM> памать не лезет то pagefault практически всегда дешевле чем read/write
  DM> сисколами.
 
 Работать "по свопу" - это использовать виртуальную память, как физическую,
 ни о чем не думая. Работать так обычно невозможно, уж очень медленно.
 
 А если думаешь, что делаешь с памятью, то read/write может быть и быстрее
 за счет того, что лучше системы знаешь, поверх чего писать то, что читаешь.
 
  DM> И к тому же это был аргумент не в пользу такой работы а для демонстрации
  DM> того,
  DM> что VSZ>>RSS не говорит о том что память зааллоцированная процессом ему не
  DM> нужна.
 
 Она ему далеко не факт, что нужна. Очень часто и не будет нужна до exit().
 
  DM>>> И к тому же давай уберем слово "активно". Пусть процесс попросил много
  DM>>> памяти, забил ее некоими данными и благополучно уснул. Через некоторое
  DM>>> время VSZ - RSS  у него станет достаточно большой но он никоим образом
  DM>>> не попадет в софт о котором говорил SO.
  EG>> И его прибьют при поднятии из свопа?
  DM> Хм... Hет. Hе понял перехода. Причем тут это?
 
 Если не прибьют, то и проблемы у него нет.
 
  DM>>>>> При этом ты не предлагаешь искать процесс сбольшой разницей - ты
  DM>>>>> предлагаешь посчитать _суммы_! Сумма не имеет никакого физического
  DM>>>>> смысла.
  EG>>>> Сумма RES имеет вполне конкретный смысл.
  DM>>> Hу так расскажи пожалуйста что же за физический смысл у суммы RSS.
  EG>> За вычетом этой суммы (и памяти ядра) получим неиспользуемую физическую
  EG>> память, нет?
  DM> Hет. Я тебе приводил результат подсчета этих сумм реального сервера.
  DM> 10.5G rss, 13.5G vsz при этом на сервере 8G памяти + 8G свопа.
  DM> своп на момент подсчета был полностью свободен.
 
 У независимых процессов может быть общая часть rss?
 
  EG>>>>  Сумму SIZE ограничивать можно, но критично это в особых случаях.
  DM>>> Ты точно понимаешь разницу между суммой размеров виртуальных
  DM>>> пространств нескольких процессов и размером объединения виртуальных
  DM>>> пространств нескольких процессов?
 
 Да.
 
  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 физической памяти не используется.
  DM> И ты уверен что это не ro mmap или не shared или не mlocked?
 
 Да. Hе ro однозначно, не shared (не с кем) и не mlocked - руки коротки.
 
  DM> Да даже если нет то с чего вдруг решение что эта память не нужна им?
 
 Была бы нужна - RES был бы больше, памяти хватает. Аптайм уже несколько
 суток, нагрузка стабильна.
 
 Eugene
 -- 
 http://www.livejournal.com/users/dadv/
 --- slrn/0.9.8.0 (FreeBSD)
  * Origin: Svyaz Service JSC (2:5006/1@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор