Hello again, Sorry for quite late to reply, hope you has found something useful to fix the smsbox. I send the valgrind checking for opensmppbox as promised. Although greatly appreciate what kannel development team doing, but opensmppbox drains your memory 10 times faster than smsbox, plus some bug remain, the box only appropriate to use in the test bed environment.
*==31087== LEAK SUMMARY:==31087== definitely lost: 78,944 bytes in 4,882 blocks==31087== indirectly lost: 4,911,232 bytes in 4,859 blocks==31087== possibly lost: 48,496 bytes in 74 blocks==31087== still reachable: 3,124,401 bytes in 26,735 blocks==31087== suppressed: 0 bytes in 0 blocks==31087== Reachable blocks (those to which a pointer was found) are not shown.==31087== To see them, rerun with: --leak-check=full --show-leak-kinds=all==31087== ==31087== For counts of detected and suppressed errors, rerun with: -v==31087== ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 45 from 10)* On Wed, Apr 9, 2014 at 1:33 PM, Hanh Le Bich <hanhmi...@gmail.com> wrote: > Hi, > Here is the valgrind log for smsbox, i will do the same with opensmppbox > soon. Not sure leak check is fine enough, if you want more like a mem check > tools,... please let me know. > > Let me describe a littler 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). > > Cause the broadcast purpose, 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. > > 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)* > > Regard, Hanh. > > > > > > > > > On Sun, Apr 6, 2014 at 1:25 AM, spameden <spame...@gmail.com> wrote: > >> >> >> >> 2014-04-05 13:22 GMT+04:00 Hanh Le Bich <hanhmi...@gmail.com>: >> >> Yes, the current revision SVN is not stable enough, especially memory >>> leaking issue of smsbox which have not been solved. It does not happen in >>> ver 1.4.3. >>> Also opensmppbox also has memory issue too. >>> >> >> Can you run valgrind over smsbox/opensmppbox and report back? >> >> >>> >>> >>> Regards, Hanh. >>> >>> ------------------------------ >>>> >>>> Message: 6 >>>> Date: Sat, 5 Apr 2014 10:26:55 +1300 >>>> From: Mashed Updata <mashed.upd...@gmail.com> >>>> To: users@kannel.org >>>> Subject: Re: 2 Questions re Redis/Debian. >>>> Message-ID: >>>> < >>>> cakfe-apnd8pupftagt716v-7nnpunf0qcczi8sbsnwifmav...@mail.gmail.com> >>>> Content-Type: text/plain; charset="iso-8859-1" >>>> >>>> >>>> Thanks Milan, me too. I'm not sold on the idea of using SVN for bleeding >>>> edge applications unless you are a developer or a truly hard soul. >>>> >>>> >>>> On 5 April 2014 06:10, Milan P. Stanic <m...@arvanta.net> wrote: >>>> >>>> > On Fri, 2014-04-04 at 17:33, Mashed Updata wrote: >>>> > > 1. What real advantages does Redis offer to a non-commercial user of >>>> > Kannel? >>>> > > >>>> > > 2. Any idea when the .deb version of Kannel will catch up to the SVN >>>> > > version? >>>> > >>>> > I thought about that i.e. to build .debs from SVN. >>>> > But which revision from SVN is 'good enough' to roll into Debian >>>> > package? >>>> > I have a hope that we will see another stable Kannel release soon. >>>> > >>>> > -- >>>> > Kind Re: 2 Questions re Redis/Debian. >>>> >>>> > -------------------------------------------------- >>>> > Arvanta, http://www.arvanta.net >>>> > Please do not send me e-mail containing HTML code or documents in >>>> > proprietary format (word, excel, pps and so on) >>>> > >>>> > >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> http://www.kannel.org/pipermail/users/attachments/20140405/13caa3d5/attachment.html >>>> > >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> users mailing list >>>> users@kannel.org >>>> http://www.kannel.org/mailman/listinfo/users >>>> >>>> >>>> ------------------------------ >>>> >>>> End of users Digest, Vol 92, Issue 7 >>>> ************************************ >>>> >>> >>> >> >
==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 blocks are definitely lost in loss record 577 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 0x805D6FD: 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== 144 bytes in 1 blocks are possibly lost in loss record 610 of 813 ==31087== at 0x402574D: calloc (vg_replace_malloc.c:618) ==31087== by 0x40111FB: _dl_allocate_tls (dl-tls.c:300) ==31087== by 0x46FA5A0: pthread_create@@GLIBC_2.1 (allocatestack.c:580) ==31087== by 0x4412F2A: my_thread_global_init (in /usr/lib/i386-linux-gnu/libmysqlclient.so.18.0.0) ==31087== by 0x44112F7: my_init (in /usr/lib/i386-linux-gnu/libmysqlclient.so.18.0.0) ==31087== by 0x43EC93A: mysql_server_init (in /usr/lib/i386-linux-gnu/libmysqlclient.so.18.0.0) ==31087== by 0x43EE078: mysql_init (in /usr/lib/i386-linux-gnu/libmysqlclient.so.18.0.0) ==31087== by 0x8094F42: mysql_open_conn (dbpool_mysql.c:84) ==31087== by 0x80952C5: dbpool_increase (dbpool.c:194) ==31087== by 0x80953F6: dbpool_create (dbpool.c:160) ==31087== by 0x805B2B3: dlr_init_mysql (dlr_mysql.c:452) ==31087== by 0x8058AF3: dlr_init (dlr.c:254) ==31087== ==31087== 400 (256 direct, 144 indirect) bytes in 16 blocks are definitely lost in loss record 680 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 0x805474D: run_smppbox (opensmppbox.c:2105) ==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== 2,160 bytes in 15 blocks are possibly lost in loss record 755 of 813 ==31087== at 0x402574D: calloc (vg_replace_malloc.c:618) ==31087== by 0x40111FB: _dl_allocate_tls (dl-tls.c:300) ==31087== by 0x46FA5A0: pthread_create@@GLIBC_2.1 (allocatestack.c:580) ==31087== by 0x8097F4F: gwthread_create_real (gwthread-pthread.c:475) ==31087== by 0x80547B3: run_smppbox (opensmppbox.c:2124) ==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== 2,160 bytes in 15 blocks are possibly lost in loss record 756 of 813 ==31087== at 0x402574D: calloc (vg_replace_malloc.c:618) ==31087== by 0x40111FB: _dl_allocate_tls (dl-tls.c:300) ==31087== by 0x46FA5A0: pthread_create@@GLIBC_2.1 (allocatestack.c:580) ==31087== by 0x8097F4F: gwthread_create_real (gwthread-pthread.c:475) ==31087== by 0x8052F97: main (opensmppbox.c:2156) ==31087== ==31087== 3,020 (1,040 direct, 1,980 indirect) bytes in 13 blocks are definitely lost in loss record 762 of 813 ==31087== at 0x4027434: malloc (vg_replace_malloc.c:291) ==31087== by 0x80970B3: gw_native_malloc (gwmem-native.c:87) ==31087== by 0x80A0DEF: gwlist_create_real (list.c:131) ==31087== by 0x805FC8C: sms_split (sms.c:339) ==31087== by 0x805517E: run_smppbox (opensmppbox.c:1008) ==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== 44,032 bytes in 43 blocks are possibly lost in loss record 798 of 813 ==31087== at 0x4027434: malloc (vg_replace_malloc.c:291) ==31087== by 0x40275BA: realloc (vg_replace_malloc.c:687) ==31087== by 0x809722B: gw_native_realloc (gwmem-native.c:115) ==31087== by 0x80A35EB: octstr_grow (octstr.c:192) ==31087== by 0x80A64B3: octstr_insert_data (octstr.c:1469) ==31087== by 0x80A672A: octstr_append_data (octstr.c:1499) ==31087== by 0x80A90F9: octstr_format_valist_real (octstr.c:2486) ==31087== by 0x80A9366: octstr_format (octstr.c:2469) ==31087== by 0x80534F5: boxc_route_msg_to_smsc (opensmppbox.c:1791) ==31087== by 0x8057AAE: smpp_to_bearerbox (opensmppbox.c:1638) ==31087== by 0x80983AE: new_thread (gwthread-pthread.c:385) ==31087== by 0x46F9C38: start_thread (pthread_create.c:304) ==31087== ==31087== 4,986,528 (77,472 direct, 4,909,056 indirect) bytes in 4,842 blocks are definitely lost in loss record 813 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 0x80A3916: octstr_create_real (octstr.c:245) ==31087== by 0x80A908E: octstr_format_valist_real (octstr.c:2480) ==31087== by 0x80A9366: octstr_format (octstr.c:2469) ==31087== by 0x80534F5: boxc_route_msg_to_smsc (opensmppbox.c:1791) ==31087== by 0x8057AAE: smpp_to_bearerbox (opensmppbox.c:1638) ==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== LEAK SUMMARY: ==31087== definitely lost: 78,944 bytes in 4,882 blocks ==31087== indirectly lost: 4,911,232 bytes in 4,859 blocks ==31087== possibly lost: 48,496 bytes in 74 blocks ==31087== still reachable: 3,124,401 bytes in 26,735 blocks ==31087== suppressed: 0 bytes in 0 blocks ==31087== Reachable blocks (those to which a pointer was found) are not shown. ==31087== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==31087== ==31087== For counts of detected and suppressed errors, rerun with: -v ==31087== ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 45 from 10)
