Memory consumption by the Dgraph

This topic discusses the logic used by the Dgraph to control its memory consumption.

The Dgraph query performance depends on characteristics of your specific deployment: query workload and complexity, the characteristics of the loaded records, and the size of the Dgraph database.

These statements describe how the Dgraph utilizes memory:

After the installation, when the Dgraph is started it allocates considerable amounts of virtual memory on the system. This is needed for ingesting data and executing queries, including those that are complex. This is an expected behavior and is observable if you use system diagnostic tools.
If the Dgraph is installed on a machine that is hosting other processes, other memory-intensive processes are present in the operating system and require memory. In this case, the Dgraph releases a significant portion of its physical memory quickly. Without such pressure, that is in cases when the Dgraph is the sole process on the hosting machine, the Dgraph may retain the physical memory indefinitely. This is an expected behavior.
Because of this, depending on your deployment requirements, such as the size of your deployment, it may be highly desirable to deploy the Dgraph instances on servers dedicated solely to each of the Dgraph processes (this means that these machines are not hosting any other processes, for BDD or other applications).
If your Dgraph databases are on HDFS, the Dgraph must be deployed on HDFS DataNodes, but this should be the only other process running on those servers. In particular, you shouldn't deploy the Dgraph on servers running Spark, which also requires a lot of memory. If you have to co-locate the Dgraph and Spark, you must use Linux cgroups to ensure the Dgraph has access to the resources it requires; for more information, see Setting up cgroups for the Dgraph.
By default, the memory limit that the Dgraph is allowed to use on the machine is set to 80% of the machine's available RAM. This behavior ensures that the Dgraph does not run out of memory on the machine hosting the Dgraph. In other words, with this limit in place, the Dgraph is protected from running into out-of-memory performance issues.
In addition to the default memory consumption limit of 80% of RAM, after the installation you can set a custom limit on the amount of memory the Dgraph can consume, using the Dgraph --memory-limit flag. If this limit is set, then, upon the Dgraph restart, the amount of memory required by the Dgraph to process all current queries cannot exceed this custom limit.

Note: The Dgraph --memory-limit flag is intended for Oracle Support. For information on how to set it, see Changing the Dgraph memory limit. Also, a value of 0 for the flag means there is no limit set on the amount of memory the Dgraph can use. In this case, you should be aware that the Dgraph will use all the memory on the machine that it can allocate for its processing without any limit, and will not attempt to cancel any queries that may require the most amount of memory. This, in turn, may lead to out-of-memory page thrashing and require manually restarting the Dgraph.
Once the Dgraph reaches a memory consumption limit (it could be the default limit of 80% of RAM, or a custom memory limit set with --memory-limit), it starts to automatically cancel queries, beginning with the query that is currently consuming the most amount of memory. When the Dgraph cancels a query, it logs the amount of memory the query was using and the time it was cancelled for diagnostic purposes.
In addition to the memory consumption limit, before you install Big Data Discovery, you can specify the Dgraph cache size, using the DGRAPH_CACHE property in the bdd.conf file located in your installation directory. The orchestration script uses this value at installation time. You can adjust the size of DGRAPH_CACHE later, at any point after the installation. For information, see Tips for setting the Dgraph cache size.
There is one additional consideration about the Dgraph cache that is useful to keep in mind, before you decide to adjust the cache size:
While the Dgraph typically operates within the limits of its configured Dgraph cache size, it is possible for the cache to become over-subscribed for short periods of time. During such periods, the Dgraph may use up to 1.5 times more cache than it has configured. It is important to note that the Dgraph does not expect to routinely reach an increase in its configured cache usage. When the cache size reaches the 1.5 times threshold, the Dgraph starts to more aggressively evict entries that consume its cache, so that the cache memory usage can be reduced to its configured limits. This behavior is not configurable by the system administrators.