Был бы, перезагружая сервер в расписании быть хорошей идеей для производительности?
В то время как я согласился бы, что нет ничего неправильно с перезагрузкой поля, по сути, на основе Вашего комментария, что SQL Server Agent останавливается, я советовал бы некоторому дополнительному анализу первопричины. Сервисы обычно просто не останавливаются, и сервисы SQL Server Agent не действовали тот путь, по моему опыту, обычно.
я думаю, что Вы преуспели бы, кроме перезагрузки, чтобы исследовать журналы событий и выполнить долгосрочный журнал счетчика производительности, который можно проанализировать с Анализ Производительности Журналов (PAL), чтобы видеть, "видит" ли это что-то не так. Необходимо попробовать, если ничто иное, для корреляции событий, связанных с SQL Agent, останавливающимся с другими факторами.
Если Вы надеетесь перезагружать компьютер для улучшения производительности, это, вероятно, означает в конечном счете столкновение с проблемами управления памятью.
Кэширование Хорошо
В любом случае перезагружение серверов повредило бы производительность (и время работы, конечно) в больше идеальная среда . Один из основных принципов производительности в вычислениях должен использовать в своих интересах кэширование (наличие доступных данных в быстродействующей памяти). Каждый раз, когда Вы перезагружаете, Вы сдуваете свой кэш. Это верно и для SQL-сервера и для IIS. Хотя у Вас не могло бы быть идеальной среды, следующее должно помочь вести Вас к более оптимальному варианту, чем перезагрузка сервера в расписании.
Утечки памяти IIS?
Теперь Вы упомянули, что это - IIS 7.5. Хотя я нахожу это угнетением, столько веб-приложений, которые работают на IIS 7.5, имеет утечки памяти, что значения по умолчанию в IIS должны перезапускать APP каждые X минуты и завершать работу его, если Пул приложений неактивен. Идеал должен зафиксировать утечки памяти - но если Вы не можете, Вы могли бы корректироваться эти настройки , которые включают пределы памяти и таймеры. Можно использовать perfmon для выяснения, какой процесс w3wp использует память. Это - что-то вроде боли, но можно связать его назад пул приложений с %systemroot%\system32\inetsrv\APPCMD list wps.
Память SQL
Возвращение к кэшированию, SQL возьмет, какая память это может. Можно ограничить это в свойствах для SQL-сервера. Если Вы не ограничиваете память, и Вы также выполняете IIS на поле, они могут начать бороться за выполнение уничтожения памяти. Эта превосходная статья входит в это подробно: Руководство Системного администратора А по Microsoft SQL Memory .
Баланс
, Так как у Вас есть и IIS и SQL на том же поле, необходимо будет сбалансировать их использование памяти. Если Вы не делаете, Вы могли бы получить память, которая, вероятно, привыкнет снова выгруженная к диску - который является ужасным местом, чтобы быть (Должны быть счетчики perfmon для действия подкачки). При помощи настроек IIS Recycle и пределов Памяти SQL, необходимо смочь сделать эту систему стабильной. Для балансировки этого, Вам, возможно, понадобилось бы больше памяти, чем 4 ГБ. Кроме того, если бы это - опция, я настоятельно рекомендовал бы поместить SQL-сервер на выделенную машину - это собирается сделать производительность намного лучше и значительно упростить вещи.
Я не сторонник перезагрузки серверов в расписании, особенно не как средство решения некоторого базового вопроса. Если необходимо перезагрузить этот сервер для решения вопроса производительности затем, лучший план действий должен найти причину проблемы и разрешить его. Перезагрузка сервера на регулярной основе только запутывает базовую проблему.
Если Вы действительно хотите перезагрузить сервер в расписании (из-за вышеупомянутых утечек памяти или обновлений или какой-либо другой причины) - почему бы не посмотреть на кластерное решение? Поднимите другой сервер параллельно, сцепите их до подсистемы балансировки нагрузки (даже простой сделал бы), и можно перезагрузить их так, как Вы хотите, не теряя сервисное время работы или волнуясь, что сервер не загрузится вообще, и Вы будете отсутствовать.
Это не ужасающее идея, но если это - просто 'вуду', это, вероятно, не собирается помогать Вам очень.
Однако существует две причины не позволить этому быть концом Вашего расследования улучшения Вашей производительности.
Каждый - будущая масштабируемость. Если Ваши отключения электричества будут результатом загрузки, определенным числом запросов, конкретный запрос, который поражает кэширование, компиляцию запроса, или ошибку индексации B-дерева или другие проблемы, которые в настоящее время повторяются ежедневно, то они будут, вероятно, происходить более часто, поскольку загрузка увеличивается со временем. Пресеките это в корне.
другая проблема состоит в том, что я подозреваю, что необходимо будет остановить входящие запросы от зависимых сервисов во время перезапуска. Вы только что создали операционный тактовый сигнал. Каждый раз, когда некоторая ежедневная задача должна быть выполнена, она закончится связанная с Вашим перезапуском. В какой-то момент у Вас будут эти крупные перезапуски прокрутки, которые занимают шесть часов (я не преувеличиваю здесь, я видел, что он происходит больше чем в одной компании), и никто не будет помнить, почему все должно быть остановлено и перезапущено в середине ночи.
Моя рекомендация состояла бы в том, чтобы контролировать процесс SQL и перезапуск по мере необходимости. Как упомянуто более ранним плакатом, SQL не сделал, чтобы люди утечки памяти думали, что он делает (и я говорю это как человек, который был в команде MSSQL в середине 90-х). Вы хотите Ваш сервер базы данных использовать почти 100% памяти и ЦП. Что-либо меньше тратит впустую ресурсы.
Если Вы плохо написали код, и утечки памяти, затем перезагружающие, могут быть единственным способом возвратить выделенную память назад пулу. Если у Вас есть связанные процессы памяти затем, это обновление пула к чистому состоянию может, конечно, улучшить производительность.... некоторое время. Но это - действительно плохой способ обработать проблемы производительности, фактическая причина должна быть закреплена и зафиксирована.
Иначе, позвольте ему работать, пока Вам не будет нужно окно обслуживания для применения данных патчей/приложений/восстановления. Это могло бы быть хорошим временем, чтобы предложить, чтобы инженер производительности смотрел на рассматриваемые серверы для точно, почему/какой проблемы заставляют это.
В то время как не полный ответ по сути , но действительно ли это - жизнеспособный вариант добавить еще некоторую RAM к серверу? 4 ГБ находятся немного на низкой стороне для машины IIS/SQL Server. Завися, если это - единица на самом деле выделенного сервера или рабочий стол, принужденный к сервису, Вы смогли получать его 8 ГБ или больше для довольно низкой стоимости. Предоставленный, если бы это - сервер, это могло бы стоить немного больше, чем стандартная настольная RAM, но это дало бы Вам немного больше времени между принудительными перезагрузками.
Высказывание, что, посмотрите, можно ли ограничить SQL Server для использования максимума 80% RAM или взгляда на журналы к штрафу точно, что идет не так, как надо и/или почему сервис останавливается.
Im, делающий это на 3 серверах, 1, наш и 2 клиента. У меня есть setted это по различной причине - один сервер 2008R1 имеет много обновлений, ожидающих для установки, но я не могу обработать в пакетном режиме, устанавливают их, таким образом, я устанавливаю его один за другим каждый день; другой сервер 2012R2 - для поиска и устранения неисправностей начальной загрузки и некоторой производительности выходит и т.д. Я не думаю, что это - плохая практика для планирования периодической перезагрузки, от другого трудно Она может помочь отследить различные аппаратные и программные проблемы, особенно те, которые вовлечены в автоматический запуск.
Я знаю крупную компанию, которая не только перезагружает их серверы Windows ночью, но некоторые из них даже переустанавливаются каждые 24 часа. Для них, его необходимого из-за лука-порея памяти в программном обеспечении и проблемах безопасности.
Кажется, что некоторые компании перезагружают каждые 24 часа - хотя это кажется странным для меня как администратор Linux. Прояснить: Я никогда не рекомендовал бы сделать, это из-за проблемы памяти - разыскивает проблему и решает ее.
, Если Ваше использование памяти остается фиксированным в 75% в течение многих месяцев, то нет возможно никакой потребности перезагрузить - полностью нормально для серверного приложения использовать всю доступную память - это повышает производительность много, потому что Вам нужно меньше диска-IO's при использовании RAM для кэширования данных.
Не связанный с проблемой SQL можно иметь дело с тем, если Вы будете иметь серверы Windows и будете следовать за каким-либо видом исправления стандартной программы, то Вы будете перезагружать серверы регулярно, не имея необходимость перезагружать "просто потому что". Когда я работал на "КРУПНУЮ ТРАНСНАЦИОНАЛЬНУЮ КОРПОРАЦИЮ", мы получили мандат исправить ежемесячно и как таковой, все наши серверы были перезагружены ежемесячно, по крайней мере, однажды.