Hello All,
We are interested in implementing a custom ProcessOptions config within the dataminer.xml file to better allocate protocol and scripting resources on the DMS. The DMS is currently using the default options.
The DMS is comprised of 4 DMAs. There are only a couple main protocols in use (Microsoft Platform, UPS collector).
There are ~40 collectors that each create up to 250 DVEs resulting in ~10k total UPS.
Given the small number of protocols in use but the large use of the collector protocol, we would like to configure the ProcessOptions to spread the load of this particular protocol over many processes.
After reviewing the potential options located in Docs (Configuring DataMiner processes | DataMiner Docs), we believe the option “Configuring a separate SLScripting process for each SLProtocol process” is the best option for this DMS where it states:
- “In a system where the load for one particular protocol has to be spread over several processes, because otherwise too much memory would be needed for one process, it can be useful to have a dedicated SLScripting process created for each SLProtocol process“
Is this assessment of our options correct?
If so, how should we determine the number of protocolProcesses to configure in the xml?
- “set the protocolProcesses attribute to a fixed number and the scriptingProcesses attribute to “protocol”“
Thank you in advance,
Thomas Rich
Hi Thomas,
Typically the default options should work fine. You do although have a special case where you indeed have an atypical load on a DMS…
That being said, we typically only have to tweak the number of processes if we run in to resource problems to manage everything in one process. E.g. 4 GB memory limit in the 32 bit SLProtocol. And now we also have by default SLProtocol in 64 bit since one of our latest release. So, I’m wondering why you are considering to tweak the number of processes? Do you run into any limitation of a process?
Note the the load (memory or CPU) won’t be lower by spreading this over more or less processes.
Bert
I agree, the root cause is probably not related to the number of processes.
Thank you for the reply Bert. Following your guidance, I checked the current load of the processes on the default config and they are not near the 4GB memory limit. With that information, it probably doesn’t make sense to adjust the config if it is not truly needed.
The suggestion to modify the config was an outcome from an observation of slow element performance, but given these findings, the root cause may be unrelated.