Ist iperf3 installiert?

    Hallo,


    aufgrund etwaiger Netzwerkprobleme (geschildert in einem anderen Thread hier), habe ich mal versucht meine Netzwerk-Geschwindigkeit mit iperf3 zu testen.


    Ich hab daher versucht dieses iperf3 zu installieren. QNAP selbst schlägt dazu "entware" vor.

    Ich habe nach deren Anleitung gearbeitet komme aber nun hier nicht mehr weiter. Er hat irgendwas installiert:

    1669219764228.png


    Ich möchte das aber nun wieder deinstallieren, weil ich über ein externes QNAP App repository (qnapclub.eu) gleich direkt einen iperf3 server gefunden habe.



    Wisst ihr wie ich dieses zuvor installierte iperf3 (entware) nun deinstallieren kann und ob ich überhaupt irgendwas deinstallieren muss, weil so sicher bin ich mir da gar nicht...

    Ad Hoc sieht es für mich so aus, als wäre gar nichts installiert worden (als alternativer Admin angemeldet?).

    Iperf3 kann man aber auch einfacher haben ;)

    Qnapclub Store: iPerf3
    iPerf3 is a tool for active measurements of the maximum achievable bandwidth on IP networks. It supports tuning of various parameters related to timing,…
    www.qnapclub.eu

    Oh, überlesen dass du die app schon gefunden hast...

    Einmal editiert, zuletzt von tiermutter () aus folgendem Grund: Ein Beitrag von tiermutter mit diesem Beitrag zusammengefügt.

    Ich hab nun mal "ps" in einer SSH Session mit Putty ausgeführt.


    In einem anderen Forum meint ein wohl sehr bewandertes Mitglied, dass da sehr viel "Zombie-Prozesse" laufen würden, die mit verschiedensten Problemen mit dem NAS in Verbindung gebracht werden (auch Geschwindigkeitseinbrüche..., siehe dazu meinen anderen Thread). Noch dazu seien mehrere SSH Sessions offen, die ich sicherlich nicht mehr brauche.


    Wie finde ich nun raus, welche Zombie-Prozesse (+ SSH Sessions) das sind und wie schließe ich diese Prozesse/SSH-Sessions?

    Das Vorgehen bei Zombie-Prozessen hängt davon ab, ob ihre Herkunft noch ermittelt werden kann.

    Also wenn es Dir gelingt zu einem Zombie-Prozess den Parent-Prozess zu ermitteln, dann kannst Du dem Parent-Prozess ein Signal senden, dass er seine Child-Prozesse prüfen/terminieren soll (SIGCHLD). Hat ein Parent auffällig viele Zombies, kann es auch helfen den ganzen Parent-Prozess zu terminieren. Wobei einem schon klar sein sollte, welchen Prozess man da gerade "abschießt".

    Sollte es sehr, sehr viele Zombie-Prozesse sein und/oder man kann keinen eindeutigen Parent-Prozess mehr ermitteln - Init (PID 1) zählen wir hier mal nicht als eindeutigen Parents. ;) Dann hilft selbst bei einem *nix-System meist nur noch ein Reboot.

    Also ich sehe da auch nichts Auffälliges... was ist denn gemeint?

    Reboot wurde sicherlich schon zwischendurch gemacht, damit wäre alles Unnötige auch weg...

    Zitat von tiermutter

    was ist denn gemeint?

    Das hab ich jetzt mal noch genauer nachgefragt...


    Mal davon ab: Wenn ich mit putty eine Session über SSH aufbau und ich dann putty einfach schließe bleibt auf dem NAS eine SSH Session offen, oder wie? Was müsste ich daher machen um die Session gleich wieder zu schließen?


    Und: Ein Reboot würde zumindestens die ganzen SSH sessions schließen?

    Zitat von bandchef

    bleibt auf dem NAS eine SSH Session offen, oder wie? Was müsste ich daher machen um die Session gleich wieder zu schließen?

    Da bin ich mir nicht sicher, ich meine dass die Session dann auch geschlossen wird.

    exit beendet die Session aber "hochoffiziell".

    Zitat von bandchef

    Und: Ein Reboot würde zumindestens die ganzen SSH sessions schließen?

    Wenn sie wirklich nicht benötigt werden, ja. Könnten ja durchaus andere Dienste sein, die per SSH zugreifen.

    Aber ich habe da jetzt auch nichts Auffälliges gesehen.

    Zitat von bandchef

    Mal davon ab: Wenn ich mit putty eine Session über SSH aufbau und ich dann putty einfach schließe bleibt auf dem NAS eine SSH Session offen, oder wie?

    Nein, die Session bleibt nicht offen. Wenn keine Aktivität erfolgt, schließt der Server die Session automatisch. Wenn der Client nicht will, dass eine Session geschlossen wird, muss er Daten schicken - dafür gibt es Keep-Alive-Pakete. Wird der Client abgeschossen, kann er das nicht, und der Server schließt die Session mangels Aktivität. Wird der Client hingegen nicht abgeschossen sondern regulär beendet, sollte er ein normales Exit schicken und die Sitzung sofort beenden.


    Bei qts hat Qnap allerdings eine Besonderheit eingebaut. Wenn in der ssh-Sitzung ein Kommando als eigener Prozess gestartet wird, z. B. mit einen & am Ende der Zeile, dann läuft dieser Prozess auch nach dem Ende der ssh-Sitzung weiter. Das widerspricht dem üblichen Verhalten von Unix und Linux, wo der Prozess mit nohup gestartet werden müsste, um das Ende der Sitzung zu überleben.

    Zitat von Anthracite

    Nein, die Session bleibt nicht offen.

    Und wo kommen dann die ganzen SSH Sessions her? Ich habe meines Erachtens nichts am Laufen, was diese ganzen SSH Sessions erzeugen würde! Ich hab grad eben mal neugestartet. Hier die Ausgabe nach erneutem PS:

    Zitat von tiermutter

    was ist denn gemeint?

    Vor allem eben diese Zombie-Prozesse (was auch immer das nun ist!) + grep und curl wären wohl auffällig gewesen...

    Frage an einen Moderator hier:


    Kann man vielleicht der Übersichtlichkeit-halber diesen thread und den thread zusammenfügen? Die Frage nach iperf3 ist nämlich aus dem gleichen Grund heraus entstanden, weil noch immer nicht klar ist, warum die Übertragungsgeschwindigkeit unvermittelt nach unter schiedlichen Zeitpunkten einbricht.

    Einmal editiert, zuletzt von bandchef () aus folgendem Grund: Ein Beitrag von bandchef mit diesem Beitrag zusammengefügt.

    Daran ist überhaupt nichts auffällig... oder ich sehe es nicht.

    grep und curl weisen nichtmal auf Aktivitäten mit SSH hin, das sind ganz normale Prozesse von QTS um zB Update-Infos zu holen.

    Damit ich daran glaube, dass da etwas auffällig sein soll, braucht es schon eine detailierte Begründung...

    Zitat von bandchef

    Und wo kommen dann die ganzen SSH Sessions her? [...] Hier die Ausgabe nach erneutem PS

    Welche ssh-Sessions meinst du? Bei einem kurzen Blick habe ich nur die eine ssh-Syssion gefunden, die du aufgemacht hast, um den ps-Befehl abzusetzen.

    Ok. Irgendwie muss ich dann wohl davon ausgehen, dass das irgendwie eine Falschmeldung in dem anderen Forum war. Danke an euch!

    Mal davon abgesehen: Wie kann ich auf serverseitig das iperf3 starten? Wenn ich das "iperf3 -s" benutze bekomme ich diese Fehlermeldung:

    pasted-from-clipboard.png


    Was bedeutet das?

    Einmal editiert, zuletzt von bandchef () aus folgendem Grund: Ein Beitrag von bandchef mit diesem Beitrag zusammengefügt.

    Was hast Du denn vor?

    iperf3 -c x.x.x.x misst von QNAP als Client zur angegebenen Server-IP

    iperf3 -c x.x.x.x -R misst von der angegebenen Server-IP zum QNAP als Client

    iperf3 -s brauchst Du gar nicht, da iperf hier sowieso automatisch und ständig lauscht

    Daher wird übrigens auch die Fehlermeldung kommen:

    iperf3 server ist bereits aktiv und kann daher nicht noch eine (dieselbe) Instanz starten.

    Einmal editiert, zuletzt von tiermutter () aus folgendem Grund: Ein Beitrag von tiermutter mit diesem Beitrag zusammengefügt.

    Zu den offenen Sessions:

    Eine SSH Verbindung nutzt eine TCP Socketverbindung.

    Wird diese duch Ausloggen oder Beenden des Clients unterbrochen, erkennt das der SSH Server und beendet/löscht die Session. Das ist der Normalfall.

    Das Sessions übrig bleiben, ist unüblich. Bestehen denn dann noch TCP Verbindungen zu TCP Port 22?

    Das kann man mit 'netstat' prüfen.


    Tschau

    Uwe

    Ich habe nun mit iperf3 eine Messung gestartet. Irgendwann nach einer x-beliebigen Zeit wird die Messung mit der Meldung "Connection reset by peer": abgebrochen. Ich hab hier das log angehängt.


    Ich denke da hat der USB-Netzwerkcontroller ein Problem. Was meint ihr?

    Die 6400 Zeilen mag ich mir jetzt nicht im Detail ansehen, aber zum NAS sieht es ja gut aus, der Fehler kommt nur beim Test zum Rechner.

    Das bedeutet jetzt aber auch nicht zwingend etwas, da es verschiedene Gründe haben kann. Die Gegenstelle hat halt die Verbindung beendet... sicherlich weil irgendwas nicht passt, aber hier könnte auch Windows einfach geblockt/ nicht geantwortet haben. Genauso gut könnten die Antworten untergegangen sein, sodass der Server die Verbindung beendet hat. Es hilft also nicht um den Fehler einzugrenzen.


    Eingrenzen geht mMn nur, indem

    1) auch mit einem anderen Client getestet wird

    2) die Infrastruktur so einfach wie möglich gehalten und schrittweise zum aktuellen Ausbau wieder aufgebaut wird