Please, Dojo
I was wondering about possible checks (if any) to assess all the "SL*" DMA processes are correctly running when enabling jumbo frames on the acquisition interface of a DMA.
I'd normally check the trends for memory consumption on "SL*" processes where these are enabled.
Anything else I might have to consider?
Since Windows default settings are for 1500bytes, the change in subject would be:
1500-->9000.
Different cases might be present (in a general cluster):
1) when the DMA uses separate NICs for "Corporate" and "Acquisition";
2) when both Corporate & Acquisition rely on the same NIC;
3) whether NIC teaming (lbfoadmin) is enabled or not;
4) if 1+1 Fail-Over is configured or if the DMA is a single node;
Well spotted, Miguel – thank you
That post dates back to the original set-up in staging.
This newer post comes after observations on SLDataGateway, as described in
https://community.dataminer.services/question/sldatagateway-high-memory-consumption/
Hi Alberto,
can you confirm you have enough information with the previous community post?
There is however one side remark i also want to make, if you run our cloud service the processes start now with "DataMiner" since we need to distinct those from our SL* processes = core processes
These processes will also transfer data between servers, so it might be good to also have a look at those, however as Bert mentioned i would be surprised if the MTU change would have impact
Thanks for the additional info, Marlies – appreciated
From a core processes perspective (“SL*”), I’d agree that the the software kept running – but we had to significantly increase the thresholds on SLDataGateway (or the DMA element would be in alarm all the time) as the OS started to allocate much more memory after the switch to the increased MTU.
Before 10.2.10 (in 10.2.4), we had also to pre-emptively restart a few DMAs every now and then, to avoid sudden restarts in key hours.
At this point, we’re verifying with the squad as the affected cluster has a very specific set of configs: central agents provisioned with FO licenses and standard MTU size; remote agents with NIC teaming and increased MTU (where we spotted the memory leak) and no separate NIC for the acquisition interface.
Wondering also if we might find a trade-off between memory usage & Jumbo frames – all that is needed is to retrieve real time measurements, which might be a lot of data for some equipment but not too dissimilar from a standard CPE scenario.
Aiming also at clarifying the reason behind initial requirement for Jumbo Frames (mentioned in https://community.dataminer.services/question/differing-mtu-sizes-in-one-dms/ )
I’ll share an update for the community as soon as we find out more.
Hi Alberto,
I saw a similar question in the past:
https://community.dataminer.services/question/differing-mtu-sizes-in-one-dms/