Tor Relay overloaded - trotz genug RAM/CPU/Ports/Sockets

Moinsen, wollte Mal fragen, ob jemand ne Ahnung hat, woran das liegen kann, dass mein TOR Relay nach so 1 Tag meist 1Tag 10h Online Zeit immer auf overloaded geht obwohl alle Ressourcen ausreichend sollten.
Jetzt nach 4 Tagen Online Zeit am Stück das erstmal wieder in den Metrics als normal gelistet.

Was kann ich noch einstellen oder verbessern?
Oder ist das Normal?

MfG

Wenn deine Hardware stark genug ist, hilft ansich nur die NumCPU-Wert hochzusetzen.
Ich nutze auf nem i7-7700 den Wert: 60-70

Da hatte ich schon lange keine Überlastungsmeldung mehr.
Dafür laufen aber auch entsprechend viele Threads im Hintergrund, welche auch mehr Ram in Beschlag nehmen.
(Teilweise zwischen 10-15GB)

Mit den hier häufiger erwähnten Iptables-Filter-Skripten kann natürlich auch noch etwas nachgeholfen werden, um die oft laufenden Attacken aufs Netzwerk etwas zu reduzieren.

Danke schön Mal für die Antwort.
Also ich habe 10 CPUs und habe das auch so eingestellt, heißt also wenn ich NumCPU einfach höher setze sollte der mehr beanspruchen und “besser” laufen bzw. mehr Leistung haben?
Komischerweise läuft jetzt seit einigen Tagen auf der metrics Seite von TOR alles anscheinend ohne overloaded.
Kann auch sein, dass der sich nach ein paar Tagen wieder einlriegt bzw. das evtl. wirklich Angriff oder Überlastung war.
Oder es liegt an dem Guard Flag welches der zwar schon länger hat aber die Clients sich erst umstellen mussten und deswegen weniger Leistung gebraucht wird.
Ich beobachte das auf jeden Fall weiter und schaue dann Mal auch wie der nach dem nächsten Reboot läuft.
Welche IPTanles regeln kannst du empfehlen?
Hab halt auch ufw am laufen, falls man das damit auch umsetzen kann.

Gibt es sonst noch Möglichkeiten etwas zu verbessern/ zu optimieren?

MfG

Die letzten Tage haben einfach die Angriffe nachgelassen. Da läuft es auch ohne Filter-Regeln sauber mit wenig CPU-Bedarf.

Wenn die Angriffe stark sind, schalte ich dann das Skript von Ekidu dazu: GitHub - Enkidu-6/tor-ddos: iptables rules for Tor relay operators to mitigate ddos
Was die NumCPU’s angeht, das ist etwas schlecht formuliert.

Zum Beispiel mit htop siehst du schön, wie die Auslastung der einzellnen Threads ist. DIese werden mit der NumCPU geregelt. Wenn du zb. nen Wert von 50 setzt und siehst nach ner Woche das manche kaum benutzt werden von der Laufzeit, kannst du es reduzieren.
Bei mir allerdings sind selbst 70 noch fast immer ausgelastet. (da gehen aber meist auch immer 400-500 MBit dauerhaft durch)

Grundsätzlich nach meinen bisherigen Tests schadet es nicht, einen sehr hohen Wert dafür zu nutzen.
Es verbraucht dann nur mehr Ram.
Hast du allerdings zu wenig Prozesse, werden dann Anfragen verworfen und ab einen Grenzwert zeigts dein Relay dann als überlastet an. :slight_smile:
Daran kannst du auch gut sehen in den Relay-Listen, ob Angriffe laufen.
Dann sind die schnelleren oft Seitenweise rot :wink:

Also das mit dem NumCPU hab ich jetzt Mal getestet und hoch gestellt.
Finde die Einstellungen tatsächlich aber auch etwas unübersichtlich bzw. man muss sich alles irgendwie zusammen suchen. Und NumCPU bedeutet für mich eigentlich wie viele CPUs ich habe bzw. die Anwendung verwenden soll und nicht die Threads
Aber nun gut. Lernt man draus, dass manche Programmierer da irgendwie ein bisschen wirr-warr erzeugen.
Vielleicht hab ich da sonst auch n Denkfehler.

Das Script schaue ich mir dann nochmal an, wenn es wieder schlimmer werden sollte.
Hab früher auch 500MBit/s dauerhaft laufen gehabt.
Also RX/TX zusammen.
Jetzt aktuell zuletzt höchster Wert auf der Metrics Seite waren bei 46MiB/s

Das komische ist halt auch, dass der jetzt auf ca. 30MiB/s runter gegangen ist.
Und das CW von 66000 auf 44K.

Meinst du das liegt an DDoS oder ähnlichem?

Andere Sache wegen den Threads (NumCPU), hab die jetzt auch hoch gestellt.
Aber angeblich ist doch die Onion Skin Verarbeitung eh Single Threaded.
Macht das denn dann überhaupt was aus?
Die Auslastung von 200% CPU war meist im Hauptthread und die restlichen waren nur ein paar Prozent.
Wie ist das zu verstehen?

MfG und danke schon Mal für den Tipp und die Hilfe. Teste das jetzt Mal mit 60.

Also was das CW angeht, das wird ja regelmäßig angepasst.
Wenn immer mehr Server dazu kommen, fällt unser Wert entsprechend.
Ebenfalls wenn manche Server mit 100mbit gegen einen 1Gbit Port ausgetauscht werden.
Das zeigt ja nur das Verhälltnis zum gesamten Netzwerk an.

Evtl. wird auch manchmal ein Update bei den Verzeichnisbehörden eingespielt für einen besseren Wert, aber das ist nun bloß reine Spekulation.

Jedoch wegen dem Tor-Prozess.
Der Hauptprozess ist Single-Threaded.
Jedoch mit genügend Prozessen, die mit der Verschlüsselung beschäftigt sind, hast du eben einen größere, ich nenn es mal Warteschlange, wo sich dann die NumCPU positiv auswirkt und nicht gleich Pakete verworfen werden.

Kontrolliere regelmäßig mal dein Torlog.
Ich bin aktuell seit dem letzten Neustart bei den Werten: 1061/1061 TAP, 16192500/16192500 NTor.
Wenn der NTor extrem abweicht, siehst dann das wohl noch zu viele Pakete nicht verarbeitet werden können.
Also entweder immer noch NumCPU weiter erhöhen oder die Hardware ist einfach zu schwach für diese Menge.

OK ja gut das kann gut sein.
Frage mich sowieso wie genau das ermittelt wird.
Weißt du denn welche Aufgaben die Threads übernehmen, wenn der Hauptthread die Onion Skins wahrscheinlich macht.
Weil Single Threaded kann ja trotzdem dann 2 CPUs bei mir auslasten. Finde das insgesamt echt interessant.
Naja auf jeden Fall teste ich das jetzt mit NumCPU 60.
Bin Mal gespannt, wie die Leistung dann im Vergleich zu vorher ist.
Würde mich halt auch trotzdem noch mit dem CW der um 20000 sinkt und der Bandbreite von 45 auf 30 interessieren, woran das jetzt genau lag bzw. liegt.

Hab auch gestern noch das HSDir flag bekommen. Kann das damit auch zusammen hängen?

Hab halt entgegen der Empfehlung das auf 2 TOR Prozesse bzw. 2 Server zu splitten, einfach mit aktiviert. Hab halt nichts zu verbergen und auch aktuell keine Onion Seite. Wollte einfach nur auch für andere einen Rendezvous Punkt bzw. HSDir bereitstellen.

Kontrolliere das nur sporadisch. So lange es läuft, läuft’s halt :sweat_smile:
Also die Hardware sollte auf jeden Fall reichen, meines Erachtens nach.

Habe 10 Kerne mit 2GHz, 32GB RAM, 2TB SSD und Netzwerk 2,5GBit/s Synchron.

Und der ist mit mehreren verschiedenen Servern wie Gameserver, Voiceserver, TeamSpeak Bots, Speedtest Netzwerk Server sowie Analyse Software wie NTopNG was auch teils gut Leistung zieht trotzdem nur zu 20-30% ausgelastet. Und der RAM gerade Mal die Hälfte. Wobei zusätzlich noch ZRAM und Swap eingerichtet sind, mit etwas angepasster Config um das nur fürs nötigste zu verwenden.

Also eigentlich sollte der das Easy hin bekommen.
Wie gesagt höchste Auslastung im Hauptprozess waren 200% also 2 von 10 Kernen.

Weiß halt nicht, was man sonst noch optimieren könnte.

Habe früher nur 6 Kerne gehabt glaube zwar mit mehr Takt, war von Intel und der hat auch locker 500MBit/s gemacht. Da hatte ich auch nur 1GBit/s Bandbreite und hatte überwiegend keine Probleme.

Dementsprechend müsste das jetzt einfach sein für den Server das zu händeln.

MfG

Eben wegen der Problematik mit dem fehlenden Multitrheading macht es sich da besser weniger Kerne mit hohem Takt zu haben als viele Kerne :wink:

Aber einfach testen.
Manche versuchen ja auch noch die Kernelparameter etwas zu optimieren.
Bei dem vorher genannten DDOS-Skript sind auch ein paar Werte angegeben, welche ich mit umgesetzt habe.
Ob es wirklich einen Unterschied macht, kann Ich da nicht sagen.
Ist wohl teilweise eher ne Glaubenssache ^^