English (Español a continuación)
Essbase can run calculations in two ways:
- Sequential calculation: it is the one that applies by default: the calculation is executed sequentially following the order of the calculation script.
- Parallel calculation: Essbase divides each calculation operation into subtasks that it executes independently and simultaneously, being able to execute up to 64 operations (on 32-bit platforms) or 128 operations (on 64-bit platforms) in parallel.
As a general rule, parallel computation is more efficient than sequential computation.
- The parallel calculation is only executed if the “Uncommitted Access” procedure is activated.
1.-CALCPARALLEL
Parallel calculation can be activated:
a) In the configuration file “essbase.cfg”, using the command:
- CALCPARALLEL [application name [database name]] n
The application name is optional: if this setting is not included it will apply to all applications.
If an application name has been specified, a database name may or may not be included: if this setting is included it will apply exclusively to that database; if it is not included it will be applied to all databases in the application.
“n”: number of parallel threads to be used.
When the configuration file is modified, the server must be restarted.
b) In a calculation script, using the command:
- SET CALCPARALLEL n;
“n”: number of parallel threads, for example: SET CALCPARALLEL 4;
- The value assigned in the SET CALCPARALLEL command prevails over the value assigned in the configuration file.
Whether it is activated in the configuration file or in a calculation script, the values that “n” can take:
- Between 1 and 64 on 32-bit platforms.
- Between 1 and 128 on 64-bit platforms.
The number of threads recommended by Oracle are:
- 32-bit server (8 cores): 8 lines
- 64-bit server (16 cores): 8 lines
- 64-bit server (32 cores): 8 lines
In any case, it is recommended to assign a number of threads at least one below the number of available processors (cores), leaving a free processor for the operating system or for other processes carried out by Essbase.
- It is important to carry out a test to analyze if the selected number optimizes the calculation.
- From a certain number of threads, the gains in efficiency are very small. Even too many can negatively affect efficiency.
Although parallel calculation is enabled, it may happen that in some phases of the calculation Essbase cannot apply it switching to sequential calculation (this is reflected in the log).
- In complex formulas, for example in formulas with circular references (A depends on B; B depends on C; C depends on A).
In the log you can check the number of operations that have been carried out in parallel:
- Calculation task Schedule [120,23]: Indicates that 120 calculations have been performed in parallel followed by 23 calculations in parallel.
On the other hand, there is a command in the essbase.cfg configuration file “MAXACTIVEUPDATETRANSACTIONS n” that sets the maximum number of operations that can simultaneously update data.
- If the parameter “n” set for the parallel calculation is greater than the limit set in this command, this limit takes effect.
2.- TASKS
To determine the subtasks in which a calculation is divided, Essbase dynamically selects the sparse dimensions that maximize the efficiency of the calculation (starting with the last one in the Outline and in ascending order).
- The potential number of tasks is calculated by multiplying the number of storage members of the sparse dimensions selected for the task calculation.
- For this reason, it is important to place the sparse dimension with the largest number of members as the last dimension of the Outline, to increase the number of potential sub-tasks.
- The automatic selection of dimensions carried out by Essbase is usually optimal.
You can also force Essbase to use a certain number of sparse dimensions (starting with the last one in the Outline) using the SET CALCTASKDIMS command.
- SET CALCTASKDIMS “n”; (Being “n” an integer that indicates the number of sparse dimensions that it must use to identify the sub-tasks that it can perform in parallel).
- This command should only be used if the dynamic selection carried out by Essbase generates many empty tasks (information that is recorded in the log), reducing the efficiency of the parallel calculation.
- With this command you can force Essbase to increase the number of sparse dimensions, substantially increasing the potential number of sub-tasks and reducing their size.
- The parameter assigned to this command must be tested: it may happen that an excessive increase in the potential number of sub-tasks negatively affects the efficiency level.
It is essential, therefore, to analyze the number of empty subtasks; if this is very high, the parallel calculation loses efficiency.
- The % of empty tasks must not exceed 40% of the total identified tasks.
- You can play with the order of the dimensions in the outline and with the CALCTASKDIMS command to try to reduce the number of empty tasks.
The command “SET CALCDIAGNOSTICS {LOGSIZE n;};” provides statistical information on the «n» longest running tasks performed by the parallel computation.
3.- THREADS
User sessions use «application threads» (the «threads» are tasks of the same process that can be executed simultaneously).
- Each transaction (calculation, queries…) uses 1 “application thread”.
These values can be modified with the SERVERTHREADS command in the essbase.cfg configuration file.
Its structure is:
- SERVERTHREADS [application name] n
[application name]: is optional; including an application name implies that this parameter will only affect that application; if it is not included it will affect all applications.
“n”: is the maximum number of threads that an “application process” (ESSSVR) can use and can take the following values:
- 32-bit platforms: 20 to 500
- 64-bit platforms: 20 to 1024
Its default value is 20.
Regardless of the maximum values, the actual number that an operating system can handle may be significantly less.
Each «application thread» can create subthreads for tasks such as parallel computation, parallel data loading, parallel export and parallel restructuring, but if the total number of threads is too high they can lose effectiveness.
Another parameter that needs to be defined is WORKERTHREADS.
- This command determines the size of the thread pool that Essbase can use when performing parallel operations (calculation, data loading, data exports, restructuring…).
This parameter is defined in the configuration file essbase.cfg
Its structure is:
- WORKERTHREADS [application name] n
[application name]: is optional; including an application name implies that this parameter will only affect that application; if it is not included it will affect all applications.
Its default value is half the size set in the SERVERTHREADS.
It is important to establish its value because if the default value is applied (half the size of SERVERTHREADS), and the latter has not been set either and its default value (20) also comes into action, it implies that the pool of threads to execute tasks in parallel it would be limited to 10:
- If, for example, 2 parallel calculations coincide, each which 8 threads (a total of 16 threads), the number of threads that could be used is only 10.
To establish the appropriate number, you have to take into account the resources of the server and the parallel tasks that are executed, and above all you have to do tests by trying different values to approximate the optimal one.
Some recommended values (although it depends, among other factors, on the type of platform 32 or 64 bit, and the number of processors).
- SERVERTHREADS: 100
- WORKERTHREADS: 50
Any question, please send an email to: essbaseeasy@gmail.com
Essbase puede ejecutar los cálculos de dos formas:
- Cálculo secuencial: es el que aplica por defecto: el cálculo se ejecuta secuencialmente siguiendo el orden del script de cálculo.
- Cálculo paralelo: Essbase divide cada operación del cálculo en subtareas que ejecuta independientemente y de forma simultánea, pudiendo ejecutar en paralelo hasta 64 operaciones (en plataformas 32 bits) o 128 operaciones (en plataformas 64 bits).
Por regla general, el cálculo paralelo es más eficiente que el cálculo secuencial.
- El cálculo paralelo sólo se ejecuta si se tiene activado el procedimiento “Uncommitted Access”.
1.- CALCPARALLEL
El cálculo paralelo se puede activar:
a) En el fichero de configuración “essbase.cfg”, mediante el comando:
- CALCPARALLEL [nombre de aplicación [nombre de base de datos]] n
El nombre de la aplicación es opcional: si no se incluye esta configuración se aplicará a todas las aplicaciones.
Si se ha indicado un nombre de aplicación, se puede incluir o no un nombre de base de datos: si se incluye esta configuración se aplicará exclusivamente a esa base de datos; si no se incluye se aplicará a todas las bases de datos de la aplicación.
“n”: número de líneas (threads) en paralelo que se van a utilizar.
Cuando se modifica el fichero de configuración hay que reiniciar el servidor.
b) En un script de cálculo, mediante el comando:
- SET CALCPARALLEL n;
“n”: número de líneas paralelas, por ejemplo: SET CALCPARALLEL 4;
- El valor asignado en el comando SET CALCPARALLEL prevalece sobre el valor asignado en el fichero de configuración.
Tanto se active en el fichero de configuración como en un script de cálculo, los valores que puede tomar “n”:
- Entre 1 y 64 en plataformas 32-bit.
- Entre 1 y 128 en plataformas 64-bit.
El número de líneas recomiendo por Oracle son:
- Servidor 32-bits (8 cores): 8 líneas
- Servidor 64-bits (16 cores): 8 líneas
- Servidor 64-bits (32 cores): 8 líneas
En todo caso se recomienda asignar un número de líneas al menos una por debajo del número de procesadores disponibles (cores), dejando un procesador libre para el sistema operativo o para otros procesos que realiza Essbase.
- Es importante, realizar test para analizar si el número seleccionado optimiza el cálculo
- A partir de cierto número de threads las ganancias en eficiencia son muy reducidas. Incluso a partir de cierto número la eficiencia se puede resentir.
Aunque el cálculo paralelo esté habilitado puede ocurrir que en algunas fases del mismo Essbase no lo pueda aplicar pasando al cálculo secuencial (esto queda reflejado en el log).
- En fórmulas complejas, por ejemplo en fórmulas con referencias circulares (A depende de B; B depende de C; C depende de A).
En el log se puede consultar el número de operaciones que se han realizado en paralelo:
- Calculation task Schedule [120,23]: indica que se han realizado 120 cálculos en paralelo seguido por 23 cálculos en paralelo.
Por otra parte, hay un comando en el fichero de configuración essbase.cfg “MAXACTIVEUPDATETRANSACTIONS n” que fija el máximo de operaciones que simultáneamente pueden estar actualizando datos.
- Si el parámetro “n” fijado para el cálculo paralelo es superior al límite establecido en este comando, este límite entra en vigor.
2.- TAREAS
Para determinar las subtareas en las que se divide un cálculo Essbase selecciona dinámicamente las dimensiones dispersas que maximizan la eficiencia del cálculo (empezando por la última del Outline y en orden ascendente).
- El número potencial de tareas se calcula multiplicando el número de miembros de almacenamiento de las dimensiones dispersas seleccionadas para el cálculo de tareas.
- Por ello es importante situar como última dimensión del Outline la dimensión dispersa con mayor número de miembros, para incrementar el número de sub-tareas potenciales.
- Normalmente la selección automática de dimensiones que realiza Essbase suele ser óptima.
También se puede forzar a Essbase a utilizar un determinado número de dimensiones dispersas (empezando por la última del Outline) mediante el comando SET CALCTASKDIMS.
- SET CALCTASKDIMS “n”; (Siendo “n” un número entero que indica el número de dimensiones dispersas que debe utilizar para identificar las sub-tareas que puede realizar en paralelo).
- Se debe utilizar este comando únicamente si en la selección dinámica que realiza Essbase se generan muchas tareas vacías (información que queda recogida en el log), reduciendo la eficiencia del cálculo paralelo.
- Con este comando se puede forzar a Essbase a que aumente el número de dimensiones dispersas, incrementando sustancialmente el número potencial de sub-tareas y reduciendo el tamaño de estas.
- El parámetro asignado a este comando hay que testarlo con pruebas: puede ocurrir que un incremento excesivo en el número potencial de sub-tareas afecte negativamente al nivel de eficiencia.
Es fundamental, por tanto, analizar el número de subtareas vacías; si este es muy elevado el cálculo en paralelo pierde eficacia.
- El % de tareas vacías no debe supera el 40% del total de las tareas identificadas.
- Se puede jugar con el orden de las dimensiones en el outline y con el comando CALCTASKDIMS para intentar reducir el número de tareas vacías.
El comando “SET CALCDIAGNOSTICS {LOGSIZE n;};” facilita información estadística sobre las “n” tareas de mayor duración realizadas por el cálculo paralelo.
3.- THREADS
Las sesiones de los usuarios utilizan “application threads” (las “threads” son tareas de un mismo proceso que pueden ser ejecutadas simultáneamente).
- Cada transacción (cálculo, consulta, actividades de administración…) utiliza 1 “application thread”.
Estos valores se pueden modificar con el comando SERVERTHREADS en el fichero de configuración essbase.cfg.
Su estructura es:
- SERVERTHREADS [nombre aplicación] n
[nombre aplicación]: es opcional; si se incluye un nombre de aplicación implica que este parámetro tan sólo afectará a dicha aplicación; si no se incluye afectará a todas las aplicaciones.
“n”: es el número máximo de threads que puede utilizar un “application process” (ESSSVR) y puede tomar los siguientes valores:
- Plataformas 32-bit: 20 a 500
- Plataformas 64-bit: 20 a 1024
Su valor por defecto es 20.
Con independencia de los valores máximos, el número real que un sistema operativo puede gestionar puede ser sensiblemente menor.
Cada “application thread” puede crear subthreads para tareas como calculo paralelo, carga de datos en paralelo, exportación en paralelo y restructuración en paralelo, pero si el número total de threads es muy elevado pueden perder efectividad.
Otro parámetro que hay que definir es WORKERTHREADS.
- Este comando determina el tamaño del pool de threads que Essbase puede utilizar cuando ejecuta operaciones en paralelo (calculo, carga de datos, exportaciones de datos, reestructuraciones…).
Este parámetro se define en el fichero de configuración essbase.cfg
Su estructura es:
- WORKERTHREADS [nombre aplicación] n
[nombre aplicación]: es opcional; si se incluye un nombre de aplicación implica que este parámetro tan sólo afectará a dicha aplicación; si no se incluye afectará a todas las aplicaciones.
Su valor por defecto es la mitad del tamaño fijado en el SERVERTHREADS.
Es importante establecer su valor ya que si se aplica el valor por defecto (mitad del tamaño del SERVERTHREADS), y este último tampoco se ha fijado y entra en acción también su valor por defecto (20) implica que el pool de threads para ejecutar tareas en paralelo quedaría limitado a 10:
- Si, por ejemplo, coincidieran 2 cálculos paralelos en los que se han fijado 8 threads en cada uno de ellos (un total de 16 threads) el número de threads que podrían utilizar es tan sólo de 10.
Para establecer el número conveniente hay que tener en cuenta los recursos del servidor y las tareas en paralelo que se ejecutan, y sobre todo hay que hacer tests probando diversos valores para aproximar el valor óptimo.
Algunos valores recomendados (aunque depende, entre otros factores, del tipo de plataforma 32 o 64 bit, y del número de procesadores).
- SERVERTHREADS: 100
- WORKERTHREADS: 50
Cualquier consulta envía, por favor, un correo a: essbaseeasy@gmail.com
ESSBASE EASY 