Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Memory Leak: Uses 3GB+

by vek (Prior)
on Jan 15, 2009 at 21:19 UTC ( #736675=note: print w/replies, xml ) Need Help??


in reply to Memory Leak: Uses 3GB+

The code you posted accepts 5 arguments on the command line, performs an insert into a database, then exits. I don't see how this could leak memory. If you had a long running process that looped over a large amount of data and you saw the memory usage of your program increase as it ran, that would indicate a leak.

Keep an eye on just your process when running top

-- vek --

Replies are listed 'Best First'.
Re^2: Memory Leak: Uses 3GB+
by kilimanjaro (Initiate) on Jan 17, 2009 at 10:03 UTC
    Thanks All for your reply. Was in transit for a day. The reason why im pointing perl is because i tried to disable it from the calling script (Asterisk PBX dialplan) and reboot the system. I then run for like 12 hours and the memory usage was as low as constant 350MB. I however couldnt keep on disabling as all are running on the production server to collect IVR statistics on different node. The script process about 100,000 request a day If any more info is required i will be glad to share for resolution Kind regards Kili

      Can you not get a full top listing that shows the memory allocated to the individual processes?

      My guess is that some or all of those other processes are dormant but non-zombied copies of your script that are not exiting. If each copy uses a modest 30MB and you have 100 of them sitting around in memory doing nothing, that will give your 3GB total memory usage.


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
        Thanks

        I have just restarted the server and shall post as soon as mem get full again

        Kili

        Check this out when running valgrind memory test on the previous posted perl script

        ==28945== Memcheck, a memory error detector. ==28945== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et +al. ==28945== Using LibVEX rev 1878, a library for dynamic binary translat +ion. ==28945== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==28945== Using valgrind-3.4.0, a dynamic binary instrumentation frame +work. ==28945== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et +al. ==28945== For more details, rerun with: -v ==28945== ==28945== ==28945== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 29 from + 2) ==28945== malloc/free: in use at exit: 1,488,425 bytes in 28,258 block +s. ==28945== malloc/free: 47,397 allocs, 19,139 frees, 16,246,146 bytes a +llocated. ==28945== For counts of detected errors, rerun with: -v ==28945== searching for pointers to 28,258 not-freed blocks. ==28945== checked 2,423,200 bytes. ==28945== ==28945== 5 bytes in 1 blocks are definitely lost in loss record 1 of +18 ==28945== at 0x4004A41: malloc (vg_replace_malloc.c:207) ==28945== by 0x34D8E54: Perl_savesharedpv (in /usr/lib/perl5/5.8.5/ +i386-linux-thread-multi/CORE/libperl.so) ==28945== by 0x3486313: (within /usr/lib/perl5/5.8.5/i386-linux-thr +ead-multi/CORE/libperl.so) ==28945== by 0x348A23B: perl_parse (in /usr/lib/perl5/5.8.5/i386-li +nux-thread-multi/CORE/libperl.so) ==28945== by 0x8049339: main (in /usr/bin/perl) ==28945== ==28945== ==28945== 13,767 (1,299 direct, 12,468 indirect) bytes in 14 blocks ar +e definitely lost in loss record 9 of 18 ==28945== at 0x4004A41: malloc (vg_replace_malloc.c:207) ==28945== by 0x34D9BDA: Perl_safesysmalloc (in /usr/lib/perl5/5.8.5 +/i386-linux-thread-multi/CORE/libperl.so) ==28945== by 0x351D46F: Perl_new_stackinfo (in /usr/lib/perl5/5.8.5 +/i386-linux-thread-multi/CORE/libperl.so) ==28945== by 0x3483D8A: Perl_init_stacks (in /usr/lib/perl5/5.8.5/i +386-linux-thread-multi/CORE/libperl.so) ==28945== by 0x34841CB: perl_construct (in /usr/lib/perl5/5.8.5/i38 +6-linux-thread-multi/CORE/libperl.so) ==28945== by 0x80492EE: main (in /usr/bin/perl) ==28945== ==28945== ==28945== 7,472 bytes in 3 blocks are definitely lost in loss record 1 +2 of 18 ==28945== at 0x4006081: realloc (vg_replace_malloc.c:429) ==28945== by 0x34DA8EB: Perl_safesysrealloc (in /usr/lib/perl5/5.8. +5/i386-linux-thread-multi/CORE/libperl.so) ==28945== by 0x351D7C8: Perl_savestack_grow (in /usr/lib/perl5/5.8. +5/i386-linux-thread-multi/CORE/libperl.so) ==28945== by 0x351E42C: Perl_save_I32 (in /usr/lib/perl5/5.8.5/i386 +-linux-thread-multi/CORE/libperl.so) ==28945== by 0x34C3FDB: Perl_pad_block_start (in /usr/lib/perl5/5.8 +.5/i386-linux-thread-multi/CORE/libperl.so) ==28945== by 0x34B24C9: Perl_block_start (in /usr/lib/perl5/5.8.5/i +386-linux-thread-multi/CORE/libperl.so) ==28945== by 0x34AEBA5: Perl_yyparse (in /usr/lib/perl5/5.8.5/i386- +linux-thread-multi/CORE/libperl.so) ==28945== by 0x35295CB: (within /usr/lib/perl5/5.8.5/i386-linux-thr +ead-multi/CORE/libperl.so) ==28945== by 0x352AF7C: Perl_pp_require (in /usr/lib/perl5/5.8.5/i3 +86-linux-thread-multi/CORE/libperl.so) ==28945== by 0x34D7DDC: Perl_runops_debug (in /usr/lib/perl5/5.8.5/ +i386-linux-thread-multi/CORE/libperl.so) ==28945== by 0x3482AE5: (within /usr/lib/perl5/5.8.5/i386-linux-thr +ead-multi/CORE/libperl.so) ==28945== by 0x3488E6A: Perl_call_sv (in /usr/lib/perl5/5.8.5/i386- +linux-thread-multi/CORE/libperl.so) ==28945== ==28945== ==28945== 144,708 bytes in 14 blocks are possibly lost in loss record +17 of 18 ==28945== at 0x4004A41: malloc (vg_replace_malloc.c:207) ==28945== by 0x34D9BDA: Perl_safesysmalloc (in /usr/lib/perl5/5.8.5 +/i386-linux-thread-multi/CORE/libperl.so) ==28945== by 0x34E4DE7: Perl_reentrant_init (in /usr/lib/perl5/5.8. +5/i386-linux-thread-multi/CORE/libperl.so) ==28945== by 0x34843F0: perl_construct (in /usr/lib/perl5/5.8.5/i38 +6-linux-thread-multi/CORE/libperl.so) ==28945== by 0x80492EE: main (in /usr/bin/perl) ==28945== ==28945== LEAK SUMMARY: ==28945== definitely lost: 8,776 bytes in 18 blocks. ==28945== indirectly lost: 12,468 bytes in 27 blocks. ==28945== possibly lost: 144,708 bytes in 14 blocks. ==28945== still reachable: 1,322,473 bytes in 28,199 blocks. ==28945== suppressed: 0 bytes in 0 blocks. ==28945== Reachable blocks (those to which a pointer was found) are no +t shown. ==28945== To see them, rerun with: --leak-check=full --show-reachable= +yes

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://736675]
help
Chatterbox?
[marto]: Eily you can't remote connect the physical device via USB ;)
[Corion]: Eily: Sure, that's what I do, but some things you need to do on the Android device directly, like when navigating the bootloader :-)
[Eily]: marto you just need a longer cable :P
[Corion]: marto: Yeah, but I'm somewhat wary of installing random USB drivers downloaded from mega.nz , Google Drive or whatever, so Linux wins there due to there being no conflicts and me just having to edit one text file in the worst case, to add the USB vendor
[hippo]: Long USB cable FTW.
[Corion]: Eily: I've thought of that, but I don't like running long cables through the appartment because sooner or later I'll trip over it, pulling at least one device off its stand :)
[marto]: hmm, may have to patch CPAN::Meta to move from search.cpan to metacpan in the META.json/yml files
[Corion]: marto: Heh - it seems that they plan to keep the search.cpan.org links alive for a long time. But still, I plan on moving PM to use/generate the new links
[Corion]: And I think it's better to generate links to the new world instead of keeping the older links alive by generating new versions of them ;)
[marto]: yeah, I guess it's supposed to be a permanent redirect, but better to make the move where possible

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (12)
As of 2018-05-23 09:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?