[Tor-BSD] Kernel crashes FreeBSD 11

[Paul]

Am 17.05.2017 um 16:42 schrieb Christian Sturm:
> On 05/15/2017 13:52, Paul wrote:
>> I am running Exits on Tor 0.2.9.10 on FreeBSD 11.0-RELEASE-p9 with rather small RAM.
>> It works well apart from the fact that it crashes from time to time leaving one of the following messages in the log:
> 
> Is that really a crash of the kernel? What do you see? I'd expect just
> Tor to crash or is that what you meant?
There is no info in the Tor logs about it -only in /var/log/messages I can find every 5 minutes

May 17 14:50:45 kernel: [1269430] [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached
May 17 14:55:45 kernel: [1269730] [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached

At that time the server cant be pinged nor reached via ssh to get rebooted. So would it be possible to have a script to check whether the limit is reached (same with  "kern.maxfiles limit exceeded") and then reboot automatically?

> 
> I suppose you are running something like a relay or a bridge.

Yes I run a Tor Exit relay
> 
> You could/should increase maxfiles, but what else you could do is reduce
> the advertised bandwidth. You can do so with the MaxAdvertisedBandwidth
> option.

Currently I have only RelayBandwidthRate and RelayBandwidthBurst in place

> 
> This will reduce the advertised, but not the actually used bandwidth (so
> you are not helping less, but more, since your relay will stay up),
> which means that you hopefully don't have so many file
> descriptors/connections open after changing this.
> 
> Indeed running with a low amount of memory isn't good, but right now it
> sounds like you only run out of virtual limits, which FreeBSD is very
> conservative on by default. Even though you don't have much memory you
> should be save to increase it, if you didn't increase it already.

My effort is to maximize the performance on given RAM :-)
Currently this translates on that rather small machine to about 200 GB/day one way traffic
> 
> You can compare the output of sysctl kern.maxfiles (which is the limit)
> with sysctl kern.openfiles (which is the actual value), to see how close
> you are to that limit. You could use that for resetting, as you
> mentioned, but I'd suggest to change OS and/or Tor settings instead.

512MB RAM seem to result in kern.maxfiles: 15349
Currently only up to 25% are to be open on different machines 

> 
> Two more tips if you are running low on memory and are running a relay.
> 
> If your relay also acts as a directory mirror, stop doing so. This will
> reduce the amount of resources and the network isn't short of them for
> now. It also means that your traffic will instead go towards actual Tor
> connections, which might be a nice side effect, and generally
> recommended for systems with lower resources.

Ok, I now don’t give a DirPort and set "DirCache 0"
> 
> Something that would greatly reduce all kinds of resources is running as
> a bridge.
Yes sure - but at the moment I prefer running it as an Exit.
> 
> I hope that helped.
Thank you very, very much for your that detailed suggestions.

Paul
> 
> Chris
> 
> 
> 
> _______________________________________________
> Tor-BSD mailing list
> Tor-BSD at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/tor-bsd
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nycbug.org/pipermail/tor-bsd/attachments/20170518/a765401e/attachment.bin>