[Postfixbuch-users] AMAVIS-NEW: DB Berkeley Number of current locks?

[Egon Gruber]

Uwe Driessen schrieb:
> Egon Gruber schrieb:
>   
>>>       
>> Bin vollkommen derselben Meinung, aber trotzdem kann man evtl. ein wenig
>> höhere Grenzen nutzen, da es für die eingesetzte
>> Hardware kein Problem darstellen sollte.
>>     
>
> Nun ja das Problem scheint der Zeitfaktor auf deinem System zu sein und bei 95% Spam
> kannst du schätzungsweise mehr wie 60% durch die vorgeschlagenen Lösungen vermeiden.
> Ergo hat deine Maschine wesentlich weniger zu tun.
> Ergo reichen dann evtl. auch 20-40 Amavis und die kannst du dann ins Ram legen.
> Kommt drauf an was sonst noch auf der Kiste rennt bei 4 GB und ca. 40MB pro child sollte
> das bis 60 auch kein Problem darstellen.
> Ergo weniger Spam der angenommen wird weniger Daten in mysql weniger Zeit zum löschen.
>   
Falls man 60% des Spamtraffics mit den vorgeschalteten Lösungen 
vermeiden kann (und ich denke dies trifft zu), kann
ich die Amavisprozesse auf 20-40 minimieren und diese könnte ich dann 
ohne Probleme ins RAM legen.
Das einzige Frage/Problem ist nur, dass beim nächtlichen Löschvorgang 
der MySQL Daten (auch wenn nur mehr 10% sind)
eine kurzfristige Unterbrechung stattfindet und im Maillog sieht man 
folgende Meldungen "PRESERVING EVIDENCE" mit evtl. temporären Fehler.
Hinzu kommt, dass im TMP-Verzeichnis von Amavis dann diese Ordner 
bestehen bleiben und nicht automastisch aufgeräumt werden.
Somit hätte ich dann im RAM bald Platzprobleme!
Aber ich denke ich muss mit den SQL_Statements einiges testen bzw. 
vielleicht versuche ich es mal mit MySQL/InnoDB. Hat da vielleicht
jemand schon ein paar Erfahrungen gemacht?
Gibt es evtl. die Möglichkeit die "PRESERVING EVIDENCE" Meldungen und 
damit das dauerhafte Speichern der Files im TMP-Verzeichnis von Amavis
zu unterbinden?
Falls die DB mal eine Zeit lang nicht erreichbar wäre, hätte ich sehr 
viele "PRESERVING EVIDENCE" Meldungen und damit auch Speicherprobleme im 
RAM, falls ich
das TMP-Verzeichnis von Amavis im RAM hätte.



> Welche Mysql Version setzt du denn ein ?
>   
mysql-4.1.20. Vielleicht würde sich mit einem Update auf mysql-5 einiges 
verbessern?
> Da du auf die Tabelle per SQL Statement zugreifst sollte das kein Problem darstellen die
> Tabelle in das innodb format zu überführen.
> Und auch mysql kennt in den anderen tabellen das verzögerte speichern und löschen 
> Versuche es mal mit low_priorrity
> Oder schau dir truncate an, ist schneller wie delete from .. where.. aber nicht
> transaktionssicher 
>   
Da muss ich mir mal die verschiedenen Möglichkeiten anschauen und austesten!
>
>   
>> Auf alle Fälle werden ich aber wie auch von Dir vorgeschlagen in
>> nächster Zeit neue Filtermöglichkeiten an vorderster Stelle
>> implementieren, damit Amavis entlastet wird.
>> (postgrey und policyd-weight).
>>
>> Danke für die Infos!
>>     
>
>
> Mit freundlichen Grüßen
>
> Drießen
>
>   
Danke für die Antwort!
Servus,
Egon