External Process Pool for Confluence Data Center
In Confluence Data Center we minimize the impact of particularly memory or CPU intensive actions by handling them in an external process pool, which is a seperate pool of processes, managed by Confluence. These processes (also known as sandboxes) can crash or be terminated, and will be restarted automatically by Confluence, without affecting the Confluence application itself.
On this page:
The external process pool currently handles the following actions:
- Document conversion (thumbnail generation for file previews)
- Exporting a space to PDF
The external process pool is only available for Confluence Data Center.
In Confluence Server, these actions are handled by Confluence, so the information on this page does not apply.
Memory requirements
You will need to make sure that Confluence has enough memory for the external process pool. In a clustered Data Center installation, you'll need to do this for each cluster node. The pool contains two processes (sandboxes) by default, so we recommend allowing an additional 2 GB on top of what is already required for Confluence (1 GB per sandbox).
If you increase the size of the external process pool, make sure each node has enough free memory to cater for the extra processes.
Configure the external process pool
In most cases the default values will be adequate, however system administrators can configure the external process pool using system properties. For example you may want to increase the size of the pool (the number of processes available), or increase the amount of memory a process can consume. Here are the main properties you may need to change:
- conversion.sandbox.pool.size
Use this property to increase the number of processes (sandboxes) in the pool. You'll need to allow additional memory on each node for each additional process. - conversion.sandbox.memory.limit.megabytes
Use this property to limit the amount of memory each process (sandbox) in the pool can consume.
See Recognized System Properties for a full description of these properties, including additional properties that can be used to fine-tune, or disable sandboxes for particular actions.
Monitor failed actions
When an external process (sandbox) is terminated, we'll write the following to the application log on that node:
2018-04-09 17:35:35 WARN [sandbox-terminator]
[impl.util.sandbox.DefaultSandbox] lambda$startTerminator$0 Request
has taken 33384ms exceeds limit 30000ms terminating sandboxThis will be followed by an Attempting to restart the sandbox message, the next time someone performs an action that uses the external process pool.
Note that the process is not immediatley restarted after termination, as we don't re-attempt failed actions. We wait for the next request to spin up a new sandbox process.