Neo4j configuration
Neo4j is the Perforce IPLM database backend. Find the Neo4j configuration options.
Perforce IPLM-specific settings can be defined in the neo4j.conf file. These settings should be identical for all the Neo4j servers in a cluster. The Neo4j server must be restarted for a change in the settings to take effect. If an illegal value is specified for a setting, the Neo4j server startup will be stopped and an error will be logged in the Neo4j log file.
Perforce IPLM settings
| Setting | Description |
|---|---|
| mdx.repo_path_validation_enabled | This setting has moved to piserver.yml configuration file. |
| mdx.hook_script | This setting has moved to piserver.yml configuration file. |
| mdx.hook_execution_timeout | This setting has moved to piserver.yml configuration file. |
| mdx.hook_lock_wait_timeout | This setting has moved to piserver.yml configuration file. |
| mdx.pagination_cli_page_size |
This setting has moved to piserver.yml configuration file. |
| mdx.pagination_cli_concurrent_requests |
This setting has moved to piserver.yml configuration file. |
| mdx.user_session_last_access_timestamp_tolerance |
This setting is no longer used. |
| mdx.transaction_max_retries_entity_not_found |
This setting is no longer used. |
| mdx.transaction_max_retries_other |
This setting is no longer used. |
| mdx.transaction_retries_delay |
This setting is no longer used. |
| mdx.janitor_initial_delay |
This setting has moved to piserver.yml configuration file. |
| mdx.janitor_period | This setting has moved to piserver.yml configuration file. |
| mdx.file_list_compressor_threads |
This setting has moved to piserver.yml configuration file. |
| mdx.file_list_compressor_batch_size |
This setting has moved to piserver.yml configuration file. |
Useful Neo4j settings
| Setting | Type | Description | Default value |
|---|---|---|---|
| dbms.threads.worker_count | integer |
Number of Neo4j worker threads. Defines the size of the pool thread available to the database engine to execute queries. By default it is set to the number of cores the OS reports (so typically, 4-8 for low-end machines, 16-32 for beefier ones); up to 500, with the maximum custom value can be 40K+ . So that number is really a function of the CPU profile and workload. If the workload causes the DB engine to trigger queries that block; it makes sense to bump up the thread count so that work can be done by other threads. If the workload generates expensive queries that just take a long time to run and if your CPU is maxed out, then there is no point in bumping this up anymore and you just need to add another machine to the cluster or get a more powerful machine with more cores. Since those are threads, the memory accounting will happen towards the main java process, which should be auto-tuning; based on available memory in the system. |
number of cores |
Types of values
| Type | Description |
|---|---|
| boolean |
One of:
|
| integer | An integer number in decimal format |
| string | A string |