You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Over time, the syndic process grows in memory until all memory is exhausted and the syndic gets OOM-killed.
This syndic processes a lot of events, forwarding anywhere from 150-600 at a time (discovered through adding some debug logging to salt.minion.SyndicManager._forward_events()).
I have used a few profilers to discover where memory is being allocated, and they all point to msgpack. Here's the relevant part of the summary from running the syndic using scalene:
There is nothing special about the syndic configuration. The syndic_master is configured with the IP of the master-of-masters, and order_masters is set to True. The master running on the syndic is using the default number of worker threads (5).
The box is running under KVM virtualization, with Salt installed via pip.
Versions Report
Salt: 3006.5Python Version:
Python:3.9.2 (default, Feb 28 2021, 17:03:44)Dependency Versions:
cffi:1.16.0cherrypy:unknowndateutil:2.8.1docker-py: Not Installed
gitdb:Not Installedgitpython:Not InstalledJinja2:3.1.3libgit2:Not Installedlooseversion:1.3.0M2Crypto:Not InstalledMako:Not Installedmsgpack:1.0.0msgpack-pure: Not Installed
mysql-python: Not Installed
packaging: 24.0pycparser: 2.21pycrypto:Not Installedpycryptodome:3.20.0pygit2:Not Installedpython-gnupg: Not Installed
PyYAML:5.3.1PyZMQ:25.1.2relenv:Not Installedsmmap:Not Installedtimelib:Not InstalledTornado:4.5.3ZMQ:4.3.4System Versions:
dist:debian 11 bullseyelocale:utf-8machine:x86_64release:5.10.0-28-amd64system:Linuxversion:Debian GNU/Linux 11 bullseye
The text was updated successfully, but these errors were encountered:
Description
Over time, the syndic process grows in memory until all memory is exhausted and the syndic gets OOM-killed.
This syndic processes a lot of events, forwarding anywhere from 150-600 at a time (discovered through adding some debug logging to
salt.minion.SyndicManager._forward_events()
).I have used a few profilers to discover where memory is being allocated, and they all point to msgpack. Here's the relevant part of the summary from running the syndic using scalene:
Setup
There is nothing special about the syndic configuration. The
syndic_master
is configured with the IP of the master-of-masters, andorder_masters
is set toTrue
. The master running on the syndic is using the default number of worker threads (5).The box is running under KVM virtualization, with Salt installed via pip.
Versions Report
The text was updated successfully, but these errors were encountered: