Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Производительность SQL сервера ВОПРОС!  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
SERG1257
dezhnevo
Спасибо, авы пользовались этим набором скриптов?
Я похож на человека не отвечающего за базар? Конечно пользовался. Только этот скрипт sp_blitz НИЧЕГО НЕ ЧИНИТ. только указывает на самые распространенные ошибки в конфигурировании. Задает направление поисков.
Брент хорошо умеет продавать свои услуги. Дальше там написано, что если вы офигеете от количества "ошибок" который выдаст моя процедура, но читать книжки и разбираться во всем этом вам лень, то наймите меня, я за 3 дня и огромную сумму денег вам все исправлю.
11 дек 18, 01:22    [21759710]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
dezhnevo
Member

Откуда:
Сообщений: 47
Mind,

Ясно, что есть люди, специалисты, которые во всем разберутся и очень быстро. Но разобраться нужно мне, поэтому будем читать книжки.
11 дек 18, 09:42    [21759839]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Androgen1985
Member

Откуда:
Сообщений: 55
dezhnevo,
а может изначально то проблема не в SQL сервер, а в приложении которое тормозит? Пользователи не в management studio же работают. А приложение может тормозить не только от того, что SQL долго обрабатывает запросы
11 дек 18, 10:03    [21759865]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
dezhnevo
Member

Откуда:
Сообщений: 47
Androgen1985,

Абсолютно верное и логичное утверждение. И в этом направлении тоже смотрю. Есть такие подозрения
11 дек 18, 10:44    [21759929]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Ondayl
Member

Откуда:
Сообщений: 200
dezhnevo, как я вас понимаю. Несколько лет назад находился в ситуации 1 в 1. Я начинал с топа медленных запросов и счетчиков производительности Windows в части производительности дисковой подсистемы. Это легко сделать и хорошо задает направление "где дальше копать".
11 дек 18, 13:37    [21760240]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
dezhnevo
Member

Откуда:
Сообщений: 47
Ondayl,

:)
11 дек 18, 14:00    [21760294]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Ondayl
Member

Откуда:
Сообщений: 200
dezhnevo, у вас уже есть информация со счетчиков и топы запросов?
11 дек 18, 16:24    [21760548]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
SERG1257
Member

Откуда:
Сообщений: 2690
Mind
Брент хорошо умеет продавать свои услуги.
будто это что-то плохое
Mind
я за 3 дня и огромную сумму денег вам все исправлю.
просчитался американец, не заплатит ему dezhnevo ни копейки

По сабжу - я бы начал работать с пользователями которые жалуются, когда именно "тормозит", что именно "плохо работает".
Иначе это бродить в потемках.
11 дек 18, 16:41    [21760570]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
dezhnevo
Member

Откуда:
Сообщений: 47
Ondayl,

Информация собирается. Пока не все метрики учтены
11 дек 18, 17:10    [21760606]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7215
SERG1257
По сабжу - я бы начал работать с пользователями которые жалуются, когда именно "тормозит", что именно "плохо работает".
Иначе это бродить в потемках.
Тормозят юсеры, не отвечают на запросы сервера.
11 дек 18, 20:01    [21760733]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
SERG1257
По сабжу - я бы начал работать с пользователями которые жалуются, когда именно "тормозит", что именно "плохо работает".
Иначе это бродить в потемках.
+1. Мне как то сказали что сервер тормозит. Стали смотреть что юзер делает, а там приложение выгружает данные с сервера одним запросом за 30 секунд в локальный кэш, потом отключается и начинает что-то там лопатить, excel файлы формировать и т.д. и так на пол часа.
12 дек 18, 00:18    [21760927]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
DaniilSeryi
Member

Откуда:
Сообщений: 1668
Mind
SERG1257
По сабжу - я бы начал работать с пользователями которые жалуются, когда именно "тормозит", что именно "плохо работает".
Иначе это бродить в потемках.
+1. Мне как то сказали что сервер тормозит. Стали смотреть что юзер делает, а там приложение выгружает данные с сервера одним запросом за 30 секунд в локальный кэш, потом отключается и начинает что-то там лопатить, excel файлы формировать и т.д. и так на пол часа.


Но виноват, разумеется, SQL Server. :-)))
12 дек 18, 10:16    [21761114]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
dezhnevo
Member

Откуда:
Сообщений: 47
Mind,

в моем случае такого нет, ничего кроме sql на сервере не крутится
12 дек 18, 11:32    [21761200]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
uaggster
Member

Откуда:
Сообщений: 769
dezhnevo
Здравствуйте.
На новом месте работы поставили задачу разобраться с производительностью сервера SQL. Сказали, что пользователи жалуются, «тормозит, плохо работает». Я сам в БД не работаю, запросы не создаю и т.д., все со слов.
Исходные данные на момент написания:

Сервер:

Win server 2008R2 x64 – 125 Gb ОЗУ – Xeon E5 4640 x2
MS SQL 2012 (количество баз – 30, размер всего 900 Гб)

Информация по БД основная, без секундных метрик и данных о нагрузке в единицу времени:

Data Base Pages – 11 134 865
Buffer Cache Hit Ratio – 100 %
Target Pages – 261 914 624
Cache objects – 96 346
Cache pages – 885 283

Для мониторинга обстановки основные показатели интегрированы в сервер мониторинга и выводы следующие:
Дисковая подсистема и процессорный пул не сильно нагружаются. То есть тех ресурсов что есть вполне хватает. А вот с оперативной памятью вопрос. Для SQL выделено 100 Gb, он «съел» их полностью. Причем было выделено 80, добавили +20 за неделю он их «прикончил».
В связи с этим вопрос, какой оптимальный объем ОЗУ (ориентировочно) мне нужен в данной ситуации (я в курсе, что это очень грубо, без анализа количества запросов и других параметров работы пользователей с БД) и что посмотреть в первую очередь для некой оптимизации БД, без глобальных изменений.
Буду рад ответить на уточняющие вопросы. Спасибо большое заранее.

Давайте я напишу несколько очевидных вещей, которые гарантированно помогают (кроме шуток), увеличить производительность MSSQLSERVER. Правда, речь идет мере такого увеличения :-).
1. Разнесите базы, логи и tempdb по разным дискам. Заметьте, что крайне желательно, чтобы это были физически разные тома. Например, если у вас много дисков (10 :-), зеркало - под систему, и 8 болтаются на рэйд-контроллере), то лучшей конфигурацией будет зеркало пол логи, зеркало под темпдб, рэйд10 под данные.
2. Если у вас СХД - озаботьтесь приоритетами при работе с томами. Для логов критически важна задержка (латентность), для данных - общая пропускная способность.
3. ОБЯЗАТЕЛЬНО уберите tempdb с системного диска.
В качестве бюджетного "ускорителя быстродействия SQL" я бы посоветовал купить SSD для PCI-EX с большим ресурсом, и вынести tempdb на него. Тут правда есть момент, что в случае его отказа SQLSERVER аварийно остановится, но разрушения баз (теоретически) не произойдет, и вы сможете запуститься, после некоторых телодвижений (https://infostart.ru/public/236716/) в течение нескольких минут после перезагрузки.
Ну, разумеется, если у вас не система 24х7 и вы не банковскими транзакциями рулите.
4. Если у вас не энтерпрайз версия SQLSQRVER, то больше 64 (2012, 2014) или 128 (2016SP1+) отдавать ему бессмысленно. Оно не умеет.
5. Если у вас сильно больше памяти, например - 256, и активно используется tempdb при работе (посмотрите хотя бы системным монитором) - подумайте, может сделать на "лишней" памяти RAM-диск, и разместить там tempdb.
6. Ограничьте, с учетом вышеизложенного, память, доступную для SQLSERVER. Лучше оставить системе 10%, но не менее 4ГБ.
7. Обязательно установите Instant File Initialization https://www.brentozar.com/blitz/instant-file-initialization/
8. Если у вас система с 8 ядрами - сделайте 8 файлов tempdb, если их больше - то еще +4 файла на каждые 8 ядер, но не более, чем 16 файлов. Обязательно установите для файлов одинаковый начальный размер и одинаковое приращение. Где-то 128-512Мб.
9. Установите такое же приращение для всех файлов БД, которые вы используете. Причем для файлов данных 256-512, для логов 32-64Мб (логи заполняются нулями при приращении, поэтому большое приращение может внезапно подвесить какой нибудь запрос на обновление).
10. Убедитесь, что опция AUTO CLOSE для БД - ВЫКЛЮЧЕНА. За опцию AUTO SHRINK - вообще нужно расстреливать сразу и без суда.
11. Убедитесь, что опция автоапдейта статистики ВКЛЮЧЕНА.
12. Не смотря на п.11. создайте задачу обслуживания по пересчету статистики рабочей базы, и сделайте ее автозапуск в периоды минимальной загрузки.
13. На самой деле задача на ребилд/реорганизацию индексов НЕ НУЖНА (при любом разумном сценарии использования SQL) :-)
14. Убедитесь, что опция БД Page Verify стоит в CHECKSUM. Если это не так, немедленно установите эту опцию и запустите DBCC.
15. Убедитесь, что вы регулярно делаете полный бэкап БД, и бэкап лога БД, для всех баз с FULL моделью восстановления.
16. Имейте ввиду, что SIMPLE модель восстановления НЕ имеет преимуществ перед FULL по быстродействию :-)
17. Перенесите базу на SSD.
18. Если вы не можете этого сделать, а у вас 2014+ SQL - хотя бы включите BPE https://olontsev.ru/tag/buffer-pool-extension/
Но, имейте ввиду, что SSD для этого должен сидеть на 6G SATA как минимум.
19. За практику шринка БД - нужно, по хорошему, расстреливать. Делать это нужно только в том случае, если вы отчетливо осознаете, что и зачем хотите сделать, и какие последствия этого будут.
20. Уберите флаг системного индексирования для быстрого поиска на томах, где расположены базы.
21. Добавьте файлы с базами в исключения антивируса.
22. Отключите на томах с базами генерацию 8.3 имен и времени последнего доступа.
23. Можно довольно сильно увеличить быстродействие БД, правильно настроив индексы. Но для этого вы должны понимать, что и зачем вы делаете :-)

Прим:
:-) помечены теоретически спорные вопросы, которые, однако, в 90+% случаев работают именно так, как я сказал :-)
12 дек 18, 13:57    [21761525]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
dezhnevo
Member

Откуда:
Сообщений: 47
uaggster,

Во первых, спасибо, что не поленились ответить. Из множества статей и видео, которые сейчас обрабатываю, в большинстве случаев с вами соглашусь.
У меня вопрос по физике только один, я разбиваю tempdb на части, сейчас один и на системном медленном винте (это уже по любому узкое место), по количеству и размеру приращения все понятно, но! от чего отталкиваться определяя его первоначальный размер. Пока логика не ясна.
Например, сейчас один файл размером 30 Gb, делю его на 12, так как 8+4 в моем случае, процент роста ставлю 10% и без ограничения (хотя в рекомендациях говорится, что стоит ограничить рост по времени, хотя бы 2 минутами), внезапного аномального роста не наблюдается. Вопрос, какой изначальный размер каждого файла указывать, какая формула вычисляет это? Для меня пока не ясно.
Вопрос по ребилду и переиндексу, после переноса на ssd, думаю не актуален, и даже противопоказан.
Еще раз спасибо.
12 дек 18, 14:21    [21761567]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
uaggster
Например, если у вас много дисков (10 :-), зеркало - под систему, и 8 болтаются на рэйд-контроллере), то лучшей конфигурацией будет зеркало пол логи, зеркало под темпдб, рэйд10 под данные.

Таки нет. Это очень плохое решение. А вот наоборот - зеркало под БД и raid10 под tempdb, это уже кошерно.
И готов пояснить, почему.

Когда вылетит один диск из 4-х (а он обязательно вылетит) - то ребилд тома под tempdb это не страшно. Отключите пользователей, запустите с БД внеочередной бэкап. Плюс скорость на запись и чтение для tempdb почти всегда важнее, чем для большой БД.

А вот если вылетит диск под томом с БД и начнется ребилд - Вы будете в страхе ожидать, что при выполнении бэкапа из-за повышенной нагрузки вылетит второй диск в том же зеркале из страйпа - и потеряете много свежих данных.
12 дек 18, 14:27    [21761590]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
архивариус
Member

Откуда:
Сообщений: 149
dezhnevo
процент роста ставлю 10%
imho, прирост в процентах = возможный выстрел в ногу в будущем, общепринятое мнение достаточно давно, несмотря на настройки по умолчанию MS ?!
12 дек 18, 14:28    [21761591]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
uaggster
Member

Откуда:
Сообщений: 769
dezhnevo
uaggster,

Во первых, спасибо, что не поленились ответить. Из множества статей и видео, которые сейчас обрабатываю, в большинстве случаев с вами соглашусь.
У меня вопрос по физике только один, я разбиваю tempdb на части, сейчас один и на системном медленном винте (это уже по любому узкое место), по количеству и размеру приращения все понятно, но! от чего отталкиваться определяя его первоначальный размер. Пока логика не ясна.

Если перенесете tempdb на отдельный диск, то я советую вообще установить начальный размер файла = месту на диске / количество файлов (ну, за минусом места под лог ~1-2Гб, tempdb в общем случае большой лог не нужен), с приращением 0.
Однако, если не включите мгновенную инициализацию файлов - рискуете заполучить старт SQLSERVER в течение десятков минут :-)
dezhnevo
Например, сейчас один файл размером 30 Gb, делю его на 12, так как 8+4 в моем случае, процент роста ставлю 10% и без ограничения (хотя в рекомендациях говорится, что стоит ограничить рост по времени, хотя бы 2 минутами), внезапного аномального роста не наблюдается. Вопрос, какой изначальный размер каждого файла указывать, какая формула вычисляет это?

Процентный прирост файлов использовать КРАЙНЕ не рекомендуется.
Установите фиксированный прирост.
dezhnevo
Для меня пока не ясно.
Вопрос по ребилду и переиндексу, после переноса на ssd, думаю не актуален, и даже противопоказан.
Еще раз спасибо.

Смысл ребилда и реиндекса - не в этом.
Упрощенно, дело в следующем:
При интенсивных вставках и обновлениях данных, в кластерном и некластерных индексах могут образовываться "дырки". Страницы, и данные на страницах, которые помечены как удаленные.
SQL же читает данные с дисками кусками по 8кб, и отображает их в память тоже этими же кусками, целиком, без изменения.
И вот представьте, что он вытянул с диска страницу, отобразил ее в памяти, а из 8 кб там полезных только 2 кб, остальное - помечено как удаленное.
Во первых он 8 кб с диска тащил, из которых только 2 - полезных (нагрузка на диск), а во-вторых в памяти то он 8 кб так и так занял, не смотря на то, что там всего 2 кб полезных.
Вот это и нужно исправить реорганизацией или перестроением.
12 дек 18, 14:45    [21761635]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
uaggster
Member

Откуда:
Сообщений: 769
Andy_OLAP
uaggster
Например, если у вас много дисков (10 :-), зеркало - под систему, и 8 болтаются на рэйд-контроллере), то лучшей конфигурацией будет зеркало пол логи, зеркало под темпдб, рэйд10 под данные.

Таки нет. Это очень плохое решение. А вот наоборот - зеркало под БД и raid10 под tempdb, это уже кошерно.
И готов пояснить, почему.

Когда вылетит один диск из 4-х (а он обязательно вылетит) - то ребилд тома под tempdb это не страшно. Отключите пользователей, запустите с БД внеочередной бэкап. Плюс скорость на запись и чтение для tempdb почти всегда важнее, чем для большой БД.
[/quot]
А вот это зависит от интенсивности использование tempdb.
Если у вас, например, версионирование вГлючено, то может и да.
А вот, например, если у вас база гигабайт 500, а памяти всего 16 - то таки нет, и запросы, скажем так, нелокальны. Скорее всего, уже определяющим будет время подъема данных с диска.
Andy_OLAP
А вот если вылетит диск под томом с БД и начнется ребилд - Вы будете в страхе ожидать, что при выполнении бэкапа из-за повышенной нагрузки вылетит второй диск в том же зеркале из страйпа - и потеряете много свежих данных.

Почему? Логи то на другом диске.
Ну, забекаплю хвост лога. Или буду бэкапить его почаще.
12 дек 18, 15:02    [21761665]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
uaggster
А вот это зависит от интенсивности использование tempdb.
Если у вас, например, версионирование вГлючено, то может и да.
А вот, например, если у вас база гигабайт 500, а памяти всего 16 - то таки нет, и запросы, скажем так, нелокальны. Скорее всего, уже определяющим будет время подъема данных с диска.

Тут еще один нюанс. Допустим, у Вас 4 диска по X Тб, Вы их объединили в RAID-10, получили 2*X Тбайт. Один диск исчез, на замену ничего нет. Все плохо.

А теперь у Вас ситуация наоборот. 6 дисков по X, зеркало под БД, RAID-10 под tempdb. Вылетел диск из зеркала. Достали из сейфа запасной или воткнули hot-spare в зеркало - а ребилд не идет. Диск с бэдами. А думали, что кошерный. Что делать.
Развалить RAID-10, собрать том с той же буквой на зеркале, под tempdb, места будет в 2 раза меньше - не страшно. Один из полученных резервных дисков отдать под том с БД.

Аналогично вылетел диск из RAID-10 под tempdb - взяли 2 из 3 и собрали зеркало под tempdb. Просела скорость - не важно. Придет кошерный запасной диск - соберете обратно RAID-10.

Тут в соседней теме коллега плачет горькими слезами, что начальство купило скоростную полку под бэкапы боевых серверов - и отдало на другие задачи. А бэкапы снова заливаются на присоединенный внешний диск. Даже не на NAS с зеркалом.

В университетах и лабораториях можно экспериментировать с расположением данных на дисках. А в фирмах все решает бюджет, который всегда режут, которого всегда не хватает на самые важные вещи. И скорость запросов к БД не так важна, как сохранность данных и время простоя на боевом сервере.
12 дек 18, 15:22    [21761699]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Andy_OLAP,

Не помещается база под X, но влезет в 2*X Тбайт - это не повод класть ее на RAID-10. Это повод пойти к начальству и выбить бюджет на замену дисков - ВСЕХ дисков - на более емкие и скоростные ПЛЮС заранее продумать вопрос о том, что и размеры бэкапов такой базы тоже растут, и наверняка потребуется увеличивать диски на более емкие и на полке, где бэкапы лежат. Не нужно выкраивать 7 шапок из шкуры кролика заранее.
12 дек 18, 15:25    [21761704]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
uaggster
dezhnevo
Здравствуйте.
На новом месте работы поставили задачу разобраться с производительностью сервера SQL. Сказали, что пользователи жалуются, «тормозит, плохо работает».

Давайте я напишу несколько очевидных вещей, которые гарантированно помогают (кроме шуток), увеличить производительность MSSQLSERVER. Правда, речь идет мере такого увеличения :-)
Большая часть перечисленного с вероятностью 95% никак не повлияет на «тормозит, плохо работает». В итоге работы много, а толку мало. Например теже 12 файлов под tempdb. Больше 8 имеет смысл создавать только если есть tempdb contention. Короче в качестве обучения конечно хорошо, но проблему ТС скорее всего не решит, ну кроме пункта 23 :-)
13 дек 18, 04:21    [21762327]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
uaggster
При интенсивных вставках и обновлениях данных, в кластерном и некластерных индексах могут образовываться "дырки". Страницы, и данные на страницах, которые помечены как удаленные.
а из 8 кб там полезных только 2 кб, остальное - помечено как удаленное.
Такое возможно только при массовых удалениях, ибо вставки и обновления делят страницу попалам, так что ниже 50% использованное место все таки очень редко опускается.
13 дек 18, 04:25    [21762331]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7215
uaggster
17. Перенесите базу на SSD.
18. Если вы не можете этого сделать, а у вас 2014+ SQL - хотя бы включите BPE https://olontsev.ru/tag/buffer-pool-extension/


17. смешно. на один чтоле?

А вы знаете, что пропускная способность у SSD - никакущая. Тут чем больше спинделей тем лучше.

18. Как далеки они были от народа?

Ктото еще покупается на эту туфту?
13 дек 18, 05:39    [21762341]     Ответить | Цитировать Сообщить модератору
 Re: Производительность SQL сервера ВОПРОС!  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7215
По остальным пункам, тоже пальцем в небо. Что если оно уже и есть так? Тогда что посоветуете?
13 дек 18, 05:43    [21762342]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить