Hi
I think you should do better in creating a new thread for this issue
since subject has "nothing to" do with this new issue. Also, post this
to de...@kannel.org instead of users@kannel.org
Regards
Alvaro
|-----------------------------------------------------------------------------------------------------------------|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier
celular y Nextel
en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via
SMS y GPRS online
Visitenos en www.perusms.com
On Wed, Apr 23, 2014 at 3:41 AM, Hanh Le Bich <hanhmi...@gmail.com> wrote:
> 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
>>>>> ************************************
>>>>
>>>>
>>>
>>
>
