[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zeromq-dev
Subject:    Re: [zeromq-dev] Big memory occupation with zmq_msg_init_data and zmq_msg_send after large number of
From:       Luca Boccassi <luca.boccassi () gmail ! com>
Date:       2017-05-03 12:49:26
Message-ID: 1493815766.11425.15.camel () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wed, 2017-05-03 at 09:56 +0000, Yan, Liming (Nokia - CN/Hangzhou)
wrote:
> Hi,
>       Anyone encountered this problem?    The process still occupies large
> physical memory when no any packets transmitting, after a turn of
> running of big traffic.    Seems some memory used by ZMQ not freed back
> to system. I'm wondering if this is normal or not?    Or anything wrong
> with me?    Thanks.
> 
> # ./zmq-mem-test -c -p 169.254.0.10 -l 512 -n 10000000
> Client started on tcp://169.254.0.10:5999.
> Actual sent msg count: 60000.
> 
> Total 9971945 freed in customized freer.
> 
> 20012 root            20      0 1950.1m 214.7m      0.0    1.8      0:05.03
> S                            `- zmq-mem-test
> 20012 root            20      0 1950.1m 214.7m      0.0    1.8      0:05.03
> S                            `- zmq-mem-test
> 
> The attached file is the example code with zero copy method
> zmq_msg_init_data and zmq_msg_send.    I'm just testing if all malloced
> memory from heap can be freed by asynchronous ZMQ handler. HWM is set
> with 30000 with no blocking sending, so many sending failed because
> of queue full.
> 
> ./zmq-mem-test -c -p 169.254.0.10 -l 512 -n 10000000
> ./zmq-mem-test -s -p 169.254.0.10
> 
> --------^_^--------
> Best Regards
> Yan Limin

Hi,

The test code has several errors:

1) It's passing a double pointer to zmq_ctx_shutdown and both
zmq_close, so they are not being called and lots of data is left
dangling
2) It's not initialising the zmq_msg_t in the server code before
calling zmq_msg_recv, so it's not actually receiving anything, add a
zmq_msg_init (&msg) before it
3) It's not calling zmq_ctx_term at the end. As the manpage of
zmq_ctx_shutdown says, that one is not mandatory and the _term is.

If you do these 3 changes then you'll see that Valgrind runs clean:

$ valgrind --leak-check=full ./test -c -p 127.0.0.1 -n 10000
==29787== Memcheck, a memory error detector
==29787== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==29787== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==29787== Command: ./lol -c -p 127.0.0.1 -n 10000
==29787==  
Client started on tcp://127.0.0.1:5999.
Actual sent msg count: 10000.  

Total 10000 freed in customized freer.
==29787==  
==29787== HEAP SUMMARY:
==29787==          in use at exit: 0 bytes in 0 blocks
==29787==      total heap usage: 20,243 allocs, 20,243 frees, 658,291,774 bytes allocated
==29787==  
==29787== All heap blocks were freed -- no leaks are possible
==29787==  
==29787== For counts of detected and suppressed errors, rerun with: -v
==29787== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Kind regards,
Luca Boccassi
["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[prev in list] [next in list] [prev in thread] [next in thread]