Чи буде перезавантаження сервера за розкладом хорошою ідеєю для продуктивності?

Мені цікаво, чи було б перезавантаження сервера в розкладі гарною ідеєю для продуктивності.

Скажімо, ми хочемо перезавантажити сервер о 02:00 за 2 ночі.

Сервер тут є Windows Server 2008 R2. В основному на цьому сервері працюють SQL Server та IIS 7.5 (майже 15 додатків, що працюють). Сервер має 4 Гб пам'яті.

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

Думаю, вам добре, окрім перезавантаження, вивчити журнали подій та запустити довготривалий журнал лічильника ефективності, який ви можете проаналізувати за допомогою Аналіз ефективності журналів (PAL), щоб побачити, чи не бачить він "щось не так". Вам слід спробувати, якщо нічого іншого, співвіднести події, пов'язані із зупинкою агента SQL, з іншими факторами.

Якщо ви хочете перезавантажити комп'ютер для підвищення продуктивності, це, ймовірно, означає, що з часом ви стикаєтеся з проблемами управління пам’яттю.

Тренування - це добре

Якщо що-небудь, перезавантаження серверів зашкодить продуктивності (і тривалості роботи, звичайно) в більш ідеальному середовищі . Однією з основ продуктивності в обчислювальних технологіях є використання кешування (наявність даних у швидкій пам'яті). Кожен раз, коли ви перезавантажуєтесь, ви видуваєте кеш. Це стосується як SQL-сервера, так і IIS. Хоча, можливо, у вас немає ідеального середовища, наступне має допомогти вам направити кращий варіант, ніж перезавантаження сервера за графіком.

IIS Витоки пам'яті?

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

Пам'ять SQL

Повертаючись до кешування, SQL візьме об'єм пам'яті. Ви можете обмежити це у властивостях для SQL-сервера. Якщо ви не обмежуєте пам’ять, а у вікні також працює IIS, вони можуть почати боротьбу за продуктивність вбивства пам'яті. Ця чудова стаття детально описується у цій справі: Посібник Sysadmin по пам'яті Microsoft SQL .

Баланс

Оскільки у вас є і IIS, і SQL в одному вікні, вам доведеться збалансувати їх використання в пам'яті. Якщо ви цього не зробите, ви можете отримати пам'ять, яку, можливо, знову використовуватимуть на диску, - це жахливо місце (там повинні бути лічильники парфмонів для роботи в обміні). Використовуючи параметри IIS Recycle та обмеження пам'яті SQL, ви зможете зробити цю систему стабільною. Для балансування цього вам може знадобитися більше пам'яті, ніж 4 Гб. Крім того, якщо це варіант, я настійно рекомендую розмістити SQL-сервер на спеціальній машині - це дозволить зробити продуктивність набагато кращими та значно спростити речі.

Я не є прихильником перезавантаження серверів за розкладом, особливо не як засіб вирішення якоїсь основної проблеми. Якщо вам потрібно перезавантажити цей сервер, щоб вирішити проблему з продуктивністю, то кращий спосіб дії - це знайти причину проблеми та вирішити її. Перезавантаження сервера за звичайним розкладом лише придушує основну проблему.

Якщо у вас є значні витоки пам’яті, тоді впевнено, чому б ні - інакше перезавантажте щомісяця оновлення.

Якщо ви дійсно хочете перезавантажити сервер за розкладом (через вищезазначені витоки або оновлення пам'яті або будь-яку іншу причину) - чому б не подивитися на рішення кластера? Паралельно підключіть інший сервер, підключіть їх до балансира завантаження (навіть простий), і ви можете перезавантажити їх скільки завгодно, не втрачаючи час роботи або не переживаючи, що сервер взагалі не завантажиться і ви вийдете.

Це не жахлива ідея, але якщо це просто "вуду", це, мабуть, не дуже допоможе вам.

Однак є дві причини, щоб не допустити, щоб це було завершенням вашого розслідування щодо підвищення ефективності.

Один - майбутня масштабованість. Якщо ваші відключення є результатом завантаження, певної кількості запитів, певного запиту, який потрапляє на кешування, компіляції запитів або помилки індексації btree, або інших проблем, які наразі повторюються щодня, вони, ймовірно, трапляться частіше як завантаження з часом збільшується. Ніп, що в бутоні.

Інша проблема полягає в тому, що я підозрюю, що вам потрібно буде зупинити вхідні запити від залежних служб під час перезавантаження. Ви щойно створили оперативну каденцію. Кожен раз, коли потрібно виконати щоденне завдання, воно перетвориться на ваш перезапуск. У якийсь момент у вас з’являться ці масові перезавантаження, які триватимуть шість годин (я тут не перебільшую, я бачив, що це відбувається в більш ніж одній компанії), і ніхто не згадає, чому все потрібно зупинити і перезапустити в середині ночі.

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

Якщо у вас погано написаний код і витоки пам'яті, то перезавантаження може бути єдиним способом повернути виділену пам'ять назад в пул. Якщо у вас є процеси, пов'язані з пам'яттю, то це оновлення пулу до чистого стану, безумовно, може покращити продуктивність .... на деякий час. Але це справді поганий спосіб вирішити проблеми з продуктивністю, справжню причину слід прибити і усунути.

В іншому випадку нехай він працює, поки не знадобиться вікно технічного обслуговування для застосування патчів / програм / відновлення даних. Це може бути вдалий час, щоб запропонувати інженеру продуктивності подивитися на розглядаються сервери, щоб саме / які проблеми це викликають переконливість.

Хоча сама по собі не є повною відповіддю , але чи є можливим варіант додати ще трохи оперативної пам’яті на сервер? 4 Гб - низька сторона для машини IIS / SQL Server. Залежно від того, що це дійсно виділений серверний блок або робочий стіл, натиснутий на сервіс, ви можете отримати його 8 Гб або більше за досить низьку вартість. Зрозуміло, якщо це сервер, це може коштувати трохи дорожче, ніж стандартна настільна оперативна пам’ять, але це дасть вам трохи більше часу між примусовими перезавантаженнями.

Повідомляючи це, подивіться, чи можете ви обмежити SQL Server використовувати максимум 80% оперативної пам’яті, або погляньте на журнали, щоб уточнити, що саме відбувається і / або чому служба припиняється.

Незалежно від проблеми SQL, з якою ви можете мати справу, якщо у вас є сервери Windows і ви дотримуєтесь будь-якої процедури виправлення, ви будете регулярно перезавантажувати сервери без необхідності перезавантажувати "просто тому". Коли я працював у "ВЕЛИКОМУ МУЛЬТИНАЛЬНІ", ми отримали мандат на патч щомісяця, і як таке всі наші сервери перезавантажувалися щомісяця щонайменше один раз.

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

Я знаю велику компанію, яка не тільки перезавантажує свої сервери Windows вночі, але деякі з них навіть перевстановлюються кожні 24 години. Для них це необхідно через витоки пам'яті в питаннях програмного забезпечення та безпеки.

Здається, деякі компанії перезавантажують кожні 24 години - хоча мені як адміністратору Linux це здається дивним. Щоб зрозуміти: я б ніколи не рекомендував цього робити через проблему з пам'яттю - відстежуйте проблему та вирішуйте її.

Якщо використання вашої пам’яті залишається фіксованим на 75% протягом місяців, можливо, не потрібно перезавантажувати - це цілком нормально, щоб серверне додаток використовувало всю наявну пам’ять - це підвищує продуктивність, оскільки вам потрібно менше дискових операцій, якщо ви використовуєте ОЗУ для кешування ваших даних.