The Strategy Intelligence Server running on Linux uses file descriptors in many essential operations such as network connectivity, communication with the database connection processes, and storing cache and History List information disk.
For Strategy 9.x and above, there are a number of ways that the Strategy Intelligence Server configuration can be changed to reduce the usage of file descriptors. The main features which use file descriptors are:
- Database connections
- Network connections
- Cache files
- Inbox / History List files
- Log files
Database connections
The Strategy Intelligence Server process normally uses named pipes (which are abstracted as files in Linux) to communicate with the M8MulPrc processes which connect to the database. Each database connection is represented by a M8MulPrc process and may use several file descriptors per connection. To reduce the impact of database connectivity on file descriptors:
- Timeout database connections when they are not being used.
Normally, the Intelligence Server caches database connections for some amount of time to be reused for future queries: 1 minute idle time or 10 hours total connection lifetime, by default. This reduces the overhead involved in constantly connecting and disconnecting to the database. As long as the connections are cached, the server retains the file descriptors required to communicate with the M8MulPrc for the connection. These timeouts can be adjusted so the connections are cleared at a faster rate; when the connection is cleared the associated file descriptors and M8MulPrc process are discarded. The following Strategy Knowledge Base technical note has more information on this subject:
- KB5598: What are the "Connection lifetime" and "Connection Idle Timeout" options under the Database Connection Caching section in MicroStrategy Intelligence Server?
- Reduce the number of database connections.
Along with the explanation above with timeouts, the fewer database connections there are overall, the fewer M8MulPrcs and file descriptors necessary to communicate with them. The number of database connections can be reduced in the database instance, however this would potentially mean jobs will be queued while waiting for an open connection to the database. The following Strategy Knowledge Base technical note has more information on this subject:
- KB8486: What is Job Prioritization and Connection Management in MicroStrategy Intelligence Server 8.x and 9.x?
- Change to shared memory for interprocess communication with the M8MulPrcs (Strategy 9 only)
As stated above, normally the Intelligence Server uses named pipes to communicate with the M8MulPrcs. In Strategy 9, a new method of interprocess communication (IPC) was introduced which allows the server to use shared memory segments instead of named pipes for communication with the M8MulPrcs. This method reduces, but does not eliminate, the server's reliance on named pipes and consequently file descriptors for database communications. This feature does require use of system level semaphores. Refer to the following Strategy Knowledge Base technical note for more information on this new feature:
- KB30320: What are the operating system shared memory settings that a user is prompted for during the installation of MicroStrategy Intelligence Server Universal 9.x
Network connections
In Linux all network connections are abstracted as files, so each network connection to the Intelligence Server requires a file descriptor. For Strategy Desktop connections, there is a 1:1 relationship of users connecting with Strategy Desktop and network connections on the server. In Strategy Web and Strategy Web Services (Strategy Office), connection pooling is used to reduce the required number of network connections. With connection pooling the network connections are shared between the users accessing Strategy Web/Office. A connection is only in use when the user is making an active request to the Intelligence Server (logging in, browsing to a new folder, requesting a report execution). When the user is not active (for example reviewing a report or dashboard, or just has the session open but is not clicking anything), the connection is unused and can be used to service another user's request. In this way, a single network connection can potentially service multiple user sessions, though the exact number is dependent on a number of factors.
- Reducing the number of Strategy Web/Office connections
The Initial pool size and Maximum pool size settings in Strategy Web Administrator control the number of connections Strategy Web makes to the Intelligence Server. If the Strategy Web Initial pool and maximum pool sizes are set too high, it is possible to have file descriptors unnecessarilly consumed by Web network connections. Ideally both the initial and maximum pool sizes should be tuned to allow just enough connections to service the environment's user request; the exact number will depend on the number of users and their activity. If Web does not have any free connections when it needs to make a user request, it will open a new connection up to the maximum limit. If there are no free connections, the request will be queued until a connection is free.
Technical Support suggests only increasing the pool size settings when there is a significant slowdown in performance of Web or user requests start hitting the Web request timeout set in the Web Administrator properties.
For Strategy Office, the maximum connection pool size is controlled on the Web Services installation, in the ProjectSources.xml file. There is an entry MaxPooledConnections in the project source which controls the maximum pool size. By this is by default set to 100.
- Timing out Strategy Web/Office Connections (Strategy 8.1.1 Hotfix 3 and later)
Normally Strategy Web keeps all connections open once they have been pooled and does not time them out. In 8.1.1 Hotfix 3 a new feature was introduced to time out idle connections on the Intelligence Server. This can be used to cleanup idle connections; Web will simply reopen a connection if it sees a connection is no longer valid. Refer to the following Strategy Knowledge Base technical note for more information on this new feature:
- KB18556: When applying MicroStrategy Intelligence Server 8.1.1 Hotfix 3, client connections to the MicroStrategy Intelligence Server are lost before reaching the specified user session idle timeout settings
NOTE: This idle timeout should be set higher than both the user session and web user session idle timeouts in the server configuration to avoid users being disconnected unnecessarily.
Cache files
The Strategy Intelligence Server backs up all cache files to disk and must use file descriptors to access them. Note that the benefit of tuning this aspect of the system may not result in significant decreases in file descriptors, and may result in other performance penalties, as cache files are only accessed when the cache is actively being loaded, created, updated, or deleted.
The fewer overall caches on the system, the fewer the number of file descriptors that may be required to access them. This also means that fewer caches can exist for reports in the environment. The number of caches is controlled by project in the Project Configuration > Caching > Storage > Maximum number of caches setting.
Increasing the RAM used for cache will allow a greater number of caches to be loaded into memory at one time. This will reduce the cache swapping which must be performed when all the memory for cache is consumed and will reduce the number of file descriptors used for caching activity. The memory used for cache is controlled at the project level under Project Configuration > Caching > Storage > Max RAM usage setting.
The new Intelligent Cube feature in Strategy 9 allows the creation of large dataset caches stored on the Intelligence Server, which then have reports designed to hit them, much like a report cache. This will reduce the number of caching file descriptors, as the data is stored in one large cache instead of many smaller caches.
- Reducing the number of caches on the system
- Increasing the RAM used for cache
- Utilize Intelligent Cubes instead of report caches (Strategy 9 only)
Inbox/History List files
In 8.x and 9 the Strategy Intelligence Server stores History List messages in files on disk. These files are accessed when users log in in order to load the history list messages. They are also accessed when a message is retrieved, updated, or deleted.
In Strategy 9 a new feature of Database History List was introduced to store messages in a database instead. This would allow the Intelligence Server to use one database connection to service History List requests instead of requiring a file descriptor for each History List and message being accessed. The benefit of switching to Database History List may not be significant however, as the files are only accessed when the History information is being actively accessed or updated.
- Database History List (Strategy 9 only)
Log files
Any log files the server which is writing diagnostic/error information requires a file descriptor. Normally this is just the DSSErrors.log, however if additional logging is enabled, potentially for troubleshooting purposes, then a separate file descriptor is used for each log file.
