Neo4j memory config for write intensive application

performance

(Shishal A) #1

In my neo4j machine I have limited memory but data/indexes easily exceed available memory.

Machine Physical RAM: 64G.

Output of bin/neo4j-admin memrec --database=graph.db

Based on the above, the following memory settings are recommended:

dbms.memory.heap.initial_size=24g
dbms.memory.heap.max_size=24g
dbms.memory.pagecache.size=28g

The numbers below have been derived based on your current data volume in database and index configuration of database 'graph.db'. They can be used as an input into more detailed memory analysis.

Lucene indexes: 47800m
Data volume and native indexes: 129600m

I am not sure I should be more generous with lucene memory or page cache for my scenario.

My application is more write intensive than read. With limited memory what should be recommended memory setting to make it biased towards write.


(Stefan Armbruster) #2

For most cases 24g heap is more than you really need. I'd start off with 16G heap and 40G for pagecache, leaving up 8G for the system itself.


(Shishal A) #3

Thanks Stefen, just one doubt, as far as i know lecune index is not part of memory which we assign for page cache and its the left over memory after page cache and heap which is used by lecune and system os. So is it fair to leave only 8gb for it(for wtite biased scenarios)


(Stefan Armbruster) #4

I've implicitly assumed you're on 3.4 which offers native indexes for almost every scenario. YMMV when being on previous versions.
You're right Lucene uses off-heap memory as well which is not controlled via pagecache size settings.


(Shishal A) #5

I have migrated from 3.2.5 to 3.4.7 along with data. and recreated index. But above memrec output still shows 47g of lucene index. is it normal that i still have 47g of lucene index?


(Shishal A) #6

To clear my doubt I have droped all indexs and ran bin/neo4j-admin memrec --database=graph.db

But it still shows 47g of lucene index. I am not sure why?


(Shishal A) #7

Sorry Its my mistake. Some obsolete data was still lying around with old index. Thanks Stefan for help.