We are interested if the default time that Windows waits for a process to end before terminating is long enough or not. This comes after one of our EPM Lab systems experienced an issue following a server restart and we question if it would have been a problem had everything shutdown from the dataminer perspective gracefully. Windows event log indicate a server restart was initiated and we see from Dataminer the alarm attached below.
There is a registry key that determines how long the server should wait after a request to restart and the default setting is very low in my opinion @ 5 seconds.
Is there a recommendation or a known value we could set this for to ensure everything is gracefully restarted naturally via the OS?
Path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control
Key: WaitToKillServiceTimeout
Hi Shawn,
I believe the time needed to gracefully close the services might depend on the load on your systems and the HW you are using. I don’t have statistics on all systems. In general, most systems stop under one minute. If you want to measure this on your system to have a more ideal setting, you can open up the task manager and look at how long it takes for the SL* processes to disappear after initiating the DataMiner stop.
Hi Shawn,
Working with different EPM systems, so far we didn’t have to modify the registry setting to increase the timeout. In EPM I-DOCSIS solution, we include an extra step in our maintenance procedure which is stopping the elements that contributes the most with the load of the DMAs (before to restart the DMA).
Hope it helps.
Hi Shawn,
In general, my recommendation would be not to touch this registry setting unless there is a clear reason to change this.
EPM systems might be a special case and host huge collector or frontend/backend elements, but even then I don’t immediately see a reason why stopping the DataMiner processes abruptly during an OS restart would cause an issue… But I could be missing something of course, and then increasing that time might indeed help out.
Bert
Thanks Michiel! We’ll take this away and let you know if there are further questions.