You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gremlin schema sync fetches edge labels and their counts with a single unbounded aggregation:
g.E().groupCount().by(label)
On a large graph this exhausts Neptune's memory and the whole schema sync fails, so the connection never becomes usable. This is worse than a Schema View problem, because nothing downstream of schema sync can run.
Measured on one Neptune 1.3.5.0 db.t3.medium with DFE enabled and statistics disabled:
Graph size
Result
57,538 edges
succeeds in about 1.2s, fully native per its explain plan
1,057,538 edges
MemoryLimitExceededException in under 10s
This code path only runs when the summary API is unavailable, which on Neptune means statistics are disabled. When the summary API works, fetchSchema takes the summary path and never issues this query. That narrows the blast radius considerably, and I have not checked how common the disabled case is in practice.
Two things I did not measure but expect to share the defect:
vertexLabelsTemplate is g.V().groupCount().by(label), the same shape, so a graph with a comparable number of vertices should fail the same way.
openCypher (MATCH ()-[e]-() RETURN type(e) AS label, count(*) AS count) and SPARQL have equivalent unbounded count queries.
Schema sync completes on a large graph whether or not statistics are enabled. The label and count discovery needs to be bounded, most likely by chunking per label rather than aggregating the whole edge store in one request.
Related Issues
Related: #2141 (found while investigating it; the fix there does not touch this query), #1677
Important
Internal only — this issue is maintained by the core team and is not accepting external contributions.
Description
Gremlin schema sync fetches edge labels and their counts with a single unbounded aggregation:
On a large graph this exhausts Neptune's memory and the whole schema sync fails, so the connection never becomes usable. This is worse than a Schema View problem, because nothing downstream of schema sync can run.
Measured on one Neptune 1.3.5.0
db.t3.mediumwith DFE enabled and statistics disabled:MemoryLimitExceededExceptionin under 10sThis code path only runs when the summary API is unavailable, which on Neptune means statistics are disabled. When the summary API works,
fetchSchematakes the summary path and never issues this query. That narrows the blast radius considerably, and I have not checked how common the disabled case is in practice.Two things I did not measure but expect to share the defect:
vertexLabelsTemplateisg.V().groupCount().by(label), the same shape, so a graph with a comparable number of vertices should fail the same way.MATCH ()-[e]-() RETURN type(e) AS label, count(*) AS count) and SPARQL have equivalent unbounded count queries.Affected files:
packages/graph-explorer/src/connector/gremlin/fetchSchema/edgeLabelsTemplate.tspackages/graph-explorer/src/connector/gremlin/fetchSchema/vertexLabelsTemplate.tspackages/graph-explorer/src/connector/gremlin/fetchSchema/index.ts(fetchEdgeLabels,fetchVerticesSchema)Environment
db.t3.medium, DFE enabled, cluster statistics disabledSteps to Reproduce
BadRequestException.g.E().groupCount().by(label)directly returnsMemoryLimitExceededException.Expected Behavior
Schema sync completes on a large graph whether or not statistics are enabled. The label and count discovery needs to be bounded, most likely by chunking per label rather than aggregating the whole edge store in one request.
Related Issues
Related: #2141 (found while investigating it; the fix there does not touch this query), #1677
Important
Internal only — this issue is maintained by the core team and is not accepting external contributions.