Comments 15
>На любом жёстком диске или SSD первые 63 сектора по 512 байт зарезервированы для размещения файлов, которые создаются в процессе установки операционной системы или при выполнении операций управления дисками, а также с помощью специальных программ — менеджеров разделов жёсткого диска
Вот эта информация совсем чуть-чуть устарела. Не на десять лет, меньше, но около того.
Собственно, тот контроллер, что на жестком диске, представляет собой достаточно давно «черный ящик», транслирующий видение контроллера, к которому он подключен, в физику. С нынешними секторами в 4К или эмуляцией сектора в 512 байт — это уже всё совсем не так.
С SSD всё еще хуже — они, по сути, упрощенный вариант RAID-контроллера с накопителями и кэшем в одном корпусе.
В итоге результат такого «выравнивания» будет зависеть отнюдь не от воли администратора сервера, а от логики, причем с более, чем одним уровнем абстракции: уровень ОС — уровень дискового контроллера — накопитель. И при смене прошивки контроллера или диска, либо обновлении ОС можно вместо ожидаемых получить результаты весьма неожиданные.
Вот эта информация совсем чуть-чуть устарела. Не на десять лет, меньше, но около того.
Собственно, тот контроллер, что на жестком диске, представляет собой достаточно давно «черный ящик», транслирующий видение контроллера, к которому он подключен, в физику. С нынешними секторами в 4К или эмуляцией сектора в 512 байт — это уже всё совсем не так.
С SSD всё еще хуже — они, по сути, упрощенный вариант RAID-контроллера с накопителями и кэшем в одном корпусе.
В итоге результат такого «выравнивания» будет зависеть отнюдь не от воли администратора сервера, а от логики, причем с более, чем одним уровнем абстракции: уровень ОС — уровень дискового контроллера — накопитель. И при смене прошивки контроллера или диска, либо обновлении ОС можно вместо ожидаемых получить результаты весьма неожиданные.
Выравнивание разделов остается одной из рекомендаций, которая справедлива для всех версий ОСЦ Windows и для всех версий SQL Server, включая SQL Server 2012 и SQL Server 2014. Исключений нет.
При работе с ОС Windows Server 2008 и более поздними версиями, в ходе управления дисками средствами графического интерфейса выравнивание разделов выполняется автоматически. Несмотря на это на практике регулярно встречаются ситуации, когда системные администраторы вручную управляют разделами жестких дисков, не задумываясь о необходимости соблюдать корреляцию между Partition Offset, File Allocation Unit Size, Stripe Unit Size (в случае последующей работы с SQL Server). Если корреляция нарушена, это оказывает существенное влияние на производительность в ходе выполнения операция чтения/записи. В связи с этим вендором настоятельно рекомендуется обязательно проводить проверку выравнивания разделов перед инсталляцией любой из версий SQL Server.
Более подробно вы можете прочитать об этом, например, в статье.
При работе с ОС Windows Server 2008 и более поздними версиями, в ходе управления дисками средствами графического интерфейса выравнивание разделов выполняется автоматически. Несмотря на это на практике регулярно встречаются ситуации, когда системные администраторы вручную управляют разделами жестких дисков, не задумываясь о необходимости соблюдать корреляцию между Partition Offset, File Allocation Unit Size, Stripe Unit Size (в случае последующей работы с SQL Server). Если корреляция нарушена, это оказывает существенное влияние на производительность в ходе выполнения операция чтения/записи. В связи с этим вендором настоятельно рекомендуется обязательно проводить проверку выравнивания разделов перед инсталляцией любой из версий SQL Server.
Более подробно вы можете прочитать об этом, например, в статье.
Методы восстановления SQL все-таки "простой" и "полный" (Simple and Full).
Отключение TCP Chimney нужно отлаживать. Для SharePoint вряд ли повлияет с точки зрения нормальной работы, но некоторое ПО, обычно связанное с шифрованием, плохо работает при включенном checksum offload. К сожалению, забыл, какое именно, но в его рекомендациях было отключать tcp chimney даже на гипервизорах. Наверно, это всё-таки не касается шарепойнта, но настройка иногда позволяет убрать малозаметные грабли при настройке некоторых типов серверного ПО.
И можно поподробнее, зачем 64кб размер кластера для sql server? И нужно ли в случае виртуального диска хостовую ФС тоже форматировать под 64кб?
Если говорить о моделях восстановления баз данных SQL-сервера, то используем стандартные названия «простая», «полная» и «с неполным протоколированием».
На практике при работе с локализованными последними версиями SQL-сервер встречаются непривычные нам подмены названий параметров и опций, на счастье без искажений сути. Очень не люблю локализации, но с ними приходится работать. В статье использованы реальные названия параметров и значения одной из таких локализаций.
В случае SharePoint отладке работы с TCP/IP Chimney Offload следует уделить внимание при работе веб-приложений по SSL и активном обращении пользователей к файлам больших размеров (видео, аудио).
Размер кластера в 64Кб коррелируется с размером экстента, — одной из основных единиц организации хранения данных SQL-сервером. Более подробно о страницах и экстентах можно прочитать здесь.
Вендор не выдвигает прямого требования о соответствии между размерами кластеров на хостовой машине и виртуальной. Если есть возможность, то выполняют тестирование обоих вариантов, после чего выбирают с наиболее высокими показателями производительности.
На практике при работе с локализованными последними версиями SQL-сервер встречаются непривычные нам подмены названий параметров и опций, на счастье без искажений сути. Очень не люблю локализации, но с ними приходится работать. В статье использованы реальные названия параметров и значения одной из таких локализаций.
В случае SharePoint отладке работы с TCP/IP Chimney Offload следует уделить внимание при работе веб-приложений по SSL и активном обращении пользователей к файлам больших размеров (видео, аудио).
Размер кластера в 64Кб коррелируется с размером экстента, — одной из основных единиц организации хранения данных SQL-сервером. Более подробно о страницах и экстентах можно прочитать здесь.
Вендор не выдвигает прямого требования о соответствии между размерами кластеров на хостовой машине и виртуальной. Если есть возможность, то выполняют тестирование обоих вариантов, после чего выбирают с наиболее высокими показателями производительности.
Вот кстати да… Допустим, у меня все SQL-сервера стоят на RAID-контроллерах, минимум P420i. Там stripe по-умолчанию составляет 512к, что хорошо бьётся с современными дисками. А еще — чудесная рекомендация о шести дисках — точно ли 4 Гб кеша RAID-контроллера и 8 шпинделей в массиве (RAID 1+0) будут работать медленней, чем 2+2+2+2 в RAID 1 (по-другому я шпиндели без отказоустойчивости не размажу)? А если у меня, допустим, 128 Гб ОЗУ для небольшой БД? Как оно лучше будет работать после прогрева кеша — с раздельными дисками либо с массивом?
Нужно ли для самого SQL-сервера выставлять настройку про OLTP-транзакции (оптимизацию для ad-hoc запросов), или это бессмысленно?
Откройте нам тайну про использование maximum degree of parallelism, которую так любят выставлять в «1» при недостаточности процессорных ядер многие разработчики приложений… И да, использование термина «полный доступ» применительно к модели восстановления БД сильно режет глаз.
Пока статья вопросов ставит больше чем ответов.
При этом, настоящее спасибо за объяснение настроек сетевой карты понятным языком. Потому что в интернетах встречаются рекомендации «тыкните это» без объяснения причин, а это неправильно.
Нужно ли для самого SQL-сервера выставлять настройку про OLTP-транзакции (оптимизацию для ad-hoc запросов), или это бессмысленно?
Откройте нам тайну про использование maximum degree of parallelism, которую так любят выставлять в «1» при недостаточности процессорных ядер многие разработчики приложений… И да, использование термина «полный доступ» применительно к модели восстановления БД сильно режет глаз.
Пока статья вопросов ставит больше чем ответов.
При этом, настоящее спасибо за объяснение настроек сетевой карты понятным языком. Потому что в интернетах встречаются рекомендации «тыкните это» без объяснения причин, а это неправильно.
В первой части статьи, посвященной тюнингу SQL Server под SharePoint даются рекомендации относительно действий и настроек, которые выполняются еще до начала инсталляции SQL, и, тем более, SharePoint. Описание особенностей настройки параметров в ходе инсталляции SQL Server, а также параметрами и настройками непосредственно до инсталляции SharePoint и после нее будут описаны во второй части, выход которой ожидается 10.04.2017. Во второй части речь пойдет и о maximum degree of parallelism, и о коэффициенте заполнения индекса, и о многих других настройках.
Ранжирование дисков по скоростям выполняется на основе проведения тестов, в этом отношении каждую конкретную среду можно считать уникальной. Рекомендация по распределению файлов данных и файлов журналов транзакций для баз данных SharePoint учитывает особенности выполнения операций чтения/записи в файлы данных, в файлы журналов транзакций, а также типовые различия в интенсивности этих операций в отношении разных служб и компонентов SharePoint. Обязательным является предварительный анализ характера работ на портале.
Ранжирование дисков по скоростям выполняется на основе проведения тестов, в этом отношении каждую конкретную среду можно считать уникальной. Рекомендация по распределению файлов данных и файлов журналов транзакций для баз данных SharePoint учитывает особенности выполнения операций чтения/записи в файлы данных, в файлы журналов транзакций, а также типовые различия в интенсивности этих операций в отношении разных служб и компонентов SharePoint. Обязательным является предварительный анализ характера работ на портале.
OLTP-транзакции и оптимизация для ad-hoc запросов — это разные вещи, не путайте их, пожалуйста.
OLTP — это большое количество транзакций, в т.ч. на запись.
Ad-Hoc запросы — это запросы, «новые» для сервера, т.е. не имеющие плана выполнения.
Т.е. база может быть OLTP, но совершенно не иметь ad-hoc запросов, если вся логика заложена в хранимые процедуры и работа идет через них. ad-hoc — это когда запросы генерируются на лету, тут же выполняются и забываются.
Соответственно, опция дает понять SQL Server'у, что не нужно хранить полный план для каждого запроса, тем самым снижается нагрузка на память для кэша планов.
max degree of parallelism — действительно рекомендуется выставлять в 1. Логика тут примерно такая — у вас все равно очень много запросов, поэтому все процессорные ядра будут загружены примерно поровну, а параллелизм дает доп. нагрузку на процессор, которую можно снизить, отключив параллелизм. Каждый конкретный запрос, возможно, будет выполняться чуть дольше без параллелизма, но в среднем производительность системы будет выше.
Для примера, у нас база используется также и для некоторой OLAP-нагрузки, периодически выполняются отчеты по базе, поэтому мы не выставляем этот параметр в 1, но мы сильно задираем вверх значение параметра «cost threshold for parallelism», чтобы в параллелизм уходили только очень тяжелые запросы, которым параллелизм сильно сократит время выполнения.
max degree of parallelism при этом нельзя ставить равным количеству ядер, т.к.в этом случае долгий запрос «подвесит» сервер, не даст другим запросам выполняться, пока он сам не будет выполнен (это очень грубое описание, но смысл, думаю, понятен), поэтому мы выставляем его обычно равным половине ядер на сервере.
OLTP — это большое количество транзакций, в т.ч. на запись.
Ad-Hoc запросы — это запросы, «новые» для сервера, т.е. не имеющие плана выполнения.
Т.е. база может быть OLTP, но совершенно не иметь ad-hoc запросов, если вся логика заложена в хранимые процедуры и работа идет через них. ad-hoc — это когда запросы генерируются на лету, тут же выполняются и забываются.
Соответственно, опция дает понять SQL Server'у, что не нужно хранить полный план для каждого запроса, тем самым снижается нагрузка на память для кэша планов.
max degree of parallelism — действительно рекомендуется выставлять в 1. Логика тут примерно такая — у вас все равно очень много запросов, поэтому все процессорные ядра будут загружены примерно поровну, а параллелизм дает доп. нагрузку на процессор, которую можно снизить, отключив параллелизм. Каждый конкретный запрос, возможно, будет выполняться чуть дольше без параллелизма, но в среднем производительность системы будет выше.
Для примера, у нас база используется также и для некоторой OLAP-нагрузки, периодически выполняются отчеты по базе, поэтому мы не выставляем этот параметр в 1, но мы сильно задираем вверх значение параметра «cost threshold for parallelism», чтобы в параллелизм уходили только очень тяжелые запросы, которым параллелизм сильно сократит время выполнения.
max degree of parallelism при этом нельзя ставить равным количеству ядер, т.к.в этом случае долгий запрос «подвесит» сервер, не даст другим запросам выполняться, пока он сам не будет выполнен (это очень грубое описание, но смысл, думаю, понятен), поэтому мы выставляем его обычно равным половине ядер на сервере.
Про OLTP и ad-hoc — извините, был неправ. Вы меня поправили совершенно справедливо.
А вот про max degree… Понимаете, в теории я с вами согласен. На практике ни один наш синтетический тест (не говоря о реальной работе) не показал преимущества ручной настройки max degree либо cost treshold for parallelism — длительность выполнения запросов только увеличивалась, по сравнению с настройками по-умолчанию, а занять все ядра (у нас ad-hoc не приветствуется, и для всего критичного индексы есть) у нас не получилось. Потому спасибо за вашу информацию, попробуем синтетику с указанными вами настройками.
А вот про max degree… Понимаете, в теории я с вами согласен. На практике ни один наш синтетический тест (не говоря о реальной работе) не показал преимущества ручной настройки max degree либо cost treshold for parallelism — длительность выполнения запросов только увеличивалась, по сравнению с настройками по-умолчанию, а занять все ядра (у нас ad-hoc не приветствуется, и для всего критичного индексы есть) у нас не получилось. Потому спасибо за вашу информацию, попробуем синтетику с указанными вами настройками.
Посмотрите переведенную мной статью про ожидания. Конкретнее — про CXPACKET. Когда это ожидание становится проблемой — тогда имеет смысл думать про настройку этих параметров. Пока оно не проблема — можно не трогать эти параметры, с достаточной долей вероятности они приведут к замедлению, а не к ускорению.
Все таки параллелизм — это благо, оно, как правило, приводит к ускорению запросов. Замедление происходит, только когда загрузка сервера приближается к максимуму — тогда лишняя работа по организации параллелизма может приводить к негативным последствиям.
Все таки параллелизм — это благо, оно, как правило, приводит к ускорению запросов. Замедление происходит, только когда загрузка сервера приближается к максимуму — тогда лишняя работа по организации параллелизма может приводить к негативным последствиям.
Будем благодарны за обратную связь по результатам ваших тестирований.
SharePoint изначально ориентирована на обработку большого кол-ва конкурирующих запросов, в связи с чем для параметра max degree of parallelism вендор рекомендует установить значение 1. Более того, если будет установлено иное значение, то будут блокироваться операции создания баз данных SharePoint. Подробнее можно прочитать здесь.
В идеале на SQL-сервере рекомендуется иметь шесть дисков для размещения следующих файлов:
Я не занимался настройкой MS SQL Server для Sharepoint, но, учитывая количество баз, указанных в пункте выше, разве не логично будет вынести разные базы на разные диски? По крайней мере, высоконагруженные для разных типов использования базы вынести на отдельные диски? Это раз уж мы заговорили об «идеале».
Расстановка приоритетов при выборе дисков
Мне кажется, полезнее было бы увидеть приоритеты в зависимости от скорости чтения и скорости записи. Для разных файлов в приоритете разные виды ввода-вывода. Например, для файла данных основной базы важнее скорость случайного чтения, а для файла журнала транзакций — скорость последовательной записи. Ну и т.д.
Один из наиболее часто встречающихся на практике подходов – выделение трех дисков (1- под ОС, второй – под файлы данных, 3 – под журналы). Этот вариант предлагается обычно администраторами баз данных, не знакомыми с SharePoint. Те, кто понимает специфику работы на портале и возникающую нагрузку по обработке данных, еще учитывает другую информацию. Примеров можно привести массу, рассмотрю лишь два:
Кейс 1. В случае развертывания портала в базовой конфигурации и небольших пропорциональных нагрузках по чтению/записи контента, работе с файлами небольших размеров и обеспечении стандартных возможностей поиска разбиения между двумя дисками файлов данных и журналов вполне хватает. В случае же большого кол-ва файлов (к примеру, 1 млн), повышения требований ко времени обхода контента, производительности поиска, — без переноса файлов данных и журналов службы поиска на другие диски уже не обойтись из-за явно наблюдаемых проблем производительности.
Кейс 2. Если на портале реализован функционал по массовой обработке элементов списков/библиотек, обработке XML и тп, то существенно повышаются требования к скорости чтения/записи для базы данных tempdb и базе контента.
Кейс 1. В случае развертывания портала в базовой конфигурации и небольших пропорциональных нагрузках по чтению/записи контента, работе с файлами небольших размеров и обеспечении стандартных возможностей поиска разбиения между двумя дисками файлов данных и журналов вполне хватает. В случае же большого кол-ва файлов (к примеру, 1 млн), повышения требований ко времени обхода контента, производительности поиска, — без переноса файлов данных и журналов службы поиска на другие диски уже не обойтись из-за явно наблюдаемых проблем производительности.
Кейс 2. Если на портале реализован функционал по массовой обработке элементов списков/библиотек, обработке XML и тп, то существенно повышаются требования к скорости чтения/записи для базы данных tempdb и базе контента.
Sign up to leave a comment.
Тюнинг SQL Server 2012 под SharePoint 2013/2016. Часть 1