[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] Rampup speed of Exit relay



So, Now I've taken some steps to adjust the state of the relay, and
try to balance this.

To reiterate a point previously,  before I start adding more tor
daemons or servers to this, I want to know how to scale and optimise
what is already there.

- Set up unbound in cache mode rather than use our local network unbound
- Disabled on machine firewall (stateful)
- Ensured AES acceleration worked
- Boosted amount of open files allowed even more
- Stopped doing regular reboots and only reboot on kernel change
- Bound Tor to a single core

The exit is till this one:
https://atlas.torproject.org/#details/5989521A85C94EE101E88B8DB2E68321673F9405

CPU utilization of a single core on  the machine never goes > 22%

Thus while it may be CPU bound, it's never maximising the CPU usage.

CPU and network are still scaling together with each other.

Load ( not cpu usage)  is fairly stable and load1 hasn't gone > 0.2

It's holding between 5k and 16k sockets in use, and ~3.5k sockets in
TIME_WAIT state.   (Fairly high amount?)

So far, I'm not sure _why_  it's capping itself on bandwidth, and
that's the one thing that I want to figure out before I start scaling
out horizontally.



On Fri, Sep 23, 2016 at 11:28 AM, nusenu <nusenu@xxxxxxxxxxxxxxx> wrote:
>>>>>> > > > > So, how do we get tor to move past 100-200Mbit? Is it just a
>>>>>> > > > > waiting game?
>>> >
>>> > I'd say just run more instances if you still have resources left and
>>> > want to contribute more bw.
>>> > (obviously also your exit policy influences on how much your instance
>>> > is
>>> > used)
>> Mainly, I want to scale up a single exit first, before I start adding
>> more resources.
>
> As Aeris, teor and me tried to explain, this is _not_ about "adding more
> resources", but since you keep ignoring that it is a bit pointless to
> state that over and over again.
>
> teor gave some rather comprehensive answers and has said pretty much
> anything relevant I guess.
>
> In the end it should be about optimizing exit bandwidth cost (many
> MBit/s for fewer $) no matter how many tor processes it requires to get
> the most out of your hardware, number of available IPs and uplink
> connectivity.
>
>> It might well be that I've missed something, some tuning I should have
>> remembered ( Like increasing the conntrack hash table size )
>
> I'm not sure I would run a stateful firewall on an dedicated exit server
> at all.
> https://www.torservers.net/wiki/setup/server
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays