PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Gelöst Avast Security für Linux parallelisieren



furban
21.04.15, 09:22
Hi,
seit gestern habe ich nun Avast auf einem Server am laufen.

Was mir aufgefallen ist:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2653 avast 20 0 798136 131092 119560 S 33.1 0.1 25:52.27 avast
713 root 20 0 146276 69612 67152 S 5.0 0.1 1:56.84 systemd-journal
37449 amavis 20 0 240676 43900 2884 S 4.0 0.0 0:01.27 /usr/sbin/amavi
39657 amavis 20 0 240400 43656 2864 S 4.0 0.0 0:00.34 /usr/sbin/amavi
39745 amavis 20 0 240528 43728 2868 S 4.0 0.0 0:00.29 /usr/sbin/amavi
34213 amavis 20 0 240524 43820 2904 S 3.3 0.0 0:01.22 /usr/sbin/amavi
38307 amavis 20 0 240640 43852 2876 S 3.3 0.0 0:01.61 /usr/sbin/amavi
39963 amavis 20 0 240396 43668 2880 S 3.3 0.0 0:00.26 /usr/sbin/amavi

Es sieht also so aus als ob nur ein Avast Daemon läuft und der dann auch nur eine CPU nutzt
Kann man da mehrere Daemons starten? Oder das irgendwie anders parallelisieren?

Gruß

Frank

Merlin
21.04.15, 12:20
Hallo,

nutzt der Daemon denn dauerhaft so viel CPU oder ist es abhängig von der Auslastung auf dem Server (eingehende Mails, Änderungen auf der Festplatte,...)? Welche Version der Avast Security Suite für Linux nutzt du?

furban
21.04.15, 14:21
avast-1.2.0-1.x86_64

Eingebunden in Amvisd

Das ist abhängig von der Auslastung.
Das ist eine reines Mailrelay wo einiges an Traffic drüber geht. Die Maschine hat 40 Kerne und 132Gbyte. Das ist also schon eini wenig Power dahinter. Schade wenn dann Avast nur auf einem Kern läuft, wärend Amavis 100 Prozesse parallel am laufen hat.

tumic
21.04.15, 20:32
Hi,
Avast ist "multithreaded", es kann also mehrere CPUs benutzen. Generell kann man sagen
das per eine UNIX socket Verbindung eine CPU asgenutzt werdenn kann (die Verbindung wird
im eigenen Thread behandelt). Mit anderen Worten jedes prallel laufendes "scan" Process
kann theoretisch (hängt von dem pthreads Scheduler ab) auf einem eigenem CPU laufen.

M.

furban
22.04.15, 11:50
Soweit die Theorie....
Leider sehe ich im top aber immer nur einen Avast Thread der immer nur auf einem Kern arbeitet und diesen bis zu 70% auslastet, wärend die restlichen Prozesse auf dem Server maximal mal 2% Auslastung erzeugen. Stell sich also die Frage wann denn das Mulithreading aktiv wird? Erst wenn ein Kern zu 100% ausgelastet ist? Oder was ist das Kriterium dafür endlich mal den nächsten Thread aufzumachen?
Ich kennen das nur z.B. vom SpamAssassin wo man per Parameter die Anzahl der minimal immer aktiven Threads und die Anzahl der max zu öffnen Threads angibt.

tumic
22.04.15, 12:28
Soweit die Theorie....
Oder was ist das Kriterium dafür endlich mal den nächsten Thread aufzumachen?

Noch einmal: 1 UNIX socket Verbindung zum "avast" Process = 1 Thread.

Wie viele UNIX socket Verbindungen zum "avast" prozess gibt es? (Wie viele "scan"
Processe laufen parallel?)

furban
24.04.15, 08:14
Soweit ich das sehe laufen zwei Prozesse und das ziemlich mager.

# ps -ef |grep avast
avast 1809 1 2 Apr22 ? 01:01:31 /bin/avast
root 8578 3497 0 07:09 pts/0 00:00:00 grep --color=auto avast
# cat /proc/1809/status | grep Threads
Threads: 2

ps -L -o pid= -p 1809
1809
1809

tumic
24.04.15, 16:36
Soweit ich das sehe laufen zwei Prozesse und das ziemlich mager.

# ps -ef |grep avast
avast 1809 1 2 Apr22 ? 01:01:31 /bin/avast
root 8578 3497 0 07:09 pts/0 00:00:00 grep --color=auto avast
# cat /proc/1809/status | grep Threads
Threads: 2

ps -L -o pid= -p 1809
1809
1809

Der "avast" Prozess läuft nur einmal, die zweite Zeile ist der "grep" Befehl mit dem du das "ps" filterst.
"avast" soll aber nicht mehrmals laufen.

Viel mehr interresant währe:

ps aux | grep scan"
oder

lsof -p `cat /var/run/avast/avast.pid` | grep unix

aber wenn #Threads im "avast" 2 ist, heist das, das es nur eine Verbindung zum "avast" Prozess
gibt (und "scan" nur einmal läuft).

furban
27.04.15, 09:30
Ich fürchte das bringt alles keine neuen Erkenntnisse.



#ps aux | grep scan
root 27397 0.0 0.0 112640 960 pts/0 S+ 08:23 0:00 grep --color=auto scan




# lsof -p `cat /var/run/avast/avast.pid` | grep unix
avast 1930 avast 3u unix 0xffff880fe635c740 0t0 52344 socket
avast 1930 avast 50u unix 0xffff880fe7a6d280 0t0 463 /var/run/avast/scan.sock
avast 1930 avast 53u unix 0xffff880fe165c740 0t0 10704703 /var/run/avast/scan.sock


Entweder hat da Avast wirklich ein Problem, oder aber die Last reicht nicht damit mal ein paar weitere Threads dazu geschaltet werden.
Das wird uns dann aber wohl nur Avast selbst beantworten können.

tumic
27.04.15, 14:37
Aus der Amavis Dokumentation (http://www.ijs.si/software/amavisd/amavisd-new-docs.html):
"Although checks are presently not performed in parallel..."

Das Problem ist also im Amavis, das die Scans nicht parallisieren kann.

furban
27.04.15, 15:27
Aus der Amavis Dokumentation (http://www.ijs.si/software/amavisd/amavisd-new-docs.html):
"Although checks are presently not performed in parallel..."

Das Problem ist also im Amavis, das die Scans nicht parallisieren kann.

Von dieser Seite ganz unten: Last updated: 2010-10-20
War das schon nach dem Krieg? :)

Schade das sich nicht endlich mal jemand von Avasis zu dem Thema wieder meldet.
Immerhin laufen ja diverse Amavis Prozesse parallel. Ich denke also das Problem gibt es heutzutage nicht mehr. Würde irgendwie keinen Sinn machen.

Merlin
27.04.15, 16:35
Hallo,

ob die Dokumentation jetzt veraltet ist oder nicht, kannst du ja mal bei den Entwicklern anfragen. Es ist jedenfalls die aktuell verfügbare Dokumentation.

Wer ist Avasis?

furban
27.04.15, 17:07
Habe eben noch das hier gefunden
http://postfix.state-of-mind.de/patrick.koetter/amavisd-new/#id580260
Das werde ich mir mal morgen in Ruhe durchlesen.

furban
30.04.15, 09:44
sehe gerade das die eine CPU nun auf über 200% läuft. Das ist dann wohl also doch nur ein Anzeigeproblem vom top und das mit dem parallesliseiren ist doch soweit ok auch ohne Änderung.


PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2296 avast 20 0 2110108 149440 120696 S 203.0 0.1 121:32.48 avast
10799 root 20 0 728856 10504 9780 S 44.7 0.0 24:12.21 rsyslogd
713 root 20 0 191108 118864 116396 S 16.9 0.1 15:21.48 systemd-journal
2912 named 20 0 3074360 118976 3332 S 15.2 0.1 17:49.81 named
15535 amavis 20 0 241972 45356 3024 S 8.6 0.0 0:04.43 /usr/sbin/amavi
13278 amavis 20 0 241316 44712 3012 S 8.3 0.0 0:02.37 /usr/sbin/amavi
10065 amavis 20 0 241988 45376 3016 S 7.9 0.0 0:05.01 /usr/sbin/amavi
19061 amavis 20 0 241348 44696 2992 S 7.9 0.0 0:02.00 /usr/sbin/amavi

Merlin
30.04.15, 12:58
Hallo,

das ist kein Anzeigeproblem, sondern die Summe der Auslastung der einzelnen Prozessorkerne. Je Kern stehen 100% zur Verfügung.

Merlin
11.05.15, 13:35
Hallo,

da keine Rückfrage mehr kam, schliesse ich das Thema als "Gelöst".

Danke auch an tumic für die Hilfe!