Discussion:
[tor-dev] Running Tor with a 15MB memory limit
Nathan Freitas
2017-12-01 04:48:38 UTC
Permalink
I am currently supporting the iCepa project, an effort to get Tor to run
as a Network Extension VPN on iOS.

https://github.com/iCepa/iCepa

The good news is that, after a long time, we have the whole thing
somewhat working. The bad news is that after browsing a few pages
through Tor, the extension is shutdown due to going over the extremely
tiny 15MB available heap. More on this at:

https://forums.developer.apple.com/thread/73148
https://developer.apple.com/documentation/networkextension

My question is, does anyone else have experience running Tor within some
extreme memory limits? Any guidance on configuring torrc for this? Any
thoughts on build flags or changes that might reduce memory usage?

We have already identified that the new compression features available
in recent versions of Tor consume more memory, and we may have to
disable those for now, for instance.

Thanks for any thoughts!

+n
teor
2017-12-04 06:10:48 UTC
Permalink
Post by Nathan Freitas
I am currently supporting the iCepa project, an effort to get Tor to run
as a Network Extension VPN on iOS.
https://github.com/iCepa/iCepa
The good news is that, after a long time, we have the whole thing
somewhat working. The bad news is that after browsing a few pages
through Tor, the extension is shutdown due to going over the extremely
https://forums.developer.apple.com/thread/73148
https://developer.apple.com/documentation/networkextension
My question is, does anyone else have experience running Tor within some
extreme memory limits? Any guidance on configuring torrc for this? Any
thoughts on build flags or changes that might reduce memory usage?
Do memory-mapped files count towards the limit?

If not, there is a patch on trac that memory-maps most of Tor's RAM:
https://trac.torproject.org/projects/tor/ticket/7176

And a ticket that attempts to make this more efficient:
https://trac.torproject.org/projects/tor/ticket/22704

You may also want to consider lowering MaxMemInQueues, if the issue only
occurs once you have sent some data.

Or you might want to lower the descriptor expiry time (I can't find an
option for this, it may be hard-coded), to stop microdescriptors adding
up over time.

Setting LearnCircuitBuildTimeout 0 will also reduce the number of circuits
you build, at the cost of poor performance if the actual timeout differs
from the default. The other *Timeout options and KeepalivePeriod may also
help here. Also, check out the ConnectionPadding option, which will send
more data to hide the actual client data. It might use more RAM.

There are other options like ConstrainedSockets and ConstrainedSockSize,
but it depends whether kernel network socket buffers count towards the
limits.

It would be useful to know what the majority of RAM is being used for.
Is it the consensus? Microdescriptors? Circuits?

You could probably get away with removing all the non-fast relays from
the consensus and removing their microdescs. But this might make your
client stand out.
Post by Nathan Freitas
We have already identified that the new compression features available
in recent versions of Tor consume more memory, and we may have to
disable those for now, for instance.
They should be disabled automatically if you build without the relevant
libraries.

I'm not sure if there is a way to disable the consensus diff code.
Is it causing increased RAM usage as well?

T

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
------------------------------------------------------------------------
Loading...