Re: Does opensmppbox and smsbox have serious memory issues?
Hi, just checked daily snapshot, yes you can use it, this is uptodate. Alex Am 29.04.2014 um 04:44 schrieb Hanh Le Bich hanhmi...@gmail.com: Dear hbilman development team, I'm willing to help to provide more evident but i have no background to work in IT fields. Cause my server has no internet connection thus i cannot get the lastest SVN trunk. Normally i download source files via the daily snapshot, is it ok? Regards, Hanh. On Mon, Apr 28, 2014 at 12:25 AM, hbil...@ecommunicate.biz wrote: Hi Kannel developers, Hanh posted his Valgrind research to the user group for smsbox and opensmppbox. His results seem interesting and so I'm copying them to this thread so the Kannel developers can view them. These results can be viewed by following the thread on Wed, Apr 23, 2014 at 3:41 AM, by Hanh Le Bich hanhmi...@gmail.com with the Subject: Re: 2 Questions re Redis/Debian. (The email subject is not related to this issue.) His research shows that opensmppbox and smsbox may have serious memory issues. I use the word may as until others have confirmed his results, there could be a mistake somewhere. Is there anyone who has a test environment that can follow his approach and confirm for the Kannel community if opensmppbox and smsbox have serious memory issues or if his testing approach has flaws? His approach is: Let me describe a little bit for my application back end. It's pretty simple: i make a loop that for each second, it push an sms via kannel CGI for 1K mobile numbers, that mean throughput is 1000 msg/sec. My kannel configuration is simple too, it's only smsbox - bearerbox - SMSC (via smpp), no file storage, no SQL, no dlr (actually dlr-mask=8). I even don't expect the sms can deliver to all end users and the app run some hours per day only. That why i can play with the lasted SVN which don't care so much for the reliability. For smsbox: In the pass when using ver 1.4.3, it was fine for years. After upgrade to 1.5.0, after each few days, i realized smsbox is reset, then i found it exhaust my memory. It's funny that smsbox consume the mem and doesn't release. Example, if it occupies 50% your mem and you stop sms pushing, it will 50% forever except the box restarting. That's all, same server with no other tasks, same back end, just different kannel version. Just paste the valgrind sum in here: ==27581== LEAK SUMMARY: ==27581==definitely lost: 1,077,904 bytes in 67,369 blocks ==27581==indirectly lost: 673,660 bytes in 67,366 blocks ==27581== possibly lost: 160 bytes in 13 blocks ==27581==still reachable: 1,240 bytes in 39 blocks ==27581== suppressed: 0 bytes in 0 blocks ==27581== Reachable blocks (those to which a pointer was found) are not shown. ==27581== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==27581== ==27581== For counts of detected and suppressed errors, rerun with: -v ==27581== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 45 from 10) For opensmppbox opensmppbox drains your memory 10 times faster than smsbox ==31087== Memcheck, a memory error detector ==31087== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==31087== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==31087== Command: /usr/local/sbin/opensmppbox -v -d -- /etc/kannel/opensmppbox.conf ==31087== Parent PID: 31085 ==31087== ==31087== ==31087== HEAP SUMMARY: ==31087== in use at exit: 8,163,073 bytes in 36,550 blocks ==31087== total heap usage: 893,827 allocs, 857,277 frees, 295,662,079 bytes allocated ==31087== ==31087== 49 (32 direct, 17 indirect) bytes in 2 blocks are definitely lost in loss record 485 of 813 ==31087==at 0x4027434: malloc (vg_replace_malloc.c:291) ==31087==by 0x80970B3: gw_native_malloc (gwmem-native.c:87) ==31087==by 0x80A37A1: octstr_create_from_data_real (octstr.c:263) ==31087==by 0x80A3D81: octstr_duplicate_real (octstr.c:377) ==31087==by 0x808B106: cfg_get_real (cfg.c:670) ==31087==by 0x8052769: main (opensmppbox.c:2291) ==31087== ==31087== 79 (64 direct, 15 indirect) bytes in 4 blocks are definitely lost in loss record 529 of 813 ==31087==at 0x4027434: malloc (vg_replace_malloc.c:291) ==31087==by 0x80970B3: gw_native_malloc (gwmem-native.c:87) ==31087==by 0x80A37A1: octstr_create_from_data_real (octstr.c:263) ==31087==by 0x80A3D81: octstr_duplicate_real (octstr.c:377) ==31087==by 0x805D52F: msg_duplicate (msg-decl.h:80) ==31087==by 0x805651D: catenate_msg (opensmppbox.c:525) ==31087==by 0x805686B: check_multipart (opensmppbox.c:1481) ==31087==by 0x8057AD8: smpp_to_bearerbox (opensmppbox.c:1639) ==31087==by 0x80983AE: new_thread (gwthread-pthread.c:385) ==31087==by 0x46F9C38: start_thread (pthread_create.c:304) ==31087==by 0x482F78D: clone (clone.S:130) ==31087== ==31087== 100 (80 direct, 20 indirect) bytes in 5
Re: Does opensmppbox and smsbox have serious memory issues?
It's happy to get it now. Thank a lot. Regards, Tuan. On Tue, Apr 29, 2014 at 4:02 PM, Alexander Malysh amal...@kannel.orgwrote: Hi, just checked daily snapshot, yes you can use it, this is uptodate. Alex Am 29.04.2014 um 04:44 schrieb Hanh Le Bich hanhmi...@gmail.com: Dear hbilman development team, I'm willing to help to provide more evident but i have no background to work in IT fields. Cause my server has no internet connection thus i cannot get the lastest SVN trunk. Normally i download source files via the daily snapshot, is it ok? Regards, Hanh. On Mon, Apr 28, 2014 at 12:25 AM, hbil...@ecommunicate.biz wrote: Hi Kannel developers, Hanh posted his Valgrind research to the user group for smsbox and opensmppbox. His results seem interesting and so I'm copying them to this thread so the Kannel developers can view them. These results can be viewed by following the thread on Wed, Apr 23, 2014 at 3:41 AM, by Hanh Le Bich hanhmi...@gmail.com with the Subject: Re: 2 Questions re Redis/Debian. (The email subject is not related to this issue.) His research shows that opensmppbox and smsbox may have serious memory issues. I use the word may as until others have confirmed his results, there could be a mistake somewhere. Is there anyone who has a test environment that can follow his approach and confirm for the Kannel community if opensmppbox and smsbox have serious memory issues or if his testing approach has flaws? His approach is: Let me describe a little bit for my application back end. It's pretty simple: i make a loop that for each second, it push an sms via kannel CGI for 1K mobile numbers, that mean throughput is 1000 msg/sec. My kannel configuration is simple too, it's only smsbox - bearerbox - SMSC (via smpp), no file storage, no SQL, no dlr (actually dlr-mask=8). I even don't expect the sms can deliver to all end users and the app run some hours per day only. That why i can play with the lasted SVN which don't care so much for the reliability. For smsbox: In the pass when using ver 1.4.3, it was fine for years. After upgrade to 1.5.0, after each few days, i realized smsbox is reset, then i found it exhaust my memory. It's funny that smsbox consume the mem and doesn't release. Example, if it occupies 50% your mem and you stop sms pushing, it will 50% forever except the box restarting. That's all, same server with no other tasks, same back end, just different kannel version. Just paste the valgrind sum in here: ==27581== LEAK SUMMARY: ==27581==definitely lost: 1,077,904 bytes in 67,369 blocks ==27581==indirectly lost: 673,660 bytes in 67,366 blocks ==27581== possibly lost: 160 bytes in 13 blocks ==27581==still reachable: 1,240 bytes in 39 blocks ==27581== suppressed: 0 bytes in 0 blocks ==27581== Reachable blocks (those to which a pointer was found) are not shown. ==27581== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==27581== ==27581== For counts of detected and suppressed errors, rerun with: -v ==27581== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 45 from 10) For opensmppbox opensmppbox drains your memory 10 times faster than smsbox ==31087== Memcheck, a memory error detector ==31087== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==31087== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==31087== Command: /usr/local/sbin/opensmppbox -v -d -- /etc/kannel/opensmppbox.conf ==31087== Parent PID: 31085 ==31087== ==31087== ==31087== HEAP SUMMARY: ==31087== in use at exit: 8,163,073 bytes in 36,550 blocks ==31087== total heap usage: 893,827 allocs, 857,277 frees, 295,662,079 bytes allocated ==31087== ==31087== 49 (32 direct, 17 indirect) bytes in 2 blocks are definitely lost in loss record 485 of 813 ==31087==at 0x4027434: malloc (vg_replace_malloc.c:291) ==31087==by 0x80970B3: gw_native_malloc (gwmem-native.c:87) ==31087==by 0x80A37A1: octstr_create_from_data_real (octstr.c:263) ==31087==by 0x80A3D81: octstr_duplicate_real (octstr.c:377) ==31087==by 0x808B106: cfg_get_real (cfg.c:670) ==31087==by 0x8052769: main (opensmppbox.c:2291) ==31087== ==31087== 79 (64 direct, 15 indirect) bytes in 4 blocks are definitely lost in loss record 529 of 813 ==31087==at 0x4027434: malloc (vg_replace_malloc.c:291) ==31087==by 0x80970B3: gw_native_malloc (gwmem-native.c:87) ==31087==by 0x80A37A1: octstr_create_from_data_real (octstr.c:263) ==31087==by 0x80A3D81: octstr_duplicate_real (octstr.c:377) ==31087==by 0x805D52F: msg_duplicate (msg-decl.h:80) ==31087==by 0x805651D: catenate_msg (opensmppbox.c:525) ==31087==by 0x805686B: check_multipart (opensmppbox.c:1481) ==31087==by 0x8057AD8: smpp_to_bearerbox (opensmppbox.c:1639) ==31087==by 0x80983AE: new_thread (gwthread-pthread.c:385) ==31087==by 0x46F9C38:
