Windows сервера для задач 24×7 — миф или мои «кривые руки»?

История последних дней. Есть у нас два SQL Server'а (2016 c SSD диском) и Express Edition (2012 с традиционным HDD). Аппаратно оба компьютеры примерно похожи (CPU/RAM/LAN). В целом 2016 «отдает» данные в 2-5 раз быстрее, за исключением некоторого набора таблиц, для которых 2012 работает быстрее в 1,5-2 раза. Такое поведение полностью противоречит какой бы то ни было логике. Любые манипуляции с настройками базы данных только ухудшают ситуацию. 2016 все более замедляется, но только для этого набора таблиц.

Для понимания парадоксальности ситуации — на обоих серверах развернута одна и та же база (с одного и того же файла backup'a). В этой базе порядка 600 таблиц. Те 5-6 которые ведут себя удивительно ничем не отличаются от десятков подобных (по структуре и количеству записей) с которыми такой проблемы нет. На обоих «серверах» — Windows 10 с последними обновлениями (это сервера разработок, а не продуктивные). На обоих SQL Server'ах последние сервис паки (без hot fix'ов). Никакие специальные «режимы» (trace flags и пр.) SQL Server'ов не включены.

Загадка сия была велика, но мой коллега ее решил. Вы даже знаете как…

Он перезагрузил компьютер с 2016 SQL сервером. После этого все «рецидивы» ушли. Как!? А точнее «Доколе!!!!!!!» хочется воскликнуть мне.

Чего мы только не делали. Каким «шаманствам» не предавались, чтобы объяснить это странное и абсолютно нелогичное поведение. Мы перестраивали индексы и изменяли типы данных (у нас в одной из этих «проблемных» таблиц был тип данных помеченных как «устаревший» в 2016, то, что он же применяется и в других «не проблемных» таблицах нас уже не останавливало), рассчитывали количество записей на странице и сравнивали размеры страниц SQL серверов, повышали версию совместимости базы данных и перестраивали статистику и прочее, прочее, прочее.

Очередная проблема с Windows, которая решилась как в том классическом анекдоте, «А вы не пробовали просто выйти и снова войти?».

Внимательный читатель (и поборник Microsoft) должен меня сразу уличить, что я де «передергиваю». Я использую для сервера базы данных не серверную операционную систему (Windows 10). Проблема понятна — это же desktop (!!!!!!!) операционная система, а вот в Windows server'ах, естественно, такой проблемы нет.

Спешу вас расстроить — я с завидной регулярностью наблюдаю подобные «выкрутасы судьбы» и на Windows серверах.

Кто виноват!?

Ну, Вы знаете — Windows Updater. Он там себе в фоне что-то устанавливает и все надеятся, что «прокатит». Я имею в виду, что если заменить без перезапуска часть исполняемых файлов операционной системы, некоторые настройки и т.д. (все то, что делает любое обновление ПО), то это может непредсказуемым образом сказаться на процессах, которые уже выполняются и которые невозможно незаметно перезапустить (как в моем случае с SQL Server'ом). Обновление исполняемых файлов и библиотек, которые уже загружены в память сервера, будет отложено, скорее всего, до перезагрузки компьютера, а вот все прочее — загадка. Как мне видится, фоновое обновление Windows всегда будет приводить к подобным «сюрпризам».

Проблема, в общем-то, стара как мир. Первый раз я с таким последствиями Windows Updater'a столкнулся в далеком 2007 году, кажется. С тех пор ничего, к сожалению, радикально не улучшилось. В оправдание Windows Updater'а скажу, что я как-то наблюдал как коллега на заре 2000-х установил в обеденный перерыв service pack на Windows Server и не смог перезагрузить сервер до конца рабочего дня. Интересные эффекты наблюдались :)

А могло ли быть иначе?

Возможно, если бы исполняемые файлы были «самодостаточными» — т.е. включали в том либо ином виде копии всех библиотек, которые они используют (за исключением самых низкоуровневых). Обновления операционной системы были не фоновыми… и мы возвращаемся в мир ранних версий Windows когда все(?) обновления «откладывались» до перезагрузки, пользователи не дожидались окончания установки обновлений и выключали компьютерыи в результате оказывались с незагружаемыми «операционками».

Т.е. скорее всего для серверных решений можно найти вариант решения — обновление всего по команде и с ведома «админа», а для «desktop'ов» мы наблюдаем «наименьшее из зол».

У меня Windows Update отключен!

Как говорится, «Если у вас паранойя — это не значит, что за Вами не следят». Я к тому, что чем дальше, тем сложнее и сложнее отключить Windows Updater. Даже в выключенном состоянии (я про «Панель Управления») Windows устанавливает «критические обновления» (в том числе на серверные операционные системы).

Я настоятельно рекомендую всем для серверных решений отключить авто-обновление Windows, но при этом выполнять его регулярно «в ручном режиме», как это делается в Unix подобных операционных системах. Я про пакетные менеджеры apt, yum или тот же brew для OSX. Если нечто подобное есть для Windows серверов и обновлений — расскажите мне об этом пожалуйста.
Хочу напомнить, что даже если у вас на windows сервере нет доступа в Интернет, то Windows Update может «утягивать» обновления по локальной сети (зараза такая).

Ха, это все проблемы Windows...

Не совсем. Критические обновления без вашего ведома на рабочие станции — «раскатывают» многие поставщики. Тот же Apple, если я ничего не путаю (речь не об уведомлениях для которых нужно что-то нажать в App Store'e, а о том, что без Вашего ведома было установлено). Ссылка ^[1].

Надеюсь, никто кроме Microsoft не устанавливает без ведома админа обновления на сервера.
В принципе, я наблюдал «свистопляски» еще и похлеще под Unix, когда «кривой» пакет принесенный apt-get'ом не остановил старый instance сервиса и заменил исполняемые файлы. О том, что дело в «косяке» обновления пакета и сервис до обновления нужно остановить я догадался после второго восстановления сервера из backup'а (благо это была «виртуалка» и делалось это в пару кликов).

Какие из всего этого мы можем сделать выводы?

Я бы не стал использовать серверные решения Microsoft без веских на то причин (я не об active domain или там file/print сервере), а про сервисы, которые должны работать 24x7. Скажу только, что за последний год я помню минимум три ситуации, когда проблемы с нашими системами решались перезапуском ОС (это все были windows server'ы разных версий с отключенными автообновлениями). Нет, у нас не «течет память». Нет, перезапуск наших серверов приложений не решал проблемы. А как вам ситуация когда операция сравнения дат перестает корректно работать для некоторых значений? Я, к сожалению, это наблюдал в этом году. Почему мы (иногда) используем на серверах приложений операционные системы Windows — это требование заказчика.

Доктор, я делаю так и у меня болит — не делайте так!

А как же тот самый SQL Server с которого начался этот монолог? Как с ним быть!? Ответ прост — SQL Server 2016 on Linux ^[2]. Мне, как и многим, наверное, пока страшно его запускать в «промышленную эксплуатацию», но если есть у кого-то подобный опыт с ним — поделитесь, пожалуйста.

Автор: FoxyBOA

Источник ^[3]