Man weiß mal wieder nicht, wieso der Download so lange dauert und man würde gern nachsehen was los ist. Mal abgesehen von der Fremdwirkung aka „Freundin beim YouTube quälen erwischen“, kann natürlich auch die Leitung gestört sein.
Also erstmal checken, ob man überhaupt eine Chance hat
Ab hier sind wir ROOT , da wir nur so an die nötigen Informationen ran kommen.
Mit iotop können wir erstmal nachsehen ob unser Rechner nicht durch IO ausgelastet ist:
Total DISK READ : 0.00 B/s | Total DISK WRITE : 0.00 B/s Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND 3629 be/4 root 0.00 B/s 0.00 B/s 0.00 % 2.32 % [kworker/0:0] 262 be/4 root 0.00 B/s 0.00 B/s 0.00 % 2.30 % [kworker/2:2] 1 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % systemd --switched-root --system --deserialize 24 2 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kthreadd] 3 be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [ksoftirqd/0] 2052 be/4 marius 0.00 B/s 0.00 B/s 0.00 % 0.00 % nautilus -n [gdbus] 5 be/0 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/0:0H]
Wie man leicht erkennen, hatte ich bei meinem Aufruf keine IO irgendeiner Art auf dem Laptop. Sehr gut so, CHECK.
Als nächstes prüfen wir mal die Leitung ins Netz mit MTR:
# mtr --report-wide bloggt-in-braunschweig.de Start: Thu Sep 8 17:38:16 2016 HOST: warrior Loss% Snt Last Avg Best Wrst StDev 1.|-- fritz.box 0.0% 10 18.6 16.8 3.2 20.8 4.8 2.|-- 217.0.119.85 0.0% 10 18.5 19.5 17.8 27.3 2.8 3.|-- 217.0.65.254 0.0% 10 21.5 18.5 17.4 21.5 1.1 4.|-- 217.239.44.22 0.0% 10 25.6 27.7 23.3 54.6 9.6 5.|-- cr01.h.as24679.net 0.0% 10 45.0 36.8 34.5 45.0 3.3 6.|-- ar13.h.as24679.net 0.0% 10 64.1 61.7 34.9 144.7 31.9 7.|-- bloggt-in-braunschweig.de 0.0% 10 34.3 34.8 34.1 35.7 0.3
Ok, die Leitung raus ist auch ok, kein Paketloss .. CHECK
Die billigste Bandbreitenmessung schlechthin: Mit wget eine große Datei abholen.
BEENDET --2016-09-08 17:47:47-- Verstrichene Zeit: 2,9s Geholt: 7 Dateien, 121K in 0,1s (1,06 MB/s)
Am Ende des Wget-Aufrufs bekommt man die Geschwindigkeit angezeigt. (Ja, das WLAN im Hof ist nicht das schnellste 🙂 ) Wenn man jetzt eine große Datei, sagen wir mal 100MB holt, hat man ein belastbares Ergebnis. Das habe ich jetzt natürlich nicht gemacht 🙂
Alle mir bekannten Tools, und das sind nicht viele, nutzen auch nur wget mit einigen Testservern aus. Aber Bandbreite kann man ja auch anders messen .. z.B. mit bmon !
Was geht ab!
Deutlich genauer kann bmon anzeigen, wieviel Bandbreite auf welchem Interface gerade genutzt wird:
bmon zeigt neben den einzelnen Interfacen auch Angaben zu QOS Einstellungen aka Trafficshaping auch Statistiken für die aktuelle Werte der Netzwerkkarten an ( Taste i ). Für die Konsole ist das eine sehr praktische Zusammenfassung. Ausgewachsene Masochisten werden allerdings ifconfig auswerten wollen, daß uns diese Daten auch gibt (sortof 😀 ) : watch -n 0,5 „ifconfig “
[root@eve marius]# ifconfig enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.44 netmask 255.255.0.0 broadcast 192.168.255.255 inet6 fe80::4216:7eff:fe24:a01 prefixlen 64 scopeid 0x20<link> ether 51:23:09:1a:44:16 txqueuelen 1000 (Ethernet) RX packets 2083577 bytes 2706797719 (2.5 GiB) RX errors 0 dropped 351 overruns 0 frame 0 TX packets 1243333 bytes 218434352 (208.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1 (Lokale Schleife) RX packets 775 bytes 42829 (41.8 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 775 bytes 42829 (41.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether 51:23:09:1a:44:16 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Wenn man nun selbst grade nichts wissentlich zieht und die Bandbreite trotzdem hoch ist, wird man auf netstat oder iotop ausweichen müssen um den Täter zu ermitteln. Schauen wir uns netstat mal an :
[root@warrior marius]# netstat -lnap | grep -i verbunden | grep -v unix tcp 0 0 192.168.0.103:51438 192.0.78.23:443 VERBUNDEN 3396/firefox tcp 0 0 192.168.0.103:48760 192.168.0.34:22 VERBUNDEN 3970/ssh tcp 0 0 192.168.0.103:41712 54.149.28.204:443 VERBUNDEN 3396/firefox tcp6 0 0 192.168.0.103:35104 83.246.80.153:5222 VERBUNDEN 2028/java
Mit der Anzeige sehen wir, welche zwei Rechner mit welchem Programm grade Daten austauschen. Wenn in Spalte 2 und 3 statt 0 etwas großes drin steht, dann geht da datenmäßig grade richtig was ab, denn das sind die Sende- und Empfangsqueues der Verbindung. Das sind kleine Puffer für Daten, die nicht schnell genug geschrieben oder gelesen wurden.
iotop wird uns dagegen verraten, wer grade wieviel IO macht und Netzwerkverkehr ist auch IO 🙂 So oder so, wir kriegen raus was da läuft.
Im nächsten Artikel geht es dann um weitere Netzwerktools, wie Iptraf, ifstat,vnstat usw..