[Eisfair] antispam stoppt nach einiger Zeit

[Marcus Röckrath]

Hallo Rolf,

Rolf Bensch wrote:

>> Kann du im Archiv bei Google mal nach oom-Kiler oder so suchen und
>> schauen, ob das dort auf einigen wenigen Maschinen aufgetretene Probleme
>> mit deinem vergleichbar ist?
> 
> Die Threads sind dort mindestens 3 Jahre alt. Danach hatte offensichtlich
> niemand mehr ein Problem damit. Soweit ich das jetzt durchforstet habe,
> konnte man keine konkrete Ursache ermitteln und suchte nach
> Analyse-Möglichkeiten.

Mir ging es darum, ob du eventuell eine der damaligen Beobachtungen exakt
bestätigen kannst.

Mit vereinzelt auftretenden Problemen ist die Ursachenforschung meist sehr
schwierig und auch die Suche nach oom-Killer im Internet gibt nur ein sehr
difuses Bild ab.

>> Wenn der oom-Killer laufende Programme killt, muss das nicht der
>> Verursacher sein, sondern der Versuch des Kernels irgendwie wieder an Ram
>> zu kommen.
> 
> Dass es hier keine Rückschlüsse auf Antispam zu ziehen sind, hatte ich
> bereits geschrieben. Allerdings ist hier die Häufigkeit, dass spamd
> gekillt wird, auffällig. Andere Prozesse waren in jüngster Zeit nicht mehr
> betroffen.

Oder es ist halt der Prozess, der nach Abwägung des Kernels eventuell
verantwortlich sein könnte:

[Zitat]
The function select_bad_process() is responsible for choosing a process to
kill. It decides by stepping through each running task and calculating how
suitable it is for killing with the function badness(). The badness is
calculated as follows, note that the square roots are integer
approximations calculated with int_sqrt();

badness_for_task = total_vm_for_task / (sqrt(cpu_time_in_seconds) *
sqrt(sqrt(cpu_time_in_minutes)))

This has been chosen to select a process that is using a large amount of
memory but is not that long lived. Processes which have been running a long
time are unlikely to be the cause of memory shortage so this calculation is
likely to select a process that uses a lot of memory but has not been
running long. If the process is a root process or has CAP_SYS_ADMIN
capabilities, the points are divided by four as it is assumed that root
privilege processes are well behaved. Similarly, if it has CAP_SYS_RAWIO
capabilities (access to raw devices) privileges, the points are further
divided by 4 as it is undesirable to kill a process that has direct access
to hardware.
[/Zitat]

Mit meinen Englischkenntnissen lese ich daraus, dass ein Prozess mit viel
Speicherverbrauch aber kurzer Laufzeit ein hohe Priorität als Verursachen
bekommt und dann ein Kill-Kandidat wird.

Nach meiner Erinnerung der damaligen Probleme, wurden nach und nach teils
auch immer neue Programme gekillt, was zumindest zeigt, dass die Heuristik
da wohl den "Bösewicht" nicht erkannt haben kann.

Wäre dir der spamd-Dienst so wichtig oder könntest du auf ihn mal eine Weile
verzichten?

Gab es in den damaligen Threads nicht auch einen Codeschnipsel, um den
Speicherverbrauch über Zeit zu dokumentieren?

> Ihm Rahmen eines Backup wird der Mailserver jeden 3. Tag neu gestartet.
> Mit dem Speicherupdate auf 8GB komme ich damit über die Runden. Ideal ist
> das aber nicht - und war vor dem systemd-Update definitiv anders.

Zumindest scheint es aber kein systemisches Problem zu sein, da systemd
inzwischen auf den meisten eisfair-Installationen aktiv sein dürfte und
auch spamd mehrfach eingesetzt werden dürfte, wenn ich mir für antispam die
Downloadstatistik anschaue (wenn sie auch durch Jäger und Sammler
verfälscht sein kann).

Vielleicht können sich auch mal andere eisfair-Nutzer kurz melden, wenn sie
antispam einsetzen.

-- 
Gruß Marcus
[eisfair-Team]