Комментарии 11
Вот про vm.swappiness недавно была статья, что вообще говоря некорректно его убирать. Можно даже проиграть в производительности, а не выиграть.
"Где пруфы, Билли?"
Ок, допустим наличие файлового кэша в оперативе требует от ОС дополнительных действий по сбросу его части, чтобы выделить нужный объем для нового процесса. Да, процессы не сразу выделяют нужный для своей работы объем, а могут делать это динамически. Но где замеры того, о каких значениях вообще идёт речь? Может быть это считанные микросекунды, а приложение запускается секунд 5 - тогда пляски с увеличением объема гарантированно пустой оперативы вообще не стоят свеч.
Пример - СУБД Oracle. У нее есть два куча разных параметров для выделения оперативы, но рассмотрим два - нижняя граница (MEMORY_TARGET) показывает, сколько будет выделено оперативы сразу при старте, и верхняя (MEMORY_MAX_TARGET) показывает, до какого уровня ее возможно выделить. Постепенно после запуска СУБД пытается выделить себе память до верхней границы, если столько есть в системе, либо если её не хватает из-за запуска других приложений она может ее освободить, вернувшись к нижней границе. Эти значения СУБД использует для расчета размера всяких буферов и кэшей, без которых скорость выполнения запросов будет совсем печальной.
Допустим, у нас была виртуалка на 8ГБ, для Oracle в конфиге указаны значения в 4 и 6Гб соответственно. База растет (допустим, вместо 10Гб стало 100), все чаще приходится лезть за данными на диск, потому что всей оперативы на кэширование часто используемых данных не хватает.
Апгрейдим виртуалку, теперь там 32Гб оперативы. Но параметры оставляем те же. С одной стороны, у базы остались те же самые параметры для выделения оперативы, а значит и значения для размеров внутренних буферов и кэшей, с другой - у нас стало очень много оперативы, которую больше никто не занимает. Но скорость выполнения запросов возрастает в разы, за что спасибо файловому кэшу ОС - самые часто используемые блоки данных уже находятся в оперативе, что позволяет существенно увеличить производительность.
Теперь увеличиваем значения параметров до пропорциональных размеру оперативы - естественно база станет стартовать дольше из-за выделения кучи оперативы за раз, но после старта и прогрева кэша запросы выполняются все то же время, что и до изменения параметров.
Да, там все же будет разница на определенных запросах - некоторые промежуточные или итоговые результаты не влезали в старые буферы, и поэтому либо падали, либо выполнялись вечно (например, дамп базы не снимался), а теперь все станет значительно лучше. Но существенного влияния на производительность запросов в среднем здесь скорее всего не будет. По крайней мере, так было у меня, проводил такую процедуру не один десяток раз, и результат всегда был схожим. А вот с меньшим файловым кэшем базе стало бы ну совсем плохо.
Плюс сервисы перезапускаются не каждую секунду, и большую часть времени они работают с уже выделенным объемом оперативы. Даже если это какой-то процесс активно выполняет операции, которые требуют постоянного выделения и освобождения памяти, он обычно не особо спешит эту память возвращать ОС - он ее потом может и не получить, а она ему может очень скоро пригодиться.
Поэтому я крайне скептически отношусь к идее как-то ограничивать или сбрасывать файловый кэш - а с чего вообще вы решили, что будет положительный эффект хоть где-то? Есть какие-нибудь записи о реальных эффектах, которые этот способ принес? Звучит крайне сомнительно.
а с чего вообще вы решили, что будет положительный эффект хоть где-то?
Ну как же - весь положительный запланированный эффект получен.
Переводчик получил гонорар, маркетолог сделал план по публикациям, контора пропиарилась,
А вы почему то решили, что должен быть технический эффект. Но тогда вам не на этот сайт.
Может быть это считанные микросекунды, а приложение запускается секунд 5 — тогда пляски с увеличением объема гарантированно пустой оперативы вообще не стоят свеч.
Полагаю, речь про микро и наносекунды:
Aerospike
The real-time data platform
Act in real time across billions of transactions while reducing your server footprint by up to 80 percent.
Для десктопа и типичного сервера всё, что описано в статье — вредные советы. Но если речь идёт буквально об увеличении *производительности памяти*, то, *может быть*, советы из этой статьи можно попробовать применить.
Посмотрите оригинал: в нём говорится о:
Under some circumstances, this can affect the general performance of the system as cache de-allocation is time-consuming in comparison with access to unused RAM. Higher latency could therefore sometimes be observed.
This latency will purely be based on the fact that RAM is being used to its full speed potential.
The latency may also affect either Aerospike, or operating system components, such as network card/iptables/ebtables/iproute2 **mallocs**.
Так что, полагаю, речь про жесткий реалтайм, и люди действительно могут упираться в задержки оперативной памяти.
Оригинал — просто форумный пост, заметка.
Все вот эти статьи "сейчас мы в 8кб текста расскажем вам как сделать память линукса быстрее" пахнут невежеством. Если бы был универсальный рецепт, делающий память линукса быстрее, то он уже давно был бы в апстриме. В отдельных ситуациях отдельные аспекты поведения системы можно менять, но их нельзя оценить простым "стало быстрее". Что-то стало быстрее, что-то катастрофически медленее, или даже перестало работать.
(Например, как сделать на сервере много свободной памяти? Убить все процессы! Станет много свободной памяти. Часть функций при этом, правда, перестанет работать).
Вы дейсвительно чему-то людей учите, или все ваши курсы такого же уровня нелепости?
Тюнинг любой системы подразумевает:
сбор информации о текущем состоянии, какие ресурсы использованы, в каком объеме, как система ведет себя в динамике
внесение изменений в настройки
оценка изменений. получение новых значений контрольных показателей при разных уровнях нагрузки
принятие решения о сохранении или откате изменений
повтор пока система не достигнет целевых показателей или не придет понимание, что это невозможно/ненужно
То, что вы научились нагибать систему до нужных вам цифр - совсем не значит, что вы сделали ее лучше. Вам еще придется это доказать.
Настройка ядра Linux для повышения производительности памяти