Starting with the release of Strategy ONE (March 2024), dossiers are also known as dashboards.
This article outlines the following topics for troubleshooting the new server governing mechanism, prioritization:
During its operation, the Intelligence Server receives various types of requests, including time-critical ones (such as interactive Dossier manipulations) as well as background requests (such as Smart Download inquiries from Library on iOS). When the Server is busy, it is desirable to prioritize the processing and execution of the time-bound interactive requests over the background ones, so that the response time of the former requests can be maintained.
To prioritize execution and maintain the performance of interactive requests, Strategy 2020 Update 2 introduces a new automatic Server governing mechanism. The first part of this governing is to provide a throttling algorithm , which limits the number of background requests that are transformed into jobs. This way, jobs for interactive requests do not need to compete against too many background jobs for CPU and memory resources.
Once a request is accepted (not throttled) by the Server and transformed into a job, it will experience the following workflow: (1) the job will be decomposed into multiple tasks, (2) each job task is put into a processing unit (PU) queue, and then (3) every queue will be served by a PU thread. In order to maintain the response time of interactive requests, their workflow must be separated from that of the background requests. This is achieved by adding a new queue and a new thread pool, for each PU type that supports background requests. Furthermore, the job-processing workflow of the interactive requests must be executed with higher priority so that they can occupy a larger chunk of CPU time. Such a job prioritization algorithm, which is the second and integral part of Server’s new automatic governing mechanism, provides a larger CPU time chunk for interactive jobs by assigning their PU threads with lower OS-level scheduling priority (”
nice” value) in Linux and higher priority class in Windows. Note that, while in Windows the priority class is proportional to CPU time, in Linux the nice value has an inverse relation to CPU time (and priority). Since Intelligence Server employs a thread pool-based concurrency, the steps below are applied to ensure that each task and queue are assigned a PU thread with the correct priority level:
8in Windows and
0in Linux) before being returned into the pool.
Step 2 improves the response time of interactive requests under high system load, while the last “reset-to-default“ step ensures that the thread pool is always in an expected state before the next reuse, possibly by other Server workflows. This way, response time performance can be improved without affecting other workflows.
When not configured properly, however, job prioritization could not provide the promised performance benefits. This knowledge base provides a troubleshooting guideline for job prioritization to prevent this issue.
How to troubleshoot:
Symptom A: I-Server failed to start up
35 | 35 | 35 | 35 | 35 |
35 | 35 | 35 |
|
|
Symptom B: Degraded throughput for interactive jobs when there is a significant number predictive cache requests
|
|
|
|
|
|
|
| Applies to Strategy 2021 |
|
|
|
|
|
|
|
|
| Applies to Strategy 2021 | Job prioritization depends on two components: queue and thread prioritizations. These components are enabled by default, unless they are disabled from Registry. Here is an example when both components are disabled: [HKEY_LOCAL_MACHINE\SOFTWARE\MicroStrategy\DSS Server\Job Prioritization] "EnableThreadPrioritization"="NO" "EnableQueuePrioritization"="NO" |
|
|
| Note: On the other hand, the log file will contain the following entry when job prioritization is enabled: [Kernel][Info] The job prioritization feature is enabled. |
|
|
|
|
| Note: The settings above only modifies the maximum nice value for the mstr user, but should not affect other users. The followings are two special scenarios you should be aware of. |
|
|
|
|
|
|
|
|
|
|
|
|
| ... [Kernel][Job Trace] ... MSIJob::SetType: Set Job:1's type to (Interactive Job) | Ensure the deployed Strategy Library has a version of 11.2.0200.xxxx or newer. Strategy 2020 Hotfix 2 installer does NOT automatically deploy the new Library WAR file. The old WAR file lacks the attribute needed to identify and set the correct priority for predictive caching requests. If the problem persists, log a support ticket regarding this logical defect to Strategy Support team and attach the DSSErrors.log file. |
There may be several corner cases not covered by the troubleshooting workflow section above. In such case, the immediate action is to verify whether the job prioritization is working properly. This boils down to checking whether interactive (time-critical) and Smart Download (referred here as “predictive caching”) jobs are respectively assigned with the right priority level during execution, by performing the steps below.
DSSErrors.logcontains the following entries.
... [Kernel][Job Trace] ... MSIJob::MSIJob Job:1 created. ... ... [Kernel][Job Trace] ... MSIJob::SetType: Set Job:1's type to (Interactive Job)
1in this case), make sure there is no log entry that states it is set to (
Predictive Cache Job) type.
DSSErrors.login the steps below and must be done by disabling the predictive caching feature from Strategy Mobile and Library on iOS and Android. To do this, go to the “Smart Download” part of the “Options → Preferences” page and then select “Never” (see screenshot below).
curl -X POST "http://localhost:8080/consume/api/auth/login" -H "accept: application/json" -H "Content-Type: application/json" -d "{"username":"<user_name>","password":"<password>","loginMode":1,"maxSearch":3,"workingSet":10,"changePassword":false,"newPassword":"string","metadataLocale":"en_us","warehouseDataLocale":"en_us","displayLocale":"en_us","messagesLocale":"en_us","numberLocale":"en_us","timeZone":"UTC","applicationType":35}"
curl -X POST "http://localhost:8080/MicroStrategyLibrary/api/dossiers/<dossier_id>/executionResult?resultType=binary" -H "accept: /" -H "X-MSTR-AuthToken: <x_mstr_token_from_login>" -H "X-MSTR-ProjectID: <project_id>" -H "Content-Type: application/json" -d "{"include":[],"mobilePrecaching":true}"
DSSErrors.logthat indicates the predictive caching request is executed with the correct priority. In this example, the Job ID is
2. Note that the easiest way to verify the log entries is to make sure that there is no other running jobs other that the predictive caching request you triggered. This way, all the entries in
DSSErrors.logis solely due to your predictive request.
... [Kernel][Job Trace] ... MSIJob::MSIJob Job:2 created. ... [Kernel][Job Trace] ... MSIJob::SetType: Set Job:2's type to (Predictive Cache Job)
A more detailed step-by-step example to verify whether job prioritization works properly is given in the video below. Note that the video includes the steps to verify both job prioritization’s and job throttling’s functionalities. Thus, when viewing the video, our focus should be on checking the priority levels for accepted jobs, which happens at timestamp 4:54 for predictive caching jobs and 5:53 for interactive jobs.