Opened 13 years ago

Last modified 7 years ago

#344 closed defect (Won't implement)

tor terminates when running out of memory

Reported by: sn Owned by: nickm
Priority: Low Milestone: post 0.2.0.x
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: sn, nickm, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I am running a tor 0.1.1.24-1sarge.1 server on a virtual server (OpenVZ).
One thing about OpenVZ is that the amount of memory available to the virtual machine varies all the time.
The server shuts down when it runs out of memory:

Logfile entry:
Oct xx xx:xx:xx.xxx [err] _tor_realloc(): Out of memory. Dying.

I would like tor to keep running when it runs out of memory - perhaps it can just close a few connections,
stop accepting new connections for a while, discard some buffers etc?

Tor terminating because it runs out of memory is not listed at
http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#head-43d0c843cb6c453ad1231c48c11196a46fae9540
so I think perhaps this is a bug?

[Automatically added by flyspray2trac: Operating System: Other Linux]

Child Tickets

Change History (8)

comment:1 Changed 13 years ago by arma

Well, I fixed the FAQ entry to mention that Tor will exit cleanly
when it notices it's out of memory.

This isn't quite what you wanted though. :)

It seems a hard problem to me in general -- first because it's hard
to get a handle on how much memory is available, and hard to know what
to free (if we know there's something we don't need, we already free
it, so this would be intentionally degrading performance), and second
because the Linux OOM killer is not a graceful beast, so I imagine we'd
get diminishing returns pretty quickly.

Thoughts from others?

comment:2 Changed 13 years ago by sn

Perhaps a parameter could be added that tells tor not to grow beyond a certain size?
Most virtual server do guarantee a minimum amount of RAM.

comment:3 Changed 12 years ago by nickm

Most of Tor's memory is used in network buffers. Since I'm hoping to substantially
revise the buffer code in the next series, I'm marking this item as "post 0.1.2.x".

Of course, the problem about overcommitting remains: on lots of OSs, you don't get
a NULL malloc return on failure; you just get killed.

comment:4 Changed 12 years ago by nickm

Tor 0.2.0.1-alpha and later will use _*way*_ less RAM than 0.1.2.x, assuming I've done
the memory pool logic, the cell queue logic, and the slack buffer logic correctly.

I'm therefore going to postpone a final fix till 0.2.1.x or later.

comment:5 Changed 11 years ago by arma

Hi Nick!

It's been over a year since any comments on this bug.

And on some OSes we know we can't do anything about it, since we won't
even get notified when we're out of memory.

What "final fix" did you have in mind? Or should we just close the bug
as a won't-fix?

comment:6 Changed 11 years ago by nickm

I think our existing solution is probably as good as we can get: "don't use so much RAM."

On some OSs (ones that don't overcommit), you can handle OOM, but avoiding OOM is really a better idea.

comment:7 Changed 11 years ago by nickm

flyspray2trac: bug closed.

comment:8 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.