This is a causal cluster of 3 instances (1 leader, 2 followers).
Below are the :sysinfo data:
Store Sizes
Count Store
35.00 KiB
Label Store
279.29 KiB
Index Store
733.22 MiB
Schema Store
200.01 KiB
Array Store
595.73 MiB
Logical Log
38.95 MiB
Node Store
54.09 MiB
Property Store
643.38 MiB
Relationship Store
74.56 MiB
String Store
504.52 MiB
Total Store Size
2.93 GiB
ID Allocation
Node ID
3780265
Property ID
16441803
Relationship ID
2267527
Relationship Type ID
321
Page Cache
Faults
331005
Evictions
0
File Mappings
169
Bytes Read
2652192417
Flushes
14565
Eviction Exceptions
0
File Unmappings
120
Bytes Written
596435804
Hit Ratio
99.99%
Usage Ratio
84.51%
Transactions
Last Tx Id
61236362
Current
1
Peak
2
Opened
23740
Committed
23703
Pagecache and heap size config:
- dbms.memory.heap.initial_size: 5G
- dbms.memory.heap.max_size: 5G
- dbms.memory.pagecache.size: 3G
Hi Abed, long time no see 
Because that's your configuration:
5G heap + 3G pagecache = 8G
Depending on your operations that's what you need. the 3G pagecache maps the files from disk to memory.
And the heap is for ongoing operations and processing of your queries, you might be able to reduce the heap.
And because you have such a large string store which you hopefully don't access that often you could also get your pagecache down to 1G or so.
Michael my friend! Long time indeed I hope you've been doing well.
I was under the impression that pagecache should be similar or greater than DB size for some reason to keep performance well. As for decreasing heap size, would that have any impact on performance too?
Yes smaller heap and PC might have performance impacts, for the PC it depends which part of the graph is frequently accessed.
For heap it depends on the number of concurrent operations and how much each of those needs for computation.
Best to test it on your staging environment with realistic load testing if reduced numbers have much impact.