[tor-dev] Running Tor with a 15MB memory limit

[teor]

> On 1 Dec 2017, at 15:48, Nathan Freitas <nathan at freitas.net> wrote:
> 
> 
> 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?

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.

> 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
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171204/f9c3c249/attachment.sig>