#2394 closed Defekt (erledigt)
Konfigurationsproblem Bittorrent?
| Reported by: | Rüdiger Kupper | Owned by: | bau |
|---|---|---|---|
| Priority: | bald erledigen | Milestone: | Schuljahr 2016/17 |
| Component: | Server: LML-Server (paedml) | Severity: | beeinträchtigt den Unterricht einiger Lehrer |
| Keywords: | Cc: |
Description
Beim lesen des Logfiles von Bittorrent fällt diese wiederkehrende Fehlermeldung auf:
IOError: [Errno 13] Permission denied: '/var/lib/bittorrent/bttrack.state'
Die Datei ist in /etc/default/bittorrent konfiguriert:
# Persistent state file DFILE=/var/lib/bittorrent/bttrack.state
Sie existiert aber gar nicht und wird offenbar auch nicht automatisch angelegt. Vielleicht ist das der Grund dafür, dass so viele unserer Clients aufgeben und stattdessen rsync nutzen? (Gerade eben ist die Load auf dem paedml wieder auf 80!).
Attachments (3)
Change History (16)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Okay, und dann muss der Nutzer, als der der Bittorrent-Deamon läuft, dort auch schreiben können:
chown --recursive bittorrent: /var/lib/bittorrent/
Jetzt füllt sich die Datei mit IP- und Schlüsseldaten und die Fehlermeldungen im Log sind weg...
comment:3 by , 10 years ago
Okay, die Load steigt beim syncen nun nur noch auf 25: Nach 10 Minuten beschließen immer noch 25 Clients, den Torrent-Download abzubrechen und rsync zu benutzen. Das sind immerhin viel weniger als 80, aber noch immer nicht richtig gut.
follow-up: 5 comment:4 by , 10 years ago
Wir müssen beim nächsten Sync mal checken, welche Clients das sind!
comment:5 by , 10 years ago
Replying to bau:
Wir müssen beim nächsten Sync mal checken, welche Clients das sind!
Mit etwas Glück kann ich das aus den Linbo-Logfiles herauslesen, muss ich mal versuchen.
comment:6 by , 10 years ago
Der Multicast-Server läuft übrigens auch auf dem paedml. Haben wir das jemals ausprobiert?
comment:7 by , 10 years ago
Die Parameter in /etc/default/linbo-bittorrent sollten wir auch mal auf ihre Sinnhaftigkeit prüfen. Wir haben ja sehr viele Schülerrechner, vielleicht stehen hier ungeschickte Zahlen drin?
comment:8 by , 10 years ago
Hier gibt's was von der Mailingliste:
https://mail.schule-bw.de/pipermail/linuxmuster/2013-July/056913.html
Interessant:
Ich habe auf dem Server Bittorrent und linbo-bittorrent gestartet. Die default Werte habe ich angepasst, so dass auch mehr Clients gleichzeitig sich verbinden können.
Der hatte übrigens auch schon das fehlen der bttrack.state-Datei bemerkt, und das war im Juni 2013...
by , 10 years ago
| Attachment: | rsync-downloads-2016-10-09 added |
|---|
Liste der Rechner, die beim letzten Sync das cloop per rsync heruntergeladen haben
by , 10 years ago
by , 10 years ago
| Attachment: | hostnames-sorted added |
|---|
comment:9 by , 10 years ago
Hier sind die Rechner, die beim letzten Sync Sonntag Nacht das cloop per rsync heruntergeladen haben:
attachment:rsync-downloads-2016-10-09
Hier nur die Hostnamen, in der Reihenfolge, wie sie im Log auftauchen:
attachment:hostnames
Und hier alphabetisch sortiert:
attachment:hostnames-sorted
Das sind genau 100 Rechner. Erkennst Du da ein Schema?
comment:10 by , 10 years ago
Ich habe gestern das virtual-XP_S.cloop per torrent auf die Rechner in 1-09 gebracht. Dabei lief einiges nicht ganz so rund. Ich würde mal vermuten, dass die 100MBit-Anbindung der beiden Räume wenig effektiv ist. Wir schauen mal weiter, sobald ich die beiden 100MBit-Module durch GBit-Nodule ersetzt habe.
Dann verbleibt noch im 2.U ein 100MBit-Switch (5.17 - 5.22 glaube ich).
comment:11 by , 10 years ago
Ich habe jetzt einfach mal die Wartezeit der Clients von 300 auf 3000 Sekunden hochgesetzt: Die warten nun also bis zu 50 Minuten, bevor sie auf rsync umschwenken. Das müsste lang genug sein, damit die Rechner, die das Netzwerk blockiert haben, mit dem Sync fertig sind. Vielleicht hilft das ja.
comment:12 by , 10 years ago
| Resolution: | → erledigt |
|---|---|
| Status: | new → closed |
Das löst das Load-Problem auf dem paedml. Am Freitag hatte ich mit dieser Einstellung noch noch vier Clients, die sich für rsync entschieden haben.
Die Einstellung löst zwar nicht das Problem, dass die Switches die DHCP und torrent-Pakete neuer Rechner nicht durchlassen, wenn viele andere Rechner untereinander Torrent-Schnipsel austauschen. Am Freitag habe ich beobachtet, dass ein Cient gerne mal 20 oder mehr Minuten während des Torrent-Downloads wartet, bis die nächsten Daten kommen.
Mit der aktuellen Einstellung wird der Sync aber entzerrt: So dauert es gut eineinhalb bis zwei Stunden, bis alle Schuelerrechner gesynct haben, doch sie nutzen alle Bittorrent und die Load auf dem paedml steigt während der ganzen Zeit nicht relevant an.
Ich erhöhe die Wartezeit jetzt noch einmal auf 90 Minuten. Damit sollte jeder Client eine freie Leitung für den torent finden und keine rsync-Prozesse mehr auftreten.
comment:13 by , 10 years ago
Waren das Rechner in 1.09 / 1.10 un dem zweiten U?
Dort sind noch 100MBit-Switche verbaut.
Ich habe die Datei jetzt einfach mal als leere Datei angelegt. Mal sehen, ob es was nützt.