Использование индекса отношений на гремлине относительно медленно

В Neo4j у меня есть индекс отношения index_e_ASSOC_sMETHdGEXP, содержащий около 180000 ребер, все с атрибутом property. Я хочу сделать простой запрос, который перечисляет 200 ребер из индекса, в этот момент независимо от значения свойства (позже выполните запрос, например, выберите те же значения атрибутов для 200 вершин первого края, где свойство edge ‹= 0,01), и получить несколько значений атрибутов из выходного узла:

time = System.currentTimeMillis();
t = new Table(); g.idx('index_e_ASSOC_sMETHdGEXP')[[property: Neo4jTokens.QUERY_HEADER + "*"]][0..200].outV().id.as('nodeId').back(1).alias.as("alias").back(1).chr.as('chr').table(t,["nodeId","alias","chr"]).iterate();
System.currentTimeMillis() - time

= 713 мс

Получение 200 первых ребер из индекса занимает 262 мс:

time = System.currentTimeMillis();
g.idx('index_e_ASSOC_sMETHdGEXP')[[property: Neo4jTokens.QUERY_HEADER + "*"]][0..200];
System.currentTimeMillis() - time

Почему первый запрос выполняется так медленно? Это не займет много времени, чтобы получить 200 ребер из «заранее определенного списка» и получить несколько значений атрибутов из каждого выходного узла. Когда дело доходит до Сайфера и Гремлина, я новичок, есть ли более быстрый способ выполнить этот запрос в Сайфере или Гремлине?

Изменить: выполнить запрос (1) 23 раза:

==> 1124
==> 983
==> 951
==> 864
==> 1175
==> 1189
==> 889
==> 917
==> 822
==> 872
==> 795
==> 736
==> 840
==> 1189
==> 723
==> 756
==> 691
==> 44609
==> 644
==> 640
==> 1110
==> 1007
==> 819

Edit2: с тех пор я повторно импортировал базу данных со следующей конфигурацией:

dump_configuration=true
cache_type=gcr
neostore.nodestore.db.mapped_memory=100M
neostore.relationshipstore.db.mapped_memory=4G
neostore.propertystore.db.mapped_memory=200M
neostore.propertystore.db.strings.mapped_memory=1G
neostore.propertystore.db.arrays.mapped_memory=1G
neostore.propertystore.db.index.keys.mapped_memory=1G
neostore.propertystore.db.index.mapped_memory=1G
relationship_cache_array_fraction=8
node_cache_array_fraction=8
node_cache_size=3G
relationship_cache_size=6G

Теперь запрос (1) действительно занимает больше времени: 23849 мс. Это начинает выглядеть как проблема с кешем.

Интересные фрагменты журнала db:

2012-07-06 10:51:49,149 DEBUG [neo4j.diagnostics]: System memory information:
2012-07-06 10:51:49,152 DEBUG [neo4j.diagnostics]: Total Physical memory: 26,37 GB
2012-07-06 10:51:49,152 DEBUG [neo4j.diagnostics]: Free Physical memory: 11,99 GB
2012-07-06 10:51:49,153 DEBUG [neo4j.diagnostics]: Committed virtual memory: 16,43 GB
2012-07-06 10:51:49,153 DEBUG [neo4j.diagnostics]: Total swap space: 27,00 GB
2012-07-06 10:51:49,153 DEBUG [neo4j.diagnostics]: Free swap space: 26,96 GB
2012-07-06 10:51:49,154 DEBUG [neo4j.diagnostics]: JVM memory information:
2012-07-06 10:51:49,154 DEBUG [neo4j.diagnostics]: Free  memory: 1,84 GB
2012-07-06 10:51:49,154 DEBUG [neo4j.diagnostics]: Total memory: 1,87 GB
2012-07-06 10:51:49,154 DEBUG [neo4j.diagnostics]: Max   memory: 13,33 GB
2012-07-06 10:51:49,588 DEBUG [neo4j.diagnostics]: Storage files:
2012-07-06 10:51:49,589 DEBUG [neo4j.diagnostics]: messages.log: 304,72 kB
2012-07-06 10:51:49,589 DEBUG [neo4j.diagnostics]: neostore.propertystore.db.index: 1,02 kB
2012-07-06 10:51:49,589 DEBUG [neo4j.diagnostics]: neostore.propertystore.db: 401,18 MB
2012-07-06 10:51:49,590 DEBUG [neo4j.diagnostics]: neostore.relationshipstore.db.id: 9,00 B
2012-07-06 10:51:49,590 DEBUG [neo4j.diagnostics]: index.db: 1,42 kB
2012-07-06 10:51:49,590 DEBUG [neo4j.diagnostics]: tm_tx_log.1: 0,00 B
2012-07-06 10:51:49,590 DEBUG [neo4j.diagnostics]: neostore.relationshiptypestore.db.names.id: 9,00 B
2012-07-06 10:51:49,591 DEBUG [neo4j.diagnostics]: neostore.propertystore.db.id: 9,00 B
2012-07-06 10:51:49,591 DEBUG [neo4j.diagnostics]: neostore.nodestore.db: 478,88 kB
2012-07-06 10:51:49,591 DEBUG [neo4j.diagnostics]: nioneo_logical.log.active: 4,00 B
2012-07-06 10:51:49,591 DEBUG [neo4j.diagnostics]: neostore.nodestore.db.id: 9,00 B
2012-07-06 10:51:49,591 DEBUG [neo4j.diagnostics]: neostore.propertystore.db.strings.id: 9,00 B
2012-07-06 10:51:49,592 DEBUG [neo4j.diagnostics]: neostore.id: 9,00 B
2012-07-06 10:51:49,592 DEBUG [neo4j.diagnostics]: neostore.propertystore.db.strings: 34,15 MB
2012-07-06 10:51:49,592 DEBUG [neo4j.diagnostics]: neostore.relationshiptypestore.db.id: 9,00 B
2012-07-06 10:53:01,486 INFO  [neo4j]: GC Monitor: Application threads blocked for an additional 14826ms [total block time: 14.826s]
2012-07-06 10:54:24,019 INFO  [neo4j]: GC Monitor: Application threads blocked for an additional 875ms [total block time: 15.701s]
2012-07-06 10:55:25,441 INFO  [neo4j]: GC Monitor: Application threads blocked for an additional 559ms [total block time: 16.26s]
2012-07-06 11:00:16,962 INFO  [neo4j]: GC Monitor: Application threads blocked for an additional 775ms [total block time: 17.035s]

Параметры JVM включают

-XX:+DisableExplicitGC
-Xms2000m,
-Xmx15360m

Кажется, что сборщик мусора мешает выполнению, почему? С помощью параметров JVM я говорю экземпляру сервера использовать максимальный объем ~ 15 ГБ памяти, чего должно быть достаточно.

Edit4: выполнение запроса (1) добавляет в журнал следующее:

2012-07-06 11:40:31,973 INFO  [neo4j]: GC Monitor: Application threads blocked for an additional 23745ms [total block time: 23.745s]
2012-07-06 11:40:33,961 INFO  [neo4j]: RelationshipCache array size: 17895751 purge count: 0 size is: 0b, 100.0% misses, NaN% collisions (0).
2012-07-06 11:40:33,966 INFO  [neo4j]: NodeCache array size: 17895751 purge count: 0 size is: 0b, 100.0% misses, NaN% collisions (0).

person amergin    schedule 27.06.2012    source источник


Ответы (1)


Вы пытались выполнить запрос несколько раз, поэтому вы работаете с теплым графиком и индексом?

person Peter Neubauer    schedule 02.07.2012
comment
Прогнали 23 раза и, как видите, довольно сильно различаются. В основном к худшему. - person amergin; 03.07.2012