Максимальный DTU базы данных SQL Azure - из-за большой базы данных?

Question

У нас есть база данных Azure SQL. Еще несколько недель назад у нас было 10 DTU (S0). Недавно мы получили больше ошибок времени ожидания SQL, побуждая нас увеличить наши DTU до 50 (S2). Мы получаем ошибки реже, но все же иногда. Когда мы получаем эти тайм-ауты, мы видим, что пики на графике ресурсов достигают 100%. Если говорить более подробно, то, как правило, операции ввода-вывода данных делают это всплеском. Но когда мы проверяем Query Performance Insight, ни один из перечисленных запросов не показывает, что они используют столько ресурсов.

Еще одна вещь, которую стоит отметить, это то, что наша база данных постоянно растет в размере. Сейчас это около 19 ГБ, и большая часть (18 ГБ) этого происходит из одной таблицы, в которой много длинных строк JSON. Ошибки тайм-аута обычно происходят в определенном запросе с несколькими объединениями, но они не взаимодействуют с таблицей с длинными строками.

Мы протестировали создание копии базы данных и удаление всех длинных строк, и она не получила никаких тайм-аутов при 10 DTU, но выполнила то же самое, что и база данных со всеми длинными строками при 50 DTU, что касается времени загрузки.

Мы перестроили наши индексы и, хотя это помогло, мы продолжаем испытывать ошибки тайм-аута.

Учитывая, что запрос, который получает тайм-ауты, не касается таблицы с длинными строками, может ли таблица с длинными строками оставаться виновником использования DTU? Это будет связано с кэшированием SQL? Могут ли длинные строки перегружать кэш и вызывать много ввода-вывода данных? (К ним тоже довольно часто обращаются.)

Answer 1

Строки могут определенно исчерпать ваш бюджет кэша, если они горячие (как вы говорите, они есть). Когда горячий рабочий набор превышает размер кэша ОЗУ, производительность может упасть с обрыва (в 10-100 раз). Это потому, что IO в 10-1000 раз медленнее, чем доступ к RAM. Это означает, что даже незначительное снижение коэффициента попадания в кэш (например, 1%) может привести к большой потере производительности.

Этот утес может быть очень крутым. В один момент приложение в порядке, в следующий момент IO не в чартах.

Поскольку база данных SQL Azure имеет строгие ограничения на ресурсы (как я слышал и читал), это может быстро исчерпать производительность, которую вы приобрели, в результате регулирования.

Я думаю, что тест, который вы сделали, как бы подтверждает, что строки являются причиной проблемы. Можете ли вы попытаться отделить строки где-нибудь еще? Если им холодно, перенесите их на другой стол. Если они горячие, переместите их в другое хранилище данных (база данных или NoSQL). Таким образом, вы, вероятно, сможете вернуться на более низкий уровень.