Danke für das Feedback.

Wir werden die UUID überprüfen und auf Neuigkeiten zum Speicherleck warten.

Hallo.

Auf den betreffenden VMs läuft Folgendes: 2.4.0.14143-9847ee8b-debian-12-amd64.
Ich kenne den Server nicht; ich frage nach.

Auf einer der VMs, die ich gestern erwähnt habe (die mit dem 3-GB-Prozess), wurde gestern RAM hinzugefügt (die VM wurde also neu gestartet).
# ps -p 765 -o etime
ELAPSED
16:00:46 ...

Und noch eine weitere Methode, die 3 GB in VmSize ergibt:
# cat /proc/1152862/status
Name: waptservice
Umask: 0022
State: S (schlafend)
Tgid: 1152862
Ngid: 0
Pid: 1152862
PPid: 1
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 128
Groups:
NStgid: 1152862
NSpid: 1152862
NSpgid: 1152862
NSsid: 1152862
VmPeak ...

Eine andere Perspektive (oben) für das erste (3 GB):

Hallo,

hier sind ein paar weitere Details zu dem, was ich gesehen habe.

Für die VM mit 2 GB und etwas mehr:
# pmap -x 1152862
1152862: waptservice
Adresse Kbytes RSS Dirty Mode Mapping
.../... musste abgeschnitten werden, um es posten zu können
---------------- ------- ------- -------
Gesamt kB 2498900 1188768 1178376

Und für die ...

Hallo zusammen,

ich habe einen Kunden, der WAPT zur Verwaltung seiner Workstations und Server (VMs) nutzt.
Er verwendet Windows (Workstations und Server), Ubuntu (18.04 bis 22.04), Debian (12) und CentOS (7).

Wir haben festgestellt, dass der WAPT-Client (waptagent 2.4.0) auf einigen Linux-VMs mehrere...