On 2014-12-31 11:21, Libertas wrote:
For those not familiar, a Tor relay will eventually have an open TCP
connection for each of the other >6,000 active relays, and (if it allows
exit traffic) must make outside TCP connections for the user's requests,
so it's pretty file-hungry and crypto-intensive.
It can also be pf-state-hungry. Further, each upstream peer Tor node, and each
client on a Tor entry node, will probably be a pf src.
Packets being dropped and circuits failing when the pf default limits topped
out would naturally present to the tor bandwidth authorities as network
congestion.
In my case, I'm now fairly certain my relays usage grew to the point where
they were allocation-bound in pf. The host was still using the pf defaults
until recently.
Since increasing the pf limits, I'm seeing better throughput. The "current
entries" from pfctl -si currently reach 35k instead of hitting the default
limit of 10k. Also, state inserts and removals are up to 50/s from 29/s, and
matches are topping 56/s instead of 30/s. As well, the pfctl -si "memory could
not be allocated" counter remains a reassuring 0 instead of increasing at
0.9/s. Additionally, netstat -m counters for pf* have a reassuring 0 in the
failure column of the memory resource pool stats. Finally, Tor network traffic
seems to have started climbing.
I increased the limits thusly, since the host does nothing but Tor and unbound
for Tor DNS.
| # don't choke on lots of circuits (default is states 10000,
| # src-nodes 10000, frags 1536)
| set limit { states 100000, src-nodes 100000, frags 8000, \
One possible explanation is that its randomness store gets exhausted. I
once saw errors like this in my Tor logs, but I don't know how to test
if it's a chronic problem. I also couldn't find anything online. Is
there any easy way to test if this is the bottleneck?
I suspect Tor won't exhaust randomness; random(4) shouldn't block. (From a
cursory look at the source, Tor references /dev/urandom, and doesn't use
arc4random.)
Richard
