We have for a long time, been using SSLogger to successfully log statistics on set attributes of a static set of models. Overnight the polling interval, of logged statistics, has gone from 5 minutes to 10, without making any changes to the SSLogger input sources, i.e.
What could be the reason for this?
If a large number of the logged models, have lost contact with Spectrum, the cost of polling retries and timeouts can be very high, per polling interval, in relation to polling threads available. The default values for polling parameters is 3 second timeouts, 3 retries and a 300 second polling cycle. After this SSLogger ignores the model, until the next polling cycle, so an unreachable device, has a 9 second cost per model, every 5 minutes. If 300 models polled by SSLogger are down (that are logging statistics every 5 minutes for example), then 9 threads will be used trying to reach the models that are down. In Spectrum 9.4, there are a maximum of 40 threads available for polling, which could amount o nearly 25% of available threads.
As a result of reduced resources, Spectrum would not be able to log all the required attributes in the 5 minute window.
This will affect all versions but environments on Spectrum 10.x will be less affected, than those of the same size on all versions prior to Spectrum 10.x.
We need to ensure that the large majority of models, polled by SSLogger, are contactable.
However it may not be possible to ensure that the large majority of models, polled by SSLogger, are always contactable , so a workaround would be to reduce the polling timeout value. This is only advisable if the network latency is low and the models responsive but a reliable environment could reduce this from 3 seconds to, as low as 0.3. and would need to be tested in each environment before using this as a workaround.
Please reference the "SSLogger" section of the documentation for more information.