[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24857 [Core Tor/Tor]: tor 0.3.1.9 100% cpu load
#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 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 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).
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?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24857#comment:33>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs