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 wrote: > 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 : > > 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, 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 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 (opensm
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 : > 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, 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 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
