Почему Gremlin Server / JanusGraph игнорирует некоторые из моих запросов?

Я использую библиотеку Gremlin Python для обхода развертывания JanusGraph сервера Gremlin (то же самое происходит и с использованием только Tinkergraph). Некоторые длинные обходы (с тысячами инструкций) не получают ответа, ошибок, таймаутов, записей журнала или ошибок на сервере или клиенте. Ничего такого.

Условия этого лечения молчанием не ясны. Описанное поведение не зависит линейно от байтов или количества инструкций. Например, у меня навсегда останется такой код:

g = traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin', 't'))
g = g.inject("")
for i in range(0, 8000):
    g = g.constant("test")
print(f"submitting traversal with length={len(g.bytecode.step_instructions)}")
result = g.next()
print(f"done, got: {result}") # this is never reached

Это зависит не только от количества байтов в сообщении запроса, поскольку количество инструкций, на которые я не получаю ответа, не меняется даже при очень больших постоянных значениях вместо простого теста. Например, введение 7000 значений с большим количеством абзацев Lorem Ipsum работает должным образом и возвращается через несколько миллисекунд.

Хотя это не имеет значения (поскольку я должен получать правильную ошибку, а не ничего), я уже увеличил серверные maxHeaderSize, maxChunkSize, maxContentLength и т. Д. До смехотворно высоких чисел. Изменение формата сериализации (например, с GraphSONMessageSerializerV3d0 на GraphBinaryMessageSerializerV1) тоже не помогает.

Примечание: я знаю, что очень длинные обходы - это анти-шаблон в Gremlin, но иногда невозможно или очень неэффективно структурировать обходы таким образом, чтобы вместо этого они могли использовать введенные значения.


person flotothemoon    schedule 07.04.2021    source источник


Ответы (1)


Я ответил на этот вопрос о gremlin-users не понимая, что это также было задано здесь, в StackOverflow. Для полноты я продублирую свой ответ здесь.

Проблема меньше связана с байтами и длиной строки, а больше с длиной цепочки обхода (то есть количеством шагов в вашем обходе). В конечном итоге вы достигаете ограничения JVM на размер стека на сервере. Вы можете увеличить размер стека на jvm, изменив размер значения -Xss, что должно позволить вам увеличить длину обхода. Скорее всего, это потребует повторного изучения других параметров JVM, таких как -Xmx и, возможно, параметры сборки мусора.

Мне действительно интересно, что вы не получаете никаких сообщений об ошибках - вы должны где-то увидеть stackoverflow, если только сервер полностью не завис из-за вашего запроса. Я бы подумал о том, чтобы добавить в него больше -Xmx, чтобы увидеть, сможете ли вы заставить его ответить как минимум ошибкой, или следить за журналами сервера, чтобы хотя бы увидеть, как она там появляется.

person stephen mallette    schedule 09.04.2021
comment
Спасибо за предложение! Я уже проверял размер и использование кучи, но забыл упомянуть об этом в своем сообщении. Я запускаю это с кучей 16 ГБ на узле Kubernetes 32 ГБ с большой вычислительной мощностью. Никаких всплесков использования я не вижу вообще, запасных всего предостаточно. Попробую увеличить размер стека. - person flotothemoon; 09.04.2021
comment
Помогло увеличение размера стека - отлично. Я предварительно обозначу это как ответ, поскольку, пока он устраняет проблему (спасибо!), Мы не выяснили, как обнаружить это в производственной среде. Как узнать, что это проблема стека, а не просто тайм-аут, если сервер не отвечает? Как я могу поддерживать низкое давление в стеке с помощью длинных переходов? Глядя на источник, кажется, что пакетирование частей обхода в sideEffect может помочь, но я недостаточно знаю о внутренней работе сервера Janus / Gremlin. Или, может быть, в стеке накапливается синтаксический анализ запросов ... - person flotothemoon; 09.04.2021
comment
Я полагаю, что если обход будет достаточно длинным, может произойти тайм-аут, прежде чем у вас возникнет проблема со стеком. но в одном случае вы получите ошибку тайм-аута, а в другом - исключение stackoverflow. любой должен отображаться в журналах сервера, я думаю. если вы решите использовать длинные обходы, вам придется иметь дело с размером стека, поскольку это проблема уровня JVM. у вас была бы такая же проблема, если бы вы писали Java и просто продолжали бесконечно связывать вызовы методов вместе ... рано или поздно вы взорвете стек. - person stephen mallette; 09.04.2021
comment
Я не экспериментировал с sideEffect() шагом, чтобы узнать, помогает ли это, но на самом деле похоже, что может. если ваш вариант использования позволяет это, возможно, это путь, по которому следует идти. Лично я бы предпочел реструктурировать, чтобы избежать долгого обхода, и, возможно, даже снизить производительность, чтобы избежать слишком близкого к пределу стека. - person stephen mallette; 09.04.2021
comment
Понял, спасибо. Как бы вы без долгих обходов выполняли массовые операции, затрагивающие большое количество данных в рамках одной транзакции? Теоретически меня устраивает обмен некоторой производительности на стабильность системы. Хотя при вставке большого количества ребер я получаю 5x + ускорение, используя addE(..).from(V(from_id)).to(V(to_id)), а не addE(..).from(select("vertices").select(from_id)).to(select("vertices").select(to_id)) (где vertices заранее заполняется необходимыми вершинами). Как я могу реструктурировать это, не жертвуя такой производительностью? - person flotothemoon; 09.04.2021
comment
если у вас должна быть длительная одиночная транзакция, которая затрагивает многие вещи, тогда я думаю, я бы подумал об использовании сеанса и отправке нескольких запросов на него. Сеансы + транзакции получат лучшую поддержку в версии 3.5.0, поэтому я думаю, что я буду использовать сценарии в 3.4.x для этого конкретного варианта использования, пока строка 3.5.x не получит широкую поддержку - issues.apache.org/jira/browse/TINKERPOP-2537 - person stephen mallette; 09.04.2021
comment
Есть какие-то указания, когда приземлится 3.5? Я не мог найти никаких предложенных дат в системе отслеживания проблем или на Github. - person flotothemoon; 21.04.2021
comment
примерно через 2 недели, если все пойдет по плану. вам необходимо подписаться на список рассылки разработчиков, если вы хотите быть в курсе обсуждений выпуска: lists.apache.org/[email protected] - person stephen mallette; 21.04.2021