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
On 1 Dec 2017, at 15:48, Nathan Freitas nathan@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 ------------------------------------------------------------------------
-
Nathan Freitas -
teor