Когда лиса Арангодба собирает мусор? - PullRequest
0 голосов
/ 13 ноября 2018

Что я понимаю, это;

  • Foxx основан на V8 Engine.
  • Foxx является многопоточным и не разделяет состояние с другими потоками
  • Поток Foxx выйдет (это правильный термин?), Как только он отправит ответ клиенту.

Помимо сбора мусора в V8 Engine, означает ли это, что любая память, используемая foxx, собирается как мусор, как только получен ответ?
Если ответ на вышеуказанный вопрос положительный, есть ли способ отключить сборщик мусора V8 Engine, и если я отключу сборщик мусора V8 Engine, могу ли я ожидать лучшей задержки?

Пожалуйста, дайте мне знать, если я ошибаюсь.

1 Ответ

0 голосов
/ 14 ноября 2018

В отличие от многих других интерпретаторов, интерпретаторы javascript имеют особую функцию. Их нужно запустить для нескольких окон браузера, и одно окно не должно знать о другом.

Таким образом, набор операций интерпретатора строго отделен от его общей логики. В В V8 эта концепция реализована под названием Isolate.

ArangoDB порождает несколько Isolates, каждый из которых может работать в Foxx. Инфраструктура ArangoDB имеет хуков в Isolates, которые могут сигнализировать о наличии новых коллекций. Тем не менее, нет такого крючка, который можно было бы использовать в Foxx.

ArangoDB является многопоточным. Брокер запросов прочитает запрос, и если он обнаружит, что должен выполнить Foxx-запрос (вместо прямого вызова AQL), ​​он выберет один из изолятов из пула и продолжит выполнение в этом контексте V8. Таким образом, нет гарантии, что вы достигнете того же рабочего потока, и что он выберет тот же изолят при последующих запросах.

Каждый из этих изолятов можно собирать мусором индивидуально, не блокируя выполнение в других изолятах. ArangoDB Предоставляет статистику об этих контекстах , так что вы можете видеть там, что изоляты могут быть помечены dirty, что означает, что они должны собираться мусором. Вы можете использовать require("internal").wait(<seconds>, true) для ручного вызова сборки мусора. Количество создаваемых контекстов зависит от количества процессоров в вашей системе. Однако эти параметры можно настроить. Таким образом, вы видите, что тактика сильно отличается от настройки Java GC.

Foxx сам откажется от структур, выделенных сервисами после запроса. Затем они будут недоступны в последующих запросах, и после запуска сборки мусора их память будет возвращена в систему.

Обычно вы должны стремиться сделать свои сервисы Foxx тонким слоем вокруг AQL , который вы выполняете. Хотя производительность следует рассматривать как функцию, вы, как правило, начинаете смотреть на нее, как только ваш код достиг определенного уровня зрелости. Мы объяснили , как создавать сценарии использования, измерять и оптимизировать возможные результаты в нашей серии постов в блоге ; хотя сервисы Foxx там не упоминаются напрямую, используемая там тактика может быть применена и к Foxx.

...