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


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

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

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

Ктото еще покупается на эту туфту?
Почему на один? На зеркало.
Ну и следите за их состоянием :-)

Relic HunterПо остальным пункам, тоже пальцем в небо. Что если оно уже и есть так? Тогда что посоветуете?
А вы попробуйте пару пунктов выГлючить, и насладитесь результатом.

Это советы "уровня ноль".
Чтобы делать НЕ так - нужно понимать, зачем ты так сделал. Если так уже сделано, но по прежнему тормозит - то проблема уже за пределами компетенции ТС. Пусть наймут консультанта или ТС пусть сядет за курсы.

Кстати, не продемонстрируете ли свои ТОП(23) "что нужно сделать/проверить на тормозящем сервере в первую очередь", чтобы мы увидели, как это "не пальцем в небо"?

Кстати, забыл еще пункт:
24. Если базы лежат не на отдельной полке, а на томах, подключенных к рэйд контроллеру сервера - проверьте, есть ли на контроллере сервера батарейка и включен ли режим кэширования Write-back.
Для увеличения производительности крайне рекомендуется на контроллере с батарейкой отключить кэш дисков и включить режим кэширование данных контроллером Write-back .
Это можно сделать и без батарейки. Но тогда вжимайтесь в кресло и делайте почаще бэкап, особенно бэкап логов. :-)
Там же, в настройках контроллера, есть настройка режима упреждающего чтения read ahead.
Вот в отношении нее - ничего определенного сказать не могу. Если приложение дергает по одной записи из базы - то нужен режим "без упреждающего чтения". Если наоборот, речь идет о базе статистики, и приложение читает данные большими кусками - то "с упреждающим чтением".
Попробуйте и так и этак, и померьте производительность.

МифодяuaggsterКстати, забыл еще пункт:
24. Если базы лежат не на отдельной полке, а на томах, подключенных к рэйд контроллеру сервера - проверьте, есть ли на контроллере сервера батарейка и включен ли режим кэширования Write-back.
Для увеличения производительности крайне рекомендуется на контроллере с батарейкой отключить кэш дисков и включить режим кэширование данных контроллером Write-back .
Это можно сделать и без батарейки. Но тогда вжимайтесь в кресло и делайте почаще бэкап, особенно бэкап логов. :-)
Там же, в настройках контроллера, есть настройка режима упреждающего чтения read ahead.
Вот в отношении нее - ничего определенного сказать не могу. Если приложение дергает по одной записи из базы - то нужен режим "без упреждающего чтения". Если наоборот, речь идет о базе статистики, и приложение читает данные большими кусками - то "с упреждающим чтением".
Попробуйте и так и этак, и померьте производительность.

ПО поводу рейд контроллера и параметров, полностью с вами согласен, и ещё немного добавлю по поводу read ahead, где-то читал что есть ещё одно положение этого параметра, адаптивный вроде бы. Суть в том что контроллер сам определяет нужно ли упереждающее чтение или нет в зависимости от потока запросов, и может как включать его так и выключать.
На моих "адаптивного" нет :-(
А по поводу упреждающего чтения - на моей практике был случай, когда его выключение (выключение, ага) дало прирост производительности где-то процентов 10. И, как результат, набор отчетов, который генерился 10 часов, и, обычно не успевал к планерке - стал генериться меньше 9 часов, и к планерке начал успевать, чем подбросил пачку дрожжей в наше устоявшееся... эээ... отхожее место.
Но там 1С был, и всё сложно. :-)))

Владислав КолосовВ моей практике были случаи, когда перемещение баз на SSD ухудшало производительность. Но с чем это связано, я не выяснял.
У SSD не всё в порядке с производительностью за пределами SLC-кэша.
OSZНекоторые SSD, особенно бюджетные модели на памяти TLC flash memory вроде OCZ Trion 100 используют SLC кеш для ускорения процесса записи. Этот метод позволяет использовать часть ёмкости как SLC (1bit-per-cell) NAND flash memory. При записи пишется только один бит вместо 3-х, тем самым значительно повышая скорость операции. Когда SLC кеш полностью заполнен, он будет перенесён на не занятый объём, освобождая пространство для дальнейшей работы этого метода ускорения производительности. При обычной нагрузке пользователь не замечает этот перенос. Но при повышенной нагрузке возможно временное снижение скорости накопителя, когда кеш уже полностью заполнен, но операции записи ещё не завершились. После переноса кеша в свободное пространтсво накопителя скорость восстановится.

Размер этого кэша довольно большой (десятки гигабайт + -), но всё вполне по меркам БД - исчерпаемый.
При этом про небольшое снижение производительности - они врут, там иногда в 10, а то и в 20 раз снижение.
Т.е. Если, например, льём bulk'ом десятки гигабайт (даже гигабайты) - то вполне себе можем за пределы slc-кэша вылететь, и получить 10 Мб/с (утрированно) на запись.
Кроме того есть такая гадость, как trim. Ячейки флэша перед записью нужно предварительно очистить. Поэтому если на диске интенсивно перезаписывается информация - вполне может вылезти ситуация, когда диск пустой, а писать - некуда, и диск должен начать сборку мусора.
Нормальные серверные SSD вполне это умеют в фоновом режиме, но даже у них это получается плохо, с падением производительности в разы, даже десятки раз.
Т.е., если мы имеем ситуацию, когда мы апдейтим (например) даже небольшое количество записей с очень высокой частотой - через какое то время получим периодические лаги.

Итого - SSD, конечно, киллер-фича, но... скажем так, при разумных условиях использования.
ИМХО так.
:-)

MinduaggsterКстати, не продемонстрируете ли свои ТОП(23) "что нужно сделать/проверить на тормозящем сервере в первую очередь", чтобы мы увидели, как это "не пальцем в небо"?Для начала нужно выяснить почему тормозит. Если все ресурсы (проц, диски, память) в норме, то почти наверняка это кривые/неоптимизированные запросы. Ну и как уже было 25 раз сказано нужно сначала выяснить у пользователей что именно тормозит, а то можно искать совсем не в том месте.
Вопросов больше не имею.