Thanks Araq, right now I am using "clients" to avoid deallocating memory, so
that I can get peak memory use. In the future, it will be used to dispatch
messages to specific connected clients. This service should also remove clients
from that sequence when they disconnect. Sorry, I will try to clean up the code
so that the test makes more "sense", this may help me to find out which part is
allocating those extra 70MB (Sorry for the long post):
sudo pmap 26153
26153: httpasync/src/httpasync018
0000556fff75a000 124K r-x-- httpasync018
0000556fff978000 4K r---- httpasync018
0000556fff979000 4K rw--- httpasync018
0000556fff97a000 32K rw--- [ anon ]
0000557000ed2000 124K rw--- [ anon ]
00007f2806a93000 84164K rw--- [ anon ]
00007f280bcc4000 2172K r-x-- libgc.so.1.0.3
00007f280bee3000 4K r---- libgc.so.1.0.3
00007f280bee4000 4K rw--- libgc.so.1.0.3
00007f280bee5000 264K rw--- [ anon ]
00007f280bf2c000 548K r-x-- ld-musl-x86_64.so.1
00007f280bfbc000 1472K rw--- [ anon ]
00007f280c12c000 4K r--s- localtime
00007f280c12f000 8K ----- [ anon ]
00007f280c131000 84K rw--- [ anon ]
00007f280c146000 8K ----- [ anon ]
00007f280c148000 84K rw--- [ anon ]
00007f280c15d000 8K ----- [ anon ]
00007f280c15f000 340K rw--- [ anon ]
00007f280c1b4000 4K r---- ld-musl-x86_64.so.1
00007f280c1b5000 4K rw--- ld-musl-x86_64.so.1
00007f280c1b6000 12K rw--- [ anon ]
00007ffdf4ad5000 132K rw--- [ pila ]
00007ffdf4b9c000 8K r---- [ anon ]
00007ffdf4b9e000 8K r-x-- [ anon ]
ffffffffff600000 4K r-x-- [ anon ]
total 89624K
versus 0.17.2
sudo pmap 26094
26094: httpasync/src/httpasync
000055b617f37000 104K r-x-- httpasync
000055b618150000 4K r---- httpasync
000055b618151000 4K rw--- httpasync
000055b618152000 28K rw--- [ anon ]
000055b6194e0000 120K rw--- [ anon ]
00007fe5853e4000 11648K rw--- [ anon ]
00007fe585f44000 2172K r-x-- libgc.so.1.0.3
00007fe586163000 4K r---- libgc.so.1.0.3
00007fe586164000 4K rw--- libgc.so.1.0.3
00007fe586165000 264K rw--- [ anon ]
00007fe5861ac000 548K r-x-- ld-musl-x86_64.so.1
00007fe586235000 1512K rw--- [ anon ]
00007fe5863af000 8K ----- [ anon ]
00007fe5863b1000 84K rw--- [ anon ]
00007fe5863c6000 8K ----- [ anon ]
00007fe5863c8000 84K rw--- [ anon ]
00007fe5863dd000 8K ----- [ anon ]
00007fe5863df000 340K rw--- [ anon ]
00007fe586434000 4K r---- ld-musl-x86_64.so.1
00007fe586435000 4K rw--- ld-musl-x86_64.so.1
00007fe586436000 12K rw--- [ anon ]
00007ffebaff6000 132K rw--- [ pila ]
00007ffebb124000 8K r---- [ anon ]
00007ffebb126000 8K r-x-- [ anon ]
ffffffffff600000 4K r-x-- [ anon ]
total 17116K
Anyway, I understand that it should work (leak) in a similar way regardless of
the gc or nim version used. There is a fixed number of clients that are
connecting, so that sequence will grow to 1000 and stop there. I am measuring
memory use after all clients (1000) have sent and received 1000 messages, so it
should not depend on the speed they are added.
jcosborn, I have been doing all tests with "official" docker images
(nimlang/nim:0.xx.y-alpine), and nimlang/nim:devel reports version 0.15.3. I
have been looking for the original Dockerfile of those images to build an
updated devel branch but it seems it is actually generated with nim code in a
very smart way I'll put some time on this and report back.
