Мой сайт
Главная | Каталог статей | Регистрация | Вход
Среда
12.12.2018
11:04
Приветствую Вас Гость | RSS
Главная » Статьи » Linux и Unix

Как ядро Linux работает с оперативной памятью
Забавно, но читая флеймообразующий пост под авторством пользователя  LiS-31 обратил внимание на комментарии пользователя  HTaeD по поводу использования браузера Uzbl. Ссылочка от того же пользователя отправила меня в F.A.Q. от создателей сего браузера, который я сел читать в электричке по пути на работу. Интересно, что в F.A.Q.е я увидел вопрос, звучащий так:"Uzbl использует слишком много памяти! Особенно, когда работает в многооконном режиме (т.е. когда используются вкладки)". Авторы Uzbl дали такой ответ: 
Не дайте себя обмануть тем, как утилиты Linux показывают вам измеренное количество использованной памяти. Вы должны понимать как разницу между RSS (Resident Set Size) и VSS (Virtual Set Size), так и то, что динамические библиотеки (libwebkit, libgtk и т.д.) загружаются в память лишь однажды.

И далее авторы дают ссылку на интересную статью, объясняющую суть того, как же все таки ядро Linux работает с оперативной памятью.

Таки образом я решил сделать перевод этой статьи, так как уверен, что она будет полезна не только новичками (хоть и размещена в этом блоге). Итак.


Как ядро Linux работает с оперативной памятью

Эта небольшая статья предназначена для тех, кто хотя бы раз удивленно спрашивал себя нечто в стиле: "Какого черта простой текстовый редактор KDE занимает 25 Мб в оперативной памяти?" Множество людей уверовали в то, что приложения Linux, особенно входящие в состав KDE или Gnome, являются "раздутыми" или "тяжеловесными", основываясь только лишь на выводе утилит, подобных ps. Этот вывод может соответствовать действительности, а может и нет, это зависит от самой программы, но чаще всего - этот вывод ошибочен, т.к. на самом деле множество программ используют память намного эффективнее, чем это кажется.


О чем сообщает утилита ps

Утилита ps может выводить различную информацию о процессе, например такую как идентификатор процесса, его текущее состояние, то, как он(процесс) использует ресурсы. Так же возможным является вывод параметров VSZ(Virtual Set Size) и RSS(Resident Set Size). 
VSZ показывает, сколько виртуальной памяти выделено под процесс, а RSS показывает, сколько страниц физической(оперативной) памяти выделено под процесс. *примечание переводчика, т.е. меня :) 

В основном, эти два параметра используются "гиками" по всему миру для того, чтобы определить сколько памяти потребляет процесс.


В качестве примера давайте посмотрим на вывод команды ps aux на моем компьютере (вывод размеется урезан. *прим. переводчика):
1
2
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
dbunker   3468  0.0  2.7  25400 14452 ?        S    20:19   0:00 kdeinit: kedit


Судя по выводу утилиты ps, KEdit занимает порядка 25 Мб в области VSS и порядка 14 Мб в области RSS (оба значения показываются в килобайтах). Похоже, что большинству людей нравится наугад выбрать одно из значений как значение, реально отражающее потребление процессом оперативной памяти. Я не буду сейчас раскрывать суть различий между VSZ и RSS, не говоря уже о том, что такой подход в определении размера занимаемой процессом памяти ошибочен. Ни то ни другое значение в точности не отображают реально занимаемой памяти программой KEdit.


Почему использование утилиты ps ошибочно?

В зависимости от того, как вы на это смотрите, ps не сообщает размер реально занимаемой процессом памяти. Что эта утилита действительно делает, так это показывает сколько каждый процесс займет памяти в случае, как будто если бы он был единственным запущенным процессом. Разумеется, что обычно это не так и типичный компьютер под управлением Linux имеет несколько десятков процессов, работающих одновременно, что говорит о том, что значения VSZ и RSS, которые отображает утилита ps наверняка ошибочны. Для того чтобы понять, почему это так, необходимо понять как Linux управляет разделяемыми (динамически загружаемыми) библиотеками в контексте программ.

Большинство программ в Linux используют разделяемые библиотеки для использования реализованной в этих библиотеках функциональности. Например, текстовый редактор KDE использует несколько разделяемых библиотек KDE (для реализации возможностей взаимодейстовия с другими частями KDE), несколько библиотек X (для реализации возможностей отображения изображений и вставки/копирования из/в буфер) и основных системных библиотек (для того чтобы иметь возможность выполнять базовые операции). Многие из этих разделяемых библиотек, особенно такие часто используемые как libc, используются многими программами, запускаемых в Linux системах. Из-за этого совместного использования Linux использует следующий трюк: ядро загружает единственную копию разделяемой библиотеки в память и использует эту копию для каждой программы, которая нуждается в этой библиотеке.

Хорошо это или нет, но многие утилиты не заботятся о трюке, описанном выше; они просто сообщают, сколько памяти использует процесс не взирая на то, используется ли память совместно с другими процессами или нет. Две программы могут использовать большую разделяемую библиотеку, и место, занимаемое ей в памяти будет включено в подсчет занимаемой памяти обоими программами, т.о. библиотека будет посчитана дважды, что может ввести вас в заблуждение, если вы не знаете, что происходит.

К сожалению, достичь корректного отображения используемой процессом памяти не так просто. Требуется понимать не только то, как действительно работает система, но и решить несколько сложных вопросов. Должен ли размер памяти, занимаемой разделяемой библиотекой, необходимой только одному процессу учитываться в подсчете размера памяти занимаемой данным процессом? Если разделяемая библиотека используется множеством процессов, должна ли память занимаемая ей, быть равномерно распределена среди процессов ее использующих или же размер занимаемой памяти должен быть проигнорирован и не учтен? Здесь нет быстрого и однозначного решения: у вас должны быть различные ответы в зависимости от ситуации, с которой вы столкнулись. Теперь легко понять, почему утилита ps не пытается выдать однозначно "правильный" отчет об используемой процессом памяти, а выдает двусмысленный результат. 


Карта памяти процесса

Достаточно разговоров. Давайте посмотрим, почему KEdit занимает так много памяти. Для того чтобы увидеть, как выглядит память процесса KEdit мы будем использовать утилиту pmap (с флагом -d):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

Address   Kbytes Mode  Offset           Device    Mapping
08048000      40 r-x-- 0000000000000000 0fe:00000 kdeinit
08052000       4 rw--- 0000000000009000 0fe:00000 kdeinit
08053000    1164 rw--- 0000000008053000 000:00000   [ anon ]
40000000      84 r-x-- 0000000000000000 0fe:00000 ld-2.3.5.so
40015000       8 rw--- 0000000000014000 0fe:00000 ld-2.3.5.so
40017000       4 rw--- 0000000040017000 000:00000   [ anon ]
40018000       4 r-x-- 0000000000000000 0fe:00000 kedit.so
40019000       4 rw--- 0000000000000000 0fe:00000 kedit.so
40027000     252 r-x-- 0000000000000000 0fe:00000 libkparts.so.2.1.0
40066000      20 rw--- 000000000003e000 0fe:00000 libkparts.so.2.1.0
4006b000    3108 r-x-- 0000000000000000 0fe:00000 libkio.so.4.2.0
40374000     116 rw--- 0000000000309000 0fe:00000 libkio.so.4.2.0
40391000       8 rw--- 0000000040391000 000:00000   [ anon ]
40393000    2644 r-x-- 0000000000000000 0fe:00000 libkdeui.so.4.2.0
40628000     164 rw--- 0000000000295000 0fe:00000 libkdeui.so.4.2.0
40651000       4 rw--- 0000000040651000 000:00000   [ anon ]
40652000     100 r-x-- 0000000000000000 0fe:00000 libkdesu.so.4.2.0
4066b000       4 rw--- 0000000000019000 0fe:00000 libkdesu.so.4.2.0
4066c000      68 r-x-- 0000000000000000 0fe:00000 libkwalletclient.so.1.0.0
4067d000       4 rw--- 0000000000011000 0fe:00000 libkwalletclient.so.1.0.0
4067e000       4 rw--- 000000004067e000 000:00000   [ anon ]
4067f000    2148 r-x-- 0000000000000000 0fe:00000 libkdecore.so.4.2.0
40898000      64 rw--- 0000000000219000 0fe:00000 libkdecore.so.4.2.0
408a8000       8 rw--- 00000000408a8000 000:00000   [ anon ]
... (trimmed) ...
mapped: 25404K    writeable/private: 2432K    shared: 0K
 


Я убрал большую часть вывода: то что осталось, показано выше. Даже без полного вывода информации мы можем увидеть несколько очень интересных вещей. Первый важный момент, который надо отметить, это то, что каждая разделяемая библиотека отображается дважды; первый раз - это сегмент кода, второй раз - это сегмент данных. Сегмент кода имеет режим доступа "r-x--" (владелец(создатель) процесса может выполнять и читать сегмент кода. *прим. переводчика), в то время как сегмент данных имеет режим доступа "rw---" (владелец(создатель) процесса может читать из и писать в сегмент данных. *прим. переводчика). Интерес для нас будут представлять только столбцы KBytes, Mode и Mapping, все остальное в нашем случае не представляет интереса для нашего обсуждения.

Если вы просмотрите вывод, вы увидите что строки с самым большим значением в столбце KBytes обычно принадлежат кодовому сегменту, содержащемуся в разделяемых библиотеках (их имена начинаются с префикса "lib"). Важно отметить, что только кодовый сегмент может быть совместно использован различными процессами. Если убрать все кодовые сегменты и посчитать память, занимаемую только сегментами данных (с режимом доступа "rw---", то мы получим значение, записанное как writeable/private. Это значение как раз можно рассматривать как память, занимаемую процессом без учета памяти, занимаемой разделяемыми библиотеками. Поэтому, цена, которую мы заплатим за запуск экземпляра KEdit (предполагая, что все разделяемые библиотеки уже загружены) составит чуть больше 2 Мб. А это очень сильно отличается от 14 и 25 Мб, о которых нам сообщала утилита ps.


И что это все значит?

Мораль данной истории такова, что размер памяти, занимаемой процессом в Linux - это многогранный вопрос. Вы не можете просто запустить утилиту ps и узнать, что происходит. Особенно это верно в случае, когда вы имеете дело с программами, которые создают множество дочерних процессов (например Apache). ps может сообщать, что каждый процесс Apache занимает 10 Мб оперативной памяти, когда на самом деле, по максимуму, он занимает 1 Мб. Эта информация становится критичной тогда, когда вы настраиваете параметр MaxClients для Apache, который определяет как много одновременных подключений сервер может обработать. 

Так же, это показывает, почему лучше придерживаться "однотипных" приложений на рабочем столе на столько, насколько это возможно. Если вы используете KDE в качестве рабочего окружения, но при этом в основном пользуетесь приложениями Gnome, то вы платите высокую цену за множество избыточных (но разных) разделяемых библиотек. Придерживаясь насколько это возможно в использовании только приложений KDE или Gnome, в целом, вы уменьшаете общее количество используемой оперативной памяти из-за уменьшения количества памяти используемой под вновь запускаемые приложения KDE или Gnome, что позволяет Linux использовать больше памяти для других интересных вещей (например кэширование файлов, сильно ускоряющего доступ к фалам).


Источник: http://www.welinux.ru/post/2388/
Категория: Linux и Unix | Добавил: SAM (03.06.2010)
Просмотров: 2284 | Комментарии: 5 | Рейтинг: 0.0/0
Всего комментариев: 5
5 qjxfietebg  
coûts <a href=http://www.vmworld.com/thread/122157>Theo-24 Cr et la grossesse</a> http://www.vmworld.com/thread/121539>Skelaxin esdsas12

4 oigswfvyyi  
coûts <a href=http://www.vmworld.com/thread/121673>Aceon un autre nom pour</a> http://www.vmworld.com/thread/121468>Pamelor esdsas12

3 tlcqhjwngf  
coûts <a href=http://www.vmworld.com/thread/121447>Menosan Acheter</a> http://www.vmworld.com/thread/121444>Maxaquin esdsas12

2 rzmmcarand  
coûts <a href=http://www.vmworld.com/thread/121496>Propecia Acheter en ligne</a> http://www.vmworld.com/thread/121389>La fluoxetine esdsas12

1 Doomeorebew  
http://gfkdjghfkgjjkhj.com - gfkdjghfkgjjkh

Имя *:
Email *:
Код *:
Форма входа
Категории раздела
Мои статьи [1]
Linux и Unix [47]
Все про Linux и Unix
Windows [3]
Все про Windows
Администрирование [5]
Все для Системного администратора
Cisco [2]
Мой опыт работы с кисками
Поиск
Друзья сайта
  • Официальный блог
  • Сообщество uCoz
  • FAQ по системе
  • Инструкции для uCoz
  • Статистика

    Онлайн всего: 1
    Гостей: 1
    Пользователей: 0
    Copyright MyCorp © 2018
    Бесплатный конструктор сайтов - uCoz