Index hints in X++ again

[AlexeyS]

Цитата:

Сообщение от fed

Ты знаешь, с тех пор как я начал с аксаптой работать, производительность жестких дисков (если не держать базу на SDD) возросла раз в 20-30-40. Производительность процессоров - раз в 500 наверное. Поэтому накладняк на построение плана запроса с легкостью перекрывается экономией на времени исполнения кривого плана запроса.
Плюс - заметные затраты на построение плана запроса происходят при большом числе таблиц в запросе (типа штук 8-10). А в такие запросы особо index hint не попихаешь, поскольку там скорее собака в типе джойна зарыта. (А тут всего один хинт есть - forcenestedloops, а этого явно не хватит).

Похоже БД все чаще становится бутылочным горлышком. Например X5 работают на SAP и пишут что вынесли на уровень сервера приложений часть join-запросов, чтобы снизить нагрузку на БД.

[fed]

Цитата:

Сообщение от AlexeyS

Похоже БД все чаще становится бутылочным горлышком. Например X5 работают на SAP и пишут что вынесли на уровень сервера приложений часть join-запросов, чтобы снизить нагрузку на БД.

БД всегда была бутылочным горлышком. Я за те 10 лет, которые я всерьез занимаюсь тюнингом производительности Ax, столкнулся всего с одним случаем, когда проблема была не в БД: Разработчики заказчика поставили Full Table Cache на часто обновляемую таблицу. В результате, большую часть времени AOS в кластере тратил на перечитывание этой таблицы. (И, кстати, таблица была слишком большая чтобы в память поместиться, так что сервера ее на локальный диск складывали). Все остальные проблемы так или иначе вызывались торможением БД.
Ну и вообще ситуации когда система 300000 запросов в секунду к серверу отправляет, говорит о некоторой кривости функционала.

[AlexeyS]

Цитата:

Сообщение от fed

БД всегда была бутылочным горлышком. Я за те 10 лет, которые я всерьез занимаюсь тюнингом производительности Ax, столкнулся всего с одним случаем, когда проблема была не в БД: Разработчики заказчика поставили Full Table Cache на часто обновляемую таблицу. В результате, большую часть времени AOS в кластере тратил на перечитывание этой таблицы. (И, кстати, таблица была слишком большая чтобы в память поместиться, так что сервера ее на локальный диск складывали). Все остальные проблемы так или иначе вызывались торможением БД.
Ну и вообще ситуации когда система 300000 запросов в секунду к серверу отправляет, говорит о некоторой кривости функционала.

Работа с транзакционной БД всегда самая медленная часть, это и так понятно. Я немного про другое, про приемлемую скорость работы, когда даже оттюненая БД не тянет.
Когда я занимался производительностью АХ, значительная часть проблем была не в базе как таковой, а в том, что по ней статистика была устаревшая и индексов не хватало, т.е просто недостаточно обслуживалась. А еще - проблемы с кривым кодом, когда, например, настроечная таблица не закеширована на ОАС и постоянно идут мелкие запросы, отжирающие ресурсы. Или запрос к большой таблице уходит с пустыми Range. Или нужно разделить одну большую транзакцию на несколько маленьких. С одной стороны это скорее проблемы приложения, но в итоге все равно если не разбираться почему, то мнение одно - тормозит БД.