Официальные документы Oracle говорят, что для машины с более чем 16 ГБ ОЗУ нам нужно выделить 16 ГБ подкачки.
Наши серверы RHEL 7 и 256 ГБ оперативной памяти.
Администраторы баз данных не хотят видеть системный своп, поэтому они хотят, чтобы мы очень агрессивно отслеживали 16 ГБ свопа.
Я предложил удвоить объем ОЗУ до 512 ГБ (расходы утверждены) и отключить подкачку. Однако это противоречит рекомендациям Oracle о наличии 16 ГБ подкачки, хотя мы удваиваем ОЗУ.
Честно говоря, я не понимаю, почему наличие 3% подкачки имеет какой-то смысл или почему, если я добавляю больше оперативной памяти, чем у нас было подкачки, мы должны сохранить подкачку.
Итак, есть ли какие-нибудь веские аргументы, которые я могу использовать, чтобы оправдать запуск Oracle без подкачки?
P.S. Единственная причина, по которой я упоминаю удвоение оперативной памяти, - это продемонстрировать нелепость аргумента, который я с трудом оспариваю. На самом деле я ищу аргументы, оправдывающие отключение свопа.
Отключение свопа - хорошая идея, если
Такое часто случается с базами данных. Я вижу это больше с базами данных noSQL, но реляционные базы данных могут столкнуться с той же проблемой.
В ОС нет ничего, что требовало бы подкачки. Linux справляется с этим довольно изящно, убивая последний процесс, запросивший память. Вы не хотите доходить до этого момента, поэтому убедитесь, что вы настроили Oracle на использование только ~ 90% памяти, чтобы было что-то еще для системных демонов и запас на ошибку. «Свободная» память также используется для буферизации дискового ввода-вывода, что является огромным выигрышем в производительности, поэтому попытка использовать больше памяти самой базой данных в конечном итоге снизит общую производительность системы, что приведет к обратным результатам.
Даже с системами, у которых есть часть памяти, из-за вопроса, является ли приложение базой данных, кешем или аналогичной системой, я бы по умолчанию не использовал свопинг на этом этапе.
Чтобы ты не полагался только на мой слово для этого:
Datastax объясняет Кассандре:
Вы должны полностью отключить свопинг. Несоблюдение этого правила может серьезно снизить производительность. Поскольку Cassandra имеет несколько реплик и прозрачное переключение при отказе, предпочтительно, чтобы реплика была немедленно уничтожена при нехватке памяти, а не переходила в режим подкачки. Это позволяет немедленно перенаправлять трафик на работающую реплику вместо того, чтобы продолжать попадать в реплику с высокой задержкой из-за подкачки. Если в вашей системе много DRAM, подкачка по-прежнему значительно снижает производительность, потому что ОС заменяет исполняемый код, чтобы больше DRAM было доступно для кэширования дисков.
Basho объясняет Риаку, что вам следует:
В идеале вам следует отключить свопинг, чтобы страницы процессов Riak не менялись местами. Отключение свопа приведет к сбою Riak в ситуациях, когда ему не хватает памяти. В результате останется файл аварийного дампа с именем
erl_crash.dump, в/var/log/riakкаталог, который можно использовать для определения причины использования памяти.
Percona сидит на заборе и дает полезные предостережения для обеих сторон вопроса. MariaDB не согласен с отключением свопа:
Хотя некоторые вообще отключают свопинг, и вы, конечно, хотите, чтобы его не использовали какие-либо процессы базы данных, было бы разумно оставить некоторое пространство подкачки, чтобы хотя бы позволить ядру изящно опрокинуться в случае всплеска. Наличие аварийной подкачки, по крайней мере, дает вам некоторую возможность убить любые побегающие процессы.
Хорошо полученный ответ здесь включает:
Я лично считаю, что система подкачки хуже, чем система, в которой произошел сбой. В случае сбоя системы резервный сервер резервного копирования перейдет на работу гораздо раньше. А в режиме «активный-активный» (или настройке с балансировкой нагрузки) неисправная система будет выведена из строя гораздо раньше. Снова выигрыш для системы без обмена.
Сегодня у этого ответа 22 голоса, и ему 4 года. Вы также можете увидеть некоторые другие ответы, восхваляющие ценность подкачки, но нет никаких указаний на то, что они используют базы данных. У них тоже не так много голосов. :)
Хотя они открыто не рекомендуют отключать swap, ребята из кальмаров сказать:
Squid, как правило, требует немного памяти. Он использует память для множества разных вещей, некоторые из которых легче контролировать, чем другие. Использование памяти важно, потому что, если размер процесса Squid превышает объем оперативной памяти вашей системы, некоторые фрагменты процесса необходимо временно переместить на диск. Обмен также может произойти, если в той же системе работают другие приложения, требующие большого объема памяти. Обмен приводит к очень быстрому снижению производительности Squid.
Это то, чего вы не хотите, чтобы случилось с вашей базой данных.
Пока Redis официально рекомендует поменять местами пользователи не покупай это:
Сначала отключите swap - Redis и swap нелегко смешиваются, и это, безусловно, может вызвать замедление.
Как видно на этот ответ получил наибольшее количество голосов в сообществе hortonworks:
Для подчиненный / рабочий / хосты данных которые имеют только распределенные службы, вы, вероятно, можете отключить подкачку. В распределенных сервисах предпочтительнее позволить процессу / хосту быть убитым, а не свопировать. Завершение работы этого процесса или хоста не должно повлиять на доступность кластера. Другими словами: вы хотите «быстро терпеть неудачу», а не «медленно деградировать».
[....]
Для мастера, своп также часто отключается, хотя это не установленное правило Hortonworks, и я предполагаю, что будут некоторые обсуждения / разногласия. С мастерами можно обращаться так же, как с мастерами в других средах, отличных от Hadoop.
Опасения, связанные с отключением подкачки на мастерах, заключаются в том, что событие OOM (нехватка памяти) может повлиять на доступность кластера. Но это все равно произойдет, даже если настроен своп, просто это займет немного больше времени. Хорошая практика администратора / оператора состоит в том, чтобы контролировать доступность ОЗУ, а затем исправлять любые проблемы до того, как память закончится. Таким образом обеспечивается доступность без снижения производительности. Тогда своп не нужен.
Мне это нравится, потому что речь идет о приложении Java, но он во многом делает те же выводы, о которых говорилось выше о базах данных. Также здесь упоминается мониторинг что очень полезно при настройке высокопроизводительных приложений. Если у вас нет цифр для сравнения, все основано на чувствах, которые труднее сравнивать. Составьте графики для всех измеримых показателей - задержки на уровне приложений и пропускной способности вплоть до ЦП, диска, памяти и сетевых графиков. Они предоставляют большую часть реальных данных, по которым вам нужно принимать решения.
Почему бы не сохранить разумный объем подкачки для неиспользуемых страниц и изменить давление кэша vfs, чтобы изменить подкачку только для случая OOM-состояния. Также вы можете закрепить процессы оракула в основной памяти, чтобы они никогда не касались диска. Это удовлетворяет требованиям базы данных, на которую не влияют медленные системы ввода-вывода, а также позволяет освобождать мусор из основной памяти, который будет использоваться базой данных, буферами и кешем. Это лучшее из обоих миров.
У Алекса из Linux есть интересное чтение на эту тему: "Своп против отсутствия свопа" http://www.alexonlinux.com/swap-vs-no-swap
Суть в том, что без свопа:
Эта тема возникает часто. Своп - это просто расширение ОЗУ, так что давайте купим больше ОЗУ, верно? Неправильно. Установка с 16 ГиБ подкачки и 512 ГиБ RAM делает идеальный экономический смысл. Позволь мне объяснить.
Если вы хорошо знаете основной софт, то знаете, сколько "тупой" памяти занимает достаточно точно. Какая "тупая" память? Различный код и данные, которые изначально отображаются в ОЗУ, но никогда больше не потребуются критически. То есть производительность, которую видит пользователь, никогда не пострадает, потому что этот материал недоступен в памяти.
Вместо того, чтобы исправлять программное обеспечение, вы можете просто дать ему эта сумма свопа, но не более эта сумма. Да пусть использует своп 100%. В этом-то и дело. Не увеличивайте своп, иначе вы рискуете, что некоторые важные вещи случайно окажутся там. Задокументируйте это, чтобы люди не волновались, увидев 100% использование свопа. В случае Oracle эта сумма составляет 16 ГиБ, и я могу сказать по своему опыту, что он будет использоваться даже в коробке 700 ГиБ, и вы не повлияет на производительность swpin.
Фактически вы получаете 16 ГиБ ОЗУ для реальной работы и приносите пользу своим пользователям. По состоянию на 2017 год это снижает затраты вашей организации примерно на 50 долларов. Если на вашем сервере 256 ГиБ ОЗУ, вы настраиваете подкачку и экономите 50 долларов. Если на вашем сервере 10 ТиБ ОЗУ, вы настраиваете своп и экономите ... 50 долларов. Видеть? Все тот же.
В настоящее время это всегда сейф иметь нулевой своп. Это просто стоит таких небольших 50 долларов, вот и все.
Если ваша организация не способна справиться со 100% использованным свопом (например, отдельная группа мониторинга и т. Д.), Не делайте этого. Если вы заставите кого-нибудь задуматься над этим вопросом, вы уже потратили 50 долларов его времени.
У некоторых поставщиков действительно нет потери памяти. А некоторые поставщики не чувствуют себя достаточно уверенно, чтобы оценить количество «глупых» распределений, поэтому они говорят «нулевой своп», чтобы избежать неизвестных проблем, просто чтобы сэкономить кучу ваших долларов. Тоже норм! Я бы просто доверился поставщику, они поддерживают установку, они знают свое дело.