Назад | Перейти на главную страницу

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

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

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

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

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

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

Во всяком случае, перезагрузка серверов снизит производительность (и, конечно, время безотказной работы) в большей степени. идеальная среда. Одна из основ производительности в вычислениях - это использование преимуществ кеширование (данные доступны в быстрой памяти). Каждый раз, когда вы перезагружаетесь, вы сдуваете кеш. Это верно как для 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-сервер на выделенной машине - это значительно повысит производительность и значительно упростит работу.

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

Я думаю, вам стоит, помимо перезагрузки, изучить журналы событий и запустить журнал долгосрочного счетчика производительности, который вы можете проанализировать с помощью Анализ производительности журналов (PAL), чтобы увидеть, "видит ли" что-нибудь не так. Вам следует хотя бы попытаться сопоставить события, связанные с остановкой агента 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% в течение нескольких месяцев, то, возможно, нет необходимости перезагружать - это совершенно нормально для серверного приложения использовать всю доступную память - это значительно повышает производительность, потому что вам нужно меньше дисковых операций ввода-вывода, если вы используете ОЗУ для кэширования ваших данных.