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 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) > > Regards > > > > > >