У меня есть веб-сервер с 8 ГБ оперативной памяти и довольно интенсивный php-сайт (1 сайт), который выполняет манипуляции с файлами, построение графиков, отправку электронной почты, форумы, вы называете это. Среда далеко не статична, что наводит меня на мысль, что очень мало можно получить от кеширования чего-либо в оперативной памяти, поскольку почти каждый запрос к серверу создает новые или обновленные страницы. И много кеширования выполняется на стороне клиента, поэтому у нас есть тонна 304 запросов, когда дело доходит до изображений, javascript, css.
Кроме того, у меня есть языковые файлы, которые записываются в плоские файлы на сервере, где кэшированная оперативная память определенно лучше, чем чтение с диска. Но таких файлов очень мало.
Примерно за две недели я перешел от 98% свободного плунжера к 4% свободного плунжера. Это произошло в то время, когда мы также отправляли на сервер несколько больших обновлений svn.
Мой вопрос в том, будет ли мой сервер лучше настроен, если я буду периодически очищать свой кеш (я знаю, что Линус Торвальдс относился к кешу), используя следующую команду:
sync; echo 3 > /proc/sys/vm/drop_caches
Или мне лучше отредактировать следующий файл:
/proc/sys/vm/swappiness
Если я заменю значение по умолчанию 60 на 30, у меня будет гораздо меньше подкачки и гораздо больше повторного использования устаревшего кеша.
Конечно, приятно видеть, что весь этот кеш освобождается с помощью первой команды, но я бы солгал вам, если бы сказал, что это хорошо для среды рабочего стола. Но как насчет веб-сервера, подобного описанному выше? Мысли?
РЕДАКТИРОВАТЬ: Я знаю, что система будет получать память по мере необходимости из кеш-памяти, но спасибо, что указали на это для ясности. Могу ли я представить себе ситуацию, когда Apache замедляется, когда большая часть памяти сервера хранится в кеше? Это совсем другая проблема?
Очистка кешей снизит производительность, но не поможет. Если бы ОЗУ требовалось для чего-то еще, она использовалась бы чем-то еще, поэтому все, что вы делаете, - это уменьшаете соотношение попаданий / промахов в кеш на некоторое время после выполнения очистки.
Если данные в кеше сильно устарели (т.е. они кешируются во время необычной операции), они будут заменены на «более новые» данные по мере необходимости без их искусственной очистки.
Единственная причина для бега sync; echo 3 > /proc/sys/vm/drop_caches обычно это происходит, если вы собираетесь попробовать выполнить некоторые тесты производительности ввода-вывода и хотите, чтобы известное состояние запускалось (запуск сброса кеша между запусками, чтобы уменьшить различия в результатах из-за того, что кеш загружается по-разному при каждом запуске).
Ядро иногда меняет местами несколько страниц, даже если есть много оперативной памяти, которую оно может запросить обратно из кеша / буферов, и настройка параметра swappiness может остановить это, если вы обнаружите, что это проблема для вашего сервера. Вы можете увидеть небольшую выгоду от этого, но, вероятно, увидите временную производительность. падение путем искусственной очистки кеша + буфера.