[Eisfair] antispam stoppt nach einiger Zeit

[Rolf Bensch]

Hallo Marcus,

Am 17.10.23 um 10:41 schrieb 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.

Nunja, gab es denn in der Vergangenheit einen Fall der konkret auf eine Ursache zurückzuführen war? Soweit ich mich eingelesen habe, läuft der Speicher aus unerklärlicher Ursache voll bis der oom-killer zuschlägt. Lösung ist jeweils ein RAM-Update. Und diesen Sachverhalt kann ich bestätigen.

> 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.

Hier ist es immer und ausschließlich spamd der gekillt wird.

> Wäre dir der spamd-Dienst so wichtig oder könntest du auf ihn mal eine Weile
> verzichten?
Und auch den Speicher wieder zu reduzieren? Auf einem Server könnte ich das machen.
> Gab es in den damaligen Threads nicht auch einen Codeschnipsel, um den
> Speicherverbrauch über Zeit zu dokumentieren?

Das hatte ich im Frühjahr auch hier gemacht. Ich sah allerdings nur, dass der Speicher zuläuft, aber nicht, welches Tool dafür die Ursache war. Die Erkenntnis daraus war nicht zielführend.

Grüße

Rolf