Neo4j memory 구성

version 4.0 기준

 

OS Memory

• 페이지 캐시와 힙 공간 구성 후에도 RAM 공간이 어느정도 남아야함 → 없으면 디스크로 swapping 되어 성능에 영향
• 1GB가 좋은 출발점이라고 함

Lucene index cache

• 인덱싱 기능 중 일부를 apache lucene으로 사용함.
• 명시적으로 지정해주지 않으면 native-btree index 사용 (apache lucene은 사용 안함)
• 인덱스가 메모리에 캐시 되도록 하여 성능 최적화

Page Cache

• 페이지 캐시는 Neo4j data와 native index를 캐시하는데 사용 됨.
• 디스크 액세스 비용 감소시킴.
• Neo4j 가 페이지 캐시에 사용할 수 있는 메모리 크기는 dbms.memory.pagecache.size로 지정 가능
• 실제 데이터 저장되는 캐시 (아래 설정 방법 설명 있음)

Heap size

• heap 공간은 query, transaction state, graph 관리 등에 사용 됨
• 장기간 실행 되는 쿼리 or 복잡한 쿼리는 많은 힙 공간을 차지하게 됨
• → periodic commit으로 실행하지 않는 장시간 쿼리는 oom 발생함
• → 테스트 환경에 create 할 때에도 apoc 같은 플러그인으로 실행 (memory error 때문)
• 일반적으로는 성능 보조를 위해 큰 힙 구성이 좋음
• dbms.memory.heap.initial_size / dbms.memory.heap.max_size 로 지정
• 위 2개 파라미터는 동일한 값으로 설정하는 것이 좋다.

Transaction state

• 레코드를 업데이트 하는 트랜잭션에서 데이터와 중간 결과를 저장하는데 필요한 메모리
• 읽기만 하는 쿼리는 이 메모리에 할당되지 않는다.
• 이 메모리는 사전에 할당되지 않고, 필요에 따라 증가 축소됨

Considerations

Always use explict configuration

• page cache & heap size를 명시적으로 neo4j.conf 에 지정해줘라
• 그렇지 않으면 휴리스틱 value들이 시스템 자원을 기반으로 시작된다?

Initial memory recommendation

• neo4j-admin memrec 명령으로 초기 권장량을 얻어서 사용하라
• 사용 사례에 맞게 memory 값을 조정할 필요가 있다.

 

위 예를 보면 lucene indexes는 6.7GB, data volume, native index는 17GB 인 상태. 이 정보를 이용해 memory configuration을 적용하라

Capacity Planning

Estimate page cache for a new Neo4j database

• 최대한 많은 data, index를 caching 하는 것이 좋다

• 위 예시는 data & index size: 35GB → pagecache size: 48GB

Configure query heap usage

• cypher query를 실행시키면 내부적으로 heap에 결과를 저장한다.
• query에 얼마나 많은 힙이 필요한지는 예측 어려움..
• query가 너무 많은 메모리를 사용하면 성능에 영향 & oom

2가지 heap 사용을 향상시킬 수 있는 방법

• dbms.track_query_allocation=true 를 통해 모든 cypher query의 heap 활용도를 추적할 수 있고 , CALL dbms.listQueries() 를 호출해 실행 중인 쿼리의 사용률을 볼 수 있다.

• dbms.logs.query.allocation_logging_enabled 조건으로 memory usage를 모니터해라 (query.log)

• cypher.query_max_allocations.size*는 각 query가 사용할 수 있는 memory 크기를 정한다. 이 limit에 도달하면 query 중지 됨