[tor-bugs] #24857 [Core Tor/Tor]: tor 0.3.1.9 100% cpu load

[Tor Bug Tracker & Wiki]

#24857: tor 0.3.1.9 100% cpu load
-------------------------------------------------+-------------------------
 Reporter:  Eugene646                            |          Owner:  (none)
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.1.9
 Severity:  Normal                               |     Resolution:
 Keywords:  cpu, windows, linux, performance,    |  Actual Points:
  regression, 033-triage-20180326,               |
  033-removed-20180326, 034-deferred-20180602,   |
  035-removed-20180711, 032-backport-maybe, 033  |
  -backport-maybe, 034-backport                  |
Parent ID:  #25500                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:33 mestriga]:
 > On Windows the limit on the number of files is not even enforced (see
 "consensus_cache_may_overallocate(consensus_cache_t *cache)" in
 conscache.c).

 The limit on the number of files in the cache directory isn't enforced,
 but the limit on the number of files used by the cache is.

 > The conditional code for Windows (#define MUST_UNMAP_TO_UNLINK) made the
 code harder to read, and a cleaner solution is possible (with the files
 still mapped, marking them for deletion on close, while possibly moving
 them to another directory).

 Do you have a patch you would like to suggest?

 > Is there a purpose in limiting the number of files in the cache
 directory for all nodes (both Windows and Linux), preventing them from
 storing 72  hour of diffs, even when not running sandboxed?

 I don't know if a higher limit would cause issues if users toggle the
 sandbox setting. But it would still be ok to have a higher limit on
 platforms without seccomp2 (BSD, macOS, and Windows).

 Limiting the number of files in the cache directory also limits the disk
 space used by the relay, and reduces the amount of CPU used to create
 diffs every hour.

 So if we increase the limit, we should consider whether having 72 hours of
 diffs is actually that helpful. Maybe we could get away with 24 hours of
 diffs.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24857#comment:34>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online