Neo4J CE stability issues


(Skazazes) #1
  • Ubuntu 18.04
  • Neo4j: 3.5.3, Browser 3.2.16
  • Python driver
  • Algo's plugin
  • Due to numerous " Discarded stale query from the query cache after n seconds" the logs are littered with personal data

So I've been trying to start using Neo4J in a project, but have struggled to keep it stable and the server available for the passed few weeks. I am running the server within a VM running on ESXi, 8 vCPUs, and 6gb of ram, should be plenty from my understanding.

Seemingly unprovoked, the database goes unresponsive, and the whole OS locks up; the server can be idling, running queries via the python driver/dashboard, or even just trying to authorize a user via the dashboard. Open SSH sessions to the VM are left hanging, as well as the console view via the hypervisor. A full VM reset is required to regain access.

At first I was trying to user the version available through debian repositories, but ran into the stability issues and decided to download the provided tar and run it that way. The issues persisted. Next I tried pinning the VM memory figuring memory sharing may be at fault, but again no dice. Eventually I went into the DB configs and increased the memory to the max the VM has to spare but again, the problem persisted. That leaves me here, I'm really not too sure what to do, but have been enjoying the system while it does work but am frustrated.

The logs do not seem to show anything meaningful in the terms of the crashes, everything seems to hang silently as far as I can tell. I will try to start removing PII from them and post them but thought I would ask first.

Thanks for any help in advanced


(Andrew Bowman) #2

Regarding the PII, are you using parameters in your queries?

When a query is sufficiently parameterized, you should see far fewer query cache evictions, as the parameterized query only counts as a single query no matter how the parameters vary on invocation. The parameters shouldn't occur in cached query eviction messages either.

Additionally it protects you from potential Cypher injection.


(Skazazes) #3

I hadn't been, but have since moved to py2neo and am no longer seeing the PII in my logs. Thank you for the suggestion even still.

That being said the issue still persists and I have clean logs now

neo4j.log
debug.log

Again any help would be appreciated


(Andrew Bowman) #4

Sorry, nothing looks wrong in those logs. Does this really cover a period of lockup? If so, as there's nothing in the logs that looks out of place, it could be the VM itself and not Neo4j. We'd need something more to work with to be able to provide neo4j-specific advice, at least from my perspective.


(Skazazes) #5

It does.

I rebooted the VM after a crash, deleted the old logs entirely, started Neo, and waited for a crash which took <5 minutes. A tab was open to the dashboard in my browser from my last session that may have tried to reestablish a connection, but no connection was ever attempted via bolt.

I can successfully run a mysql server from the same VM for over a week without issue, which leads me to believe it's not directly at fault. Could Java potentially be the culprit? I'm looking through system logs now to see if there is anything valuable in them.


(Skazazes) #6

It seems downgrading to 16.04 from 18.04 has solved the issue for now. For the record, I had already tried a fresh install if 18.04 to no avail.

Thanks again for your suggestions