Memory leak (kind of) fix
- objectsKnownToThem is supposed to track if it's necessary to send inv commands to a peer - it is supposed to enter garbage collection after 1 hour (ObjectTracker.trackingExpires) - due to peer not announcing all objects, or announcing them before we announce, this contains excessive number of entries after connection is fully established. - profiling revealed that this creates unnecessary memory to be kept allocated - this patch will prevent tracking of entries sent during bigInv, reducing the memory "leak" - it is possible, in theory, that this does have some negative effect, like increased bandwidth or neglecting to announce some invs. It probably doesn't though as my review of objectsKnownToThem occurrences didn't reveal any such case, and since the dict didn't track fully accurately anyway (so it would have already been broken if it was a problem), I consider it an acceptable risk at the moment. If it indeed causes problems, they can be solved separately - I tested this on one of the bootstrap servers with little memory, and it increased the number of connections than can be handled by a factor of about 3.5
This commit is contained in:
parent
50ccb897fc
commit
0c9cb4824d
|
@ -172,7 +172,7 @@ class TCPConnection(BMProto, TLSDispatcher):
|
||||||
if Dandelion().hasHash(objHash):
|
if Dandelion().hasHash(objHash):
|
||||||
continue
|
continue
|
||||||
bigInvList[objHash] = 0
|
bigInvList[objHash] = 0
|
||||||
self.objectsNewToThem[objHash] = time.time()
|
#self.objectsNewToThem[objHash] = time.time()
|
||||||
objectCount = 0
|
objectCount = 0
|
||||||
payload = b''
|
payload = b''
|
||||||
# Now let us start appending all of these hashes together. They will be
|
# Now let us start appending all of these hashes together. They will be
|
||||||
|
|
Loading…
Reference in New Issue
Block a user