Tunneldigger verursacht hohe Prozessorlast auf den Gateways?


#1

Moin,

ich sehe gerade, dass der Tunneldigger-Prozess bzw. Python auf zumindest Parad0x und Des1 eine ziemlich hohe Prozessorlast verursachen (~75-95%).

Das war eigentlich sonst nicht so. Daher frage ich mich, wo das herkommt und ob eventuell was schief läuft.

@Adminteam

Grüße
Matthias

Ergänzung: Das scheint ein Bug im neuen Tunneldigger zu sein. Die Gateways, die noch mit der alten Version laufen, ideln rum, die auf denen die neue Version läuft, rödeln die ganze Zeit rum. Ich frag mal auf der Mailingliste nach, ob da was bekannt ist.


Collectd auf barristan 50% CPU usage?
#2

Ist eigentlich mittlerweile eine Lösung für da Problem gefunden worden?

Ich glaube irgendwo ist mal an mir vorbei geflogen, dass von der wlanslovenija version wieder auf die ffrl version umgeschaltet werden sollte (und im ansible ist das auch so).

Zumindest auf des1 scheint jedoch noch die wlanslovenija version zu liegen (und die CPU Auslastung ist noch sehr hoch).

Soll ich dort einfach mal die ffrl version ausrollen?


#3

75% sagt ja nicht viel aus, wenn der VM angenommen nur 600 Mhz zugewiesen sein “könnte”.

Rhe-Gatewawy nutzt derzeit bei einer Bandbreitennutzung von in+out insg.ca 60 Mbit/s mit 960 Mhz CPU Nutzung.
(freigegeben sind der VM von meinem vHost 3,3 GHz Hardware Rechenleistung)
sowie 2 GB RAM.
1500 Mhz können es schonmal bei höherer Bandbreitennutzung werden (in Spitzenzeiten), dann gehen etwa 15.000 Kbyte/s über die Leitung etwa 120 Mbit/s
Es ist aber nicht zu Kapazitätsengpässen gekommen.

Sind denke ich mal keine “dramatischen” sondern norm-Werte, oder? So dass ich an der Hardwarespezifikation nicht drehen müsste?


#4

Joa, bei mir hat die VM einen Core (mit 3,4 GHz) und durchschnittlich ist rx+tx bei 400 Mbit/s. Aber ich denke das tut hier nichts zur Sache. Denn es geht um den Tunneldigger und das ist doch “nur” ein broker.


#5

Eigentlich dachte ich, dass ich alle zurück gedreht hätte. Dann hab ich Des1 wohl vergessen.

Einfach den Broker stoppen, /srv/tunneldigger löschen und Asible drüber bügeln.

Grüße
Matthias


#6

Auf FanLin läuft auch noch die falsche Version:

root@remue-ansible ~/ansible-ffms # ansible gateways -m shell -a "pgrep python| xargs ps"
remue-08 | SUCCESS | rc=0 >>
  PID TTY      STAT   TIME COMMAND
 2185 ?        Ssl  106:14 /srv/tunneldigger/bin/python /srv/tunneldigger/broker/l2tp_broker.py /srv/tunneldigger/broker/l2tp_broker.cfg
 6520 pts/0    S+     0:00 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1471749158.41-96932633572611/command

fanlin | SUCCESS | rc=0 >>
  PID TTY      STAT   TIME COMMAND
 4514 ?        Ss   16742:19 /srv/tunneldigger/bin/python -m broker.main /srv/tunneldigger/broker/l2tp_broker.cfg
 9619 pts/0    S+     0:00 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1471749158.84-137172395290569/command

c1024 | SUCCESS | rc=0 >>
  PID TTY      STAT   TIME COMMAND
14990 pts/0    S+     0:00 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1471749158.43-84792450525198/command
17151 ?        Ssl  2097:18 /srv/tunneldigger/bin/python /srv/tunneldigger/broker/l2tp_broker.py /srv/tunneldigger/broker/l2tp_broker.cfg

greyworm-06 | SUCCESS | rc=0 >>
  PID TTY      STAT   TIME COMMAND
 2589 ?        Ssl   46:37 /srv/tunneldigger/bin/python /srv/tunneldigger/broker/l2tp_broker.py /srv/tunneldigger/broker/l2tp_broker.cfg
18506 pts/0    S+     0:00 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1471749158.39-167928600693489/command

parad0x | SUCCESS | rc=0 >>
  PID TTY      STAT   TIME COMMAND
15736 pts/0    S+     0:00 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1471749158.43-43772904426912/command
24945 ?        Ssl  1512:58 /srv/tunneldigger/bin/python /srv/tunneldigger/broker/l2tp_broker.py /srv/tunneldigger/broker/l2tp_broker.cfg

rhe | SUCCESS | rc=0 >>
  PID TTY      STAT   TIME COMMAND
 5473 ?        Ssl   75:34 /srv/tunneldigger/bin/python /srv/tunneldigger/broker/l2tp_broker.py /srv/tunneldigger/broker/l2tp_broker.cfg
27550 pts/0    S+     0:00 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1471749160.05-179291605424325/command

ausrufer | SUCCESS | rc=0 >>
  PID TTY      STAT   TIME COMMAND
 3411 pts/0    S+     0:00 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1471749159.96-277284507381344/command
 4790 ?        Ssl  809:30 /srv/tunneldigger/bin/python /srv/tunneldigger/broker/l2tp_broker.py /srv/tunneldigger/broker/l2tp_broker.cfg

des1 | SUCCESS | rc=0 >>
  PID TTY      STAT   TIME COMMAND
10199 ?        Ss     1:58 /srv/tunneldigger/bin/python -m broker.main /srv/tunneldigger/broker/l2tp_broker.cfg
11914 pts/0    S+     0:00 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1471749160.69-199753547734015/command

barristan | SUCCESS | rc=0 >>
  PID TTY      STAT   TIME COMMAND
  884 pts/0    S+     0:00 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1471749158.46-74820643727413/command
25604 ?        Ssl  502:12 /srv/tunneldigger/bin/python /srv/tunneldigger/broker/l2tp_broker.py /srv/tunneldigger/broker/l2tp_broker.cfg

root@remue-ansible ~/ansible-ffms #

Das sieht man an dem -m broker. Das hat nur die kaputte Version.

Mir fällt auch gerade wieder ein, dass dein Server abgestürzt war, als ich mir das zuletzt angesehen hatte.

Ich hatte mal auf der Mailingliste der Entwickler geschrieben, aber dort konnte es niemand reproduzieren.


#7

Ist repariert. Ansible auf dem Telefon, wenn man gerade nicht schlafen kann FTW :slight_smile: