[telemetry] Limit resource usage of ST and disable OOM killer

[yozhao101]

Signed-off-by: Yong Zhao yozhao@microsoft.com

Why I did it

Recently we observed the occurrence of memory spike in streaming telemetry due to the issues of gNMI client side. As such, we put a hard limitation on memory usage. At the same time, the OOM killer will be disabled in streaming telemetry container since OOM killer will panicked the kernel if OOM did happen.

In other words, if OOM occurs in streaming telemetry, we will depend on the Monit to catch this issue and restart the streaming telemetry container. So we have another open PR (#10008) to do this change on Monit scripts.

How I did it

I added several runtime parameters to limit the memory and CPU usage, also disabled the OOM killer in streaming telemetry.

How to verify it

I verified this change on DuT str-msn27000-20.

Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• [ x] 202012
• 202106
• 202111

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

[liuh-80]

Please make sure this scenario does not happen:

1. the memory_checker seems running inside telemetry docker, and the threshold is 400m: https://github.com/sonic-net/sonic-buildimage/blob/master/dockers/docker-sonic-telemetry/base_image_files/monit_telemetry

2. if memory_checker run first time check and current memory is 390m, memory_checker passed. memory_check will check 1 minute later.

3.  then before memory next time run, telemetry use more than 450M memory.

4. because can't allocate memory, memory_checker failed. telemetry container can't start again, telemetry container will hang there and memory will never release.

https://docs.docker.com/engine/reference/run/#user-memory-constraints

[FengPan-Frank]

With #19179, we're using monit to monitor runtime memory usage of docker, @qiluo-msft do we still need this docker hard limit as double insurance?

[qiluo-msft]

Seems dangerous to merge this feature. If slow memory lead happens in telemetry container, we still need telemetry functionality to detect the memory issue, instead of break telemetry feature. so block this PR.