total used free shared buffers cached
Mem: 905376 894312 11064 0 520552 24976
-/+ buffers/cache: 348784 556592
Swap: 2000368 0 2000368
Linux (Gentoo). Слишком большой размер buffers-памяти (>50% total mem)
Добрый день!
Соверешенно случайно обнаружил SUBJ. Общий объем физической памяти 1 гиг. free выдает, что под buffers отведено 512 мег.
Подскажите, какие команды нужно запустить, какие файлы просмотреть, чтобы понять, для чего аллокировано столько места под буферы?
Я не хочу сказать, что это серьезная проблема для меня - машинка работает исправно. Но вопрос принципиальный - как узнать, зачем СТОЛЬКО? :)
Пробовал
1. искать в Гугле. Большинство статей посвящено архитектуре и приницпам. Полезно почитать, но почему-то нигде никто не сознается, как посмотреть содержимое buffers-памяти или хотя бы узнать, кто на нее претендует.
2. перерыл /proc раздел. Нашел только файл meminfo, который является аналогм команды free. Возможно что-то упустил? Может в ядре какой-то опции не хватает?
Кто сталкивался, плиз, подскажите.
Соверешенно случайно обнаружил SUBJ. Общий объем физической памяти 1 гиг. free выдает, что под buffers отведено 512 мег.
Код:
Подскажите, какие команды нужно запустить, какие файлы просмотреть, чтобы понять, для чего аллокировано столько места под буферы?
Я не хочу сказать, что это серьезная проблема для меня - машинка работает исправно. Но вопрос принципиальный - как узнать, зачем СТОЛЬКО? :)
Пробовал
1. искать в Гугле. Большинство статей посвящено архитектуре и приницпам. Полезно почитать, но почему-то нигде никто не сознается, как посмотреть содержимое buffers-памяти или хотя бы узнать, кто на нее претендует.
2. перерыл /proc раздел. Нашел только файл meminfo, который является аналогм команды free. Возможно что-то упустил? Может в ядре какой-то опции не хватает?
Кто сталкивался, плиз, подскажите.
http://www.linuxjournal.com/article/2770
изучите внимательно. после этого вопросы, я думаю отпадут.
изучите внимательно. после этого вопросы, я думаю отпадут.
2 squirL: спасибо за ссылочку, было поводом с чего начать. Рекомендую другим в качестве общего понимания на пользовательском уровне.
Ответ на свой вопрос я все таки нашел. Если в ядре (у меня сейчас последнее 2.6.23) использовать опцию стандартного SLAB allocator'а, то в появляется файлик /proc/slabinfo, в котором можео посмотреть текущую информацию о распределении памяти в ядре. Для стандартного аллокатора также разработана утилита slabtop, ориентированая только на чтение /slab/procinfo
Однако, многие рекомендуют использовать SLUB как наиболее оптимизированной алгоритм с точки зрения производительности и расширяемости системы (вроде он появился начиная с 2.6.22+). В случае SLUB (я его использую) такая информация не выдается (/proc/slabinfo отсутствует). Но в исходниках ядра в Documentation/vm можно вручную собрать утилитку slabinfo, которая также предоставит необходимую информацию.
Так или иначе посмотреть информацию можно. Ну и соответственно сделать выводы. А выводы таковы, что не стоит заморачиваться наличием большого объема buffer или cache памяти. Она используется для ускорения работы всей системы в целом. Например, одни из плюсов: нет необходимости часто делать подкачку с диска, если необходимые данные уже лежат в кеше.
Ответ на свой вопрос я все таки нашел. Если в ядре (у меня сейчас последнее 2.6.23) использовать опцию стандартного SLAB allocator'а, то в появляется файлик /proc/slabinfo, в котором можео посмотреть текущую информацию о распределении памяти в ядре. Для стандартного аллокатора также разработана утилита slabtop, ориентированая только на чтение /slab/procinfo
Однако, многие рекомендуют использовать SLUB как наиболее оптимизированной алгоритм с точки зрения производительности и расширяемости системы (вроде он появился начиная с 2.6.22+). В случае SLUB (я его использую) такая информация не выдается (/proc/slabinfo отсутствует). Но в исходниках ядра в Documentation/vm можно вручную собрать утилитку slabinfo, которая также предоставит необходимую информацию.
Так или иначе посмотреть информацию можно. Ну и соответственно сделать выводы. А выводы таковы, что не стоит заморачиваться наличием большого объема buffer или cache памяти. Она используется для ускорения работы всей системы в целом. Например, одни из плюсов: нет необходимости часто делать подкачку с диска, если необходимые данные уже лежат в кеше.
Цитата: grgdvo
2А выводы таковы, что не стоит заморачиваться наличием большого объема buffer или cache памяти.
я так и хотел сначала ответить :) но потом подумал, что будет выглядеть как отмазка. и решил, что лучше будет, если вы сами дойдете до такого вывода ;)
в общем и целом - верный вывод.