Essbase Kernel Is Multi-Threaded
By Ahmed Awan on Oct 24, 2011
Although it is documented in the Essbase Database Administration Guide (DBA Guide) that the Essbase kernel is multi-threaded and provides the foundation for a variety of Essbase functions, which includes data loading, calculations, spreadsheet lock and send, partitioning, and restructuring. The Essbase kernel also reads, caches, and writes data, manages transactions, enforces transaction semantics to ensure data consistency and data integrity. There still continues to be some confusion around the multi-thread capabilities of the Essbase kernel.
For the documented information on the Essbase Kernel, see the Essbase DBA Guide:
· Chapter 46. “Running Essbase Servers, Applications, and Databases”
· Chapter 49, “Managing Database Settings”
· Chapter 50, “Allocating Storage and Compressing Data”
· Chapter 51, “Ensuring Data Integrity”
· Chapter 55, “Optimizing Essbase Caches”
· Appendix D, “Estimating Disk and Memory Requirements”
It has been continually questioned if the Essbase kernel is in fact multi-threaded. This post is to help clarify this point and will hopefully clear up this misconception with the Essbase kernel and its multi-threaded capabilities.
The Essbase kernel has not been single threaded since the release of Essbase v6.5. Both the Block Storage (BSO) and Aggregate Storage (ASO) kernels are multi-thread capable. This is evident with the concurrent activities run by end users i.e. queries, HBR type calculations, batch type calculations, and data updates that are typical in a Planning (BSO) type applications or heavy queries demanded in Reporting (ASO) type applications.
The Essbase kernel does not do anything by itself to create multiple threads. AgentThreads and ServerThreads are set in the Essbase.cfg file based on design, process and end user volume. Normally, the ServerThread default setting of 20 threads is sufficient per application. The calculation command “SET CALCPARALLEL”, which is set in each calc script, inherently creates multi-threading inside the Essbase kernel. The Essbase kernel will service these requests concurrently and this is not a serialization point.
A caveat that can be misread that the Essbase kernel is serial is if the customer uses a slow I/O subsystem, especially an I/O subsystem that does not support parallel I/O capabilities. A slow IO subsystem that does not support parallel IO capabilities can be a bottleneck that will eventually serialize the concurrent operations, meaning the Essbase kernel is not the serialization point.
Another caveat that can be misread is if the volume of concurrent requests on the Essbase server exceeds the server resource capacity. It is important to do appropriate performance testing to be sure the expected design, process and end user volume does not exceed server capacity. If the volume of concurrent activities bombards the Essbase server, this can cause CPUs to contend and thrash negatively affecting performance.