So,
da der Node nun schon ein paar Tage läuft, ich mittlerweile auch die portacl gesetzt habe (Danke nochmal an metro für den Hinweis) mal noch ein paar kosmetische Sachen falls jemand vorhaben sollte mal Tor auf FreeBSD rennen zu lassen. Kurzum: Es rennt wie ne Krücke. Da ist aber nicht FreeBSD schuld, sondern ein netter kleiner Bug in Tor, der bisher nicht gefunden wurde (mittlerweile arbeiten da aber neben mir wohl noch ein Paar Leute dran).
Tor erstellt per default bis zu 16 Worker Threads, welche die Arbeit erledigen, nun ist es aber so, dass diese aus irgendeinem Grund nach einiger zeit anfangen zu vermelden, dass sie busy wären, obwohl sie genaugenommen garnichts tun. Sobald das eintritt fängt die Maschine natürlich an bei ein paar hundert KB/sec bis wenige MB/sec rumzukriechen, was blöd ist.
Da ich den Fehler noch nicht gefunden habe, habe ich zumindest mal einen Workaround gebaut. Mit schuld an der Situation ist nämlich ein genialer Timeout von 12h für das killen dieser kaputten worker threads. Da die nämlich nach wenigen Minuten schon anfangen dieses Verhalten zu zeigen ist ein Timeout von 12h etwas schwachsinnig. Daher also den Timeout runter auf 120sek und die Anzahl der Threads hoch auf 32 und schon schnurrt das Kätzen. Ist natürlich keine gute Dauerlösung aber tut erstmal.
Das wäre der patch, falls es jemanden interessiert und noch ein Danke an Abakus fürs tatkräftige Helfen beim Debugging vorhin.
da der Node nun schon ein paar Tage läuft, ich mittlerweile auch die portacl gesetzt habe (Danke nochmal an metro für den Hinweis) mal noch ein paar kosmetische Sachen falls jemand vorhaben sollte mal Tor auf FreeBSD rennen zu lassen. Kurzum: Es rennt wie ne Krücke. Da ist aber nicht FreeBSD schuld, sondern ein netter kleiner Bug in Tor, der bisher nicht gefunden wurde (mittlerweile arbeiten da aber neben mir wohl noch ein Paar Leute dran).
Tor erstellt per default bis zu 16 Worker Threads, welche die Arbeit erledigen, nun ist es aber so, dass diese aus irgendeinem Grund nach einiger zeit anfangen zu vermelden, dass sie busy wären, obwohl sie genaugenommen garnichts tun. Sobald das eintritt fängt die Maschine natürlich an bei ein paar hundert KB/sec bis wenige MB/sec rumzukriechen, was blöd ist.
Da ich den Fehler noch nicht gefunden habe, habe ich zumindest mal einen Workaround gebaut. Mit schuld an der Situation ist nämlich ein genialer Timeout von 12h für das killen dieser kaputten worker threads. Da die nämlich nach wenigen Minuten schon anfangen dieses Verhalten zu zeigen ist ein Timeout von 12h etwas schwachsinnig. Daher also den Timeout runter auf 120sek und die Anzahl der Threads hoch auf 32 und schon schnurrt das Kätzen. Ist natürlich keine gute Dauerlösung aber tut erstmal.
Code:
nforce2# less /usr/ports/security/tor-devel/files/patch-src-or-cpuworker.c
--- src/or/cpuworker.c 2012-01-20 17:38:13.000000000 +0100
+++ src/or/cpuworker.c 2012-01-20 19:16:44.000000000 +0100
@@ -24,7 +24,7 @@
#include "router.h"
/** The maximum number of cpuworker processes we will keep around. */
-#define MAX_CPUWORKERS 16
+#define MAX_CPUWORKERS 32
/** The minimum number of cpuworker processes we will keep around. */
#define MIN_CPUWORKERS 1
@@ -405,7 +405,7 @@
* up on it and decide that we have a bug or infinite loop?
* This value is high because some servers with low memory/cpu
* sometimes spend an hour or more swapping, and Tor starves. */
-#define CPUWORKER_BUSY_TIMEOUT (60*60*12)
+#define CPUWORKER_BUSY_TIMEOUT (60*2*1)
/** We have a bug that I can't find. Sometimes, very rarely, cpuworkers get
* stuck in the 'busy' state, even though the cpuworker process thinks ofDas wäre der patch, falls es jemanden interessiert und noch ein Danke an Abakus fürs tatkräftige Helfen beim Debugging vorhin.
