Будет ли перезагрузка сервера по расписанию хорошей идеей для производительности?

Мне интересно, если перезагрузка сервера по расписанию будет хорошей идеей для производительности.

Допустим, мы хотим перезагрузить сервер в 2 часа ночи за 2 ночи.

Сервер здесь есть Windows Server 2008 R2. В основном под этим сервером работают SQL Server и IIS 7.5 (работает около 15 приложений). Сервер имеет 4 ГБ памяти.

Хотя я бы согласился с тем, что нет ничего плохого в перезагрузке блока как такового, исходя из вашего комментария о том, что агент SQL Server останавливается, я бы посоветовал провести дополнительный анализ первопричин. Службы обычно не просто останавливаются, а службы агента SQL Server, по моему опыту, так не действуют.

Я думаю, что вы хорошо бы, кроме перезагрузки, проверить журналы событий и запустить долгосрочный журнал счетчиков производительности, который вы можете проанализировать с помощью Performance Analysis of Logs (PAL), чтобы убедиться, что он «видит» что-то неправильное. Вы должны попытаться, если не сказать больше, соотнести события, связанные с остановкой агента SQL, с другими факторами.

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

Кэширование это хорошо

Во всяком случае, перезагрузка серверов может снизить производительность (и, конечно, время безотказной работы) в более идеальной среде . Одной из основ производительности в вычислениях является использование преимуществ кэширования (наличие данных в быстрой памяти). Каждый раз при перезагрузке вы стираете кеш. Это верно как для SQL-сервера, так и для IIS. Хотя у вас может не быть идеальной среды, следующее может помочь вам выбрать лучший вариант, чем перезагрузка сервера по расписанию.

Утечки памяти IIS?

Теперь вы упомянули, что это IIS 7.5. Хотя я нахожу это удручающим, многие веб-приложения, работающие на IIS 7.5, имеют утечки памяти, поэтому по умолчанию в IIS перезапускает приложение каждые X минут и закрывает его, если пул приложения не используется. В идеале нужно исправить утечки памяти - но если вы не можете, вы можете отрегулировать эти настройки, которые включают ограничения памяти и таймеры. Вы можете использовать perfmon, чтобы выяснить, какой процесс w3wp использует память. Это немного болезненно, но вы можете привязать его к пулу приложений %systemroot%\system32\inetsrv\APPCMD list wps.

Память SQL

Возвращаясь к кешированию, SQL займет столько памяти, сколько сможет. Вы можете ограничить это в свойствах сервера SQL. Если вы не ограничиваете память, а также используете IIS на коробке, это может привести к снижению производительности памяти. Эта превосходная статья подробно расскажет об этом: Руководство системного администратора по памяти Microsoft SQL .

Баланс

Поскольку у вас есть и IIS, и SQL на одном и том же устройстве, вам придется сбалансировать использование их памяти. Если вы этого не сделаете, вы можете получить память, которая, вероятно, будет использоваться снова, выгружена на диск - это ужасное место (для своп-активности должны быть счетчики perfmon). Используя настройки IIS Recycle и ограничения памяти SQL, вы сможете сделать эту систему стабильной. Чтобы сбалансировать это, вам может понадобиться больше памяти, чем 4 ГБ. Кроме того, если это вариант, я бы настоятельно рекомендовал разместить SQL-сервер на выделенном компьютере - это значительно повысит производительность и значительно упростит процесс.

Я не сторонник перезагрузки серверов по расписанию, особенно не в качестве средства решения какой-то основной проблемы. Если вам необходимо перезагрузить этот сервер, чтобы решить проблему производительности, лучше найти причину проблемы и устранить ее. Перезагрузка сервера по регулярному расписанию только запутывает основную проблему.

Если у вас есть значительные утечки памяти, тогда, конечно, почему бы и нет - в противном случае ежемесячно перезагружайте обновления.

Если вы действительно хотите перезагрузить сервер по расписанию (из-за вышеупомянутых утечек памяти или обновлений или по любой другой причине) - почему бы не посмотреть на кластерное решение? Установите другой сервер параллельно, подключите их к балансировщику нагрузки (даже простому), и вы можете перезагрузить их сколько угодно, не теряя времени безотказной работы и не беспокоясь о том, что сервер вообще не загрузится и тебя не будет

Это не ужасная идея, но если это просто «вуду», это, вероятно, не очень вам поможет.

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

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

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

Моя рекомендация - следить за процессом SQL и перезагружать его по мере необходимости. Как упоминалось в предыдущем постере, в SQL нет утечек памяти, о которых думают люди (и я говорю это как человек, который был в команде MSSQL в середине 90-х). Вы хотите, чтобы ваш сервер базы данных использовал почти 100% памяти и процессора. Все, что меньше, тратит ресурсы.

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

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

Хотя это и не полный ответ сам по себе , но является ли приемлемым вариантом добавить больше оперативной памяти на сервер? 4 ГБ - это небольшая часть для компьютера с IIS / SQL Server. В зависимости от того, действительно ли это выделенный сервер или настольный компьютер, введенный в эксплуатацию, вы можете получить его 8 ГБ или более за довольно низкую стоимость. Конечно, если это сервер, он может стоить немного больше, чем стандартная настольная память, но это даст вам немного больше времени между принудительными перезагрузками.

Сказав это, посмотрите, можете ли вы ограничить использование SQL Server максимум 80% ОЗУ или посмотрите журналы, чтобы точно определить, что происходит неправильно и / или почему служба останавливается.

Вне зависимости от проблемы SQL, с которой вы, возможно, сталкиваетесь, если у вас есть серверы Windows, и вы следуете какой-либо процедуре исправления, вы будете регулярно перезагружать серверы без перезагрузки «просто потому, что». Когда я работал в «BIG MULTINATIONAL», нам приходилось обновлять ежемесячно, поэтому все наши серверы ежемесячно перезагружались, по крайней мере, один раз.

Я делаю это на 3 сервера, 1 наш и 2 клиента. Я настроил его по разным причинам - на одном сервере 2008R1 имеется множество обновлений, ожидающих установки, но я не могу установить их в пакетном режиме, поэтому я устанавливаю его по одному каждый день; другой сервер 2012R2 - для устранения неполадок при загрузке и некоторых проблем с производительностью и т. д. Я не думаю, что это плохая практика для планирования периодической перезагрузки, с другой стороны. Это может помочь отследить различные аппаратные и программные проблемы, особенно те, которые связаны с автоматическим запуском ,

Я знаю большую компанию, которая не только перезагружает свои серверы Windows по ночам, но некоторые из них даже переустанавливаются каждые 24 часа. Для них это необходимо из-за нехватки памяти в программном обеспечении и проблемах безопасности.

Кажется, что некоторые компании перезагружаются каждые 24 часа - хотя мне как администратору Linux это кажется странным. Чтобы было понятно: я бы никогда не рекомендовал делать это из-за проблемы с памятью - отследить проблему и решить ее.

Если ваше использование памяти остается фиксированным на уровне 75% в течение нескольких месяцев, то, возможно, нет необходимости перезагружаться - для серверного приложения вполне нормально использовать всю доступную память - это значительно повышает производительность, потому что вам нужно меньше дисковых операций ввода-вывода, если вы используете оперативная память для кэширования ваших данных.