Как решить проблемы с зависанием ArangoDB Foxx?

В процессе тестирования наше приложение Foxx попадает в проблему «обнаружен тупик». Похоже, это вызвано запросами на обход. Априори, трудно, если не невозможно узнать, какие таблицы будут использоваться во время обхода. Однако я взял один конкретный случай, когда я мог определить количество таблиц и заключить AQL в транзакцию для тестирования:

var result = db._executeTransaction ({"collections": {"read": ["pmlibrary", "pmvartype", "pmvariant", "pmproject", "pmsite", "pmpath", "pmattic"]}, "action ":" function () {var db = require (\ "@ arangodb \"). db; var res = db._query (\ "FOR o IN ['pmlibrary / 199340787'] FOR v, e, p IN 0. .7 INBOUND o pm_child RETURN p.vertices \ "); return res.toArray ()}"});

FYI, список таблиц в коллекциях не включает граничные таблицы.

Однако тупиковые ситуации по этому заявлению продолжаются. Я не уверен, что попробовать дальше. Спасибо.


person ggendel    schedule 04.04.2017    source источник


Ответы (2)


Я не эксперт по индексированию / производительности с ArangoDB, но недавно у меня тоже были некоторые проблемы с взаимоблокировкой, и реконструкция и изменение формы запросов давали огромный прирост производительности, иногда запросы, которые занимали 120 секунд, а затем 0,2 секунды.

Ключевым моментом, который я сделал, было помочь ArangoDB узнать, когда использовать индекс, и убедиться, что этот индекс можно использовать.

В вашем примере запроса есть проблема, из-за которой ArangoDB не знает, что происходит индекс:

FOR o IN ['pmlibrary/199340787'] 
FOR v,e,p IN 0..7 INBOUND o pm_child 
  RETURN p.vertices

Ключевой проблемой здесь является то, что ваш исходный цикл FOR использует значение из массива, что может помешать ArangoDB идентифицировать индекс. Вы можете легко заменить ваш o параметром и напрямую ввести значение 'pmlibrary/199340787', а с помощью кнопки «Объяснить» посмотреть, указывает ли оно, что может использовать индекс.

Одна проблема, которую я обнаружил, заключалась в попытке сделать очень понятным использование индекса, что иногда означало добавление дополнительных команд LET, чтобы позволить ArangoDB создавать содержимое массивов, а затем, похоже, он знал, какой индекс использовать лучше.

Если бы вы должны были протестировать производительность вышеприведенного запроса, по сравнению с чем-то вроде:

LET my_targets = (FOR o IN pmlibrary FILTER o._key == '199340787' RETURN o._id)

FOR o IN my_targets
FOR v,e,p IN 0..7 INBOUND o._id pm_child 
  RETURN p.vertices

Это может показаться нелогичным, но при тестировании я обнаружил поразительный прирост производительности, разбив запросы на части, чтобы помочь ArangoDB заметить, что он может использовать индекс.

Если какие-либо запросы относятся к значениям в массивах или если вы используете имена динамических атрибутов, тогда он не всегда будет использовать индекс, даже если он существует.

Также я обнаружил, что сервер будет кэшировать ответ на запросы, поэтому, если вы хотите протестировать изменения в длительном запросе и хотите избежать попаданий в кеш на ваши вторые запросы +, мне пришлось остановить и перезапустить службу arangodb3.

Я надеюсь, что это поможет дать вам цель для перетасовки вашего запроса для работы с индексами.

Помните, что у вас уже есть встроенные индексы для _id, _key, _from, _to, поэтому вам нужно попробовать и убедиться, что он будет использовать другие индексы, которые могут помочь ускорить ваш запрос.

person David Thomas    schedule 10.04.2017
comment
Дэвид, спасибо за информацию. В моем случае в массиве может быть несколько элементов, и они могут быть в разных коллекциях. Оказалось, что было выдано две тупиковые ошибки. Я полагал, что операторы AQL играют друг против друга, но оказалось, что это должны быть одновременные вызовы одних и тех же операторов AQL. Тестировщик QA не сказал мне, что я действительно исправил первое, используя предложение WITH. Я просто подумал, что что-то упустил. С предложениями WITH в обоих операторах больше нет тупиковой ситуации. - person ggendel; 11.04.2017

Правильным решением было использование предложения WITH, а не транзакции.

person ggendel    schedule 11.04.2017