From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2N9X45Q016728 for ; Fri, 23 Mar 2012 10:33:04 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUCABpCbE/RVdK2kWdsb2JhbABErwwBiGIIIgEBAQEJCQ0HEimCCQEBAQMBEgIsARsdAQMBCwYFCzshAQERAQUBHAYTGgiHYwULmjEKjBaCcYR7P4h2AQULiWJxhiUElV+LL4MaPYQKgVM X-IronPort-AV: E=Sophos;i="4.73,636,1325458800"; d="scan'208";a="137389421" Received: from mail-iy0-f182.google.com ([209.85.210.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 23 Mar 2012 10:32:58 +0100 Received: by iahk25 with SMTP id k25so7572645iah.27 for ; Fri, 23 Mar 2012 02:32:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nNe7hfKKsujFWLOOV0PQQPy4DVaqNzQhfAAiX1Sby7o=; b=EdS6Bvt08qreEGNufaZ6lGtQlBg9XmkuaCQ3hmjd1dG7OiFgy1Q37dPO48PXkWEvQG nxNUuyrmuP1WE6BU2BUCQ1TOZ5TTTYYmkfv02t+w3X12Khsj1HNb2/Q4QVNha7rJYLTH nCmbKVkbTzr4fPUajvVYsfxzAOAu0rgmRv4XBIImxJGjZIentOldn64p+X17D1BArbZm Md6Vh5tYKfw824NJUb546xGGPGU9HDscwRqbIIDVZtKjq1ztiN9riiusXGtEmQVjnEF2 brlXP47CicYBHXI0OZvUwsWpjh2NQ09WZFIZjgGKB0cgImJjnSn+szZzQ4SvpR/YCAC6 VLUQ== MIME-Version: 1.0 Received: by 10.50.45.234 with SMTP id q10mr1358214igm.54.1332495176980; Fri, 23 Mar 2012 02:32:56 -0700 (PDT) Received: by 10.42.117.67 with HTTP; Fri, 23 Mar 2012 02:32:56 -0700 (PDT) In-Reply-To: <874ntgadal.fsf@frosties.localnet> References: <874ntgadal.fsf@frosties.localnet> Date: Fri, 23 Mar 2012 10:32:56 +0100 Message-ID: From: Hans Ole Rafaelsen To: Goswin von Brederlow Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=14dae93403d7b0585904bbe5b591 Subject: Re: [Caml-list] Strategies for finding memory leaks --14dae93403d7b0585904bbe5b591 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have tried to trigger Gc.compact but that only have limited effect for a short time. Hans Ole On Thu, Mar 22, 2012 at 4:03 PM, Goswin von Brederlow wrote: > Hans Ole Rafaelsen writes: > > > Hello, > > > > Is there some tools / tricks that can be used to help find memory leaks? > > > > I have trouble with an application, that when running for a long time, > starts > > to use a lot of CPU and consume more memory. It starts out by using > about 20% > > CPU (reported by top) and after 24 hours it has increased to 80% usage. > Also > > physical (RES) memory usage goes from 80M to 160M. The workload for the > > application is the same the whole time. > > > > Using OProfile (http://oprofile.sourceforge.net/news/) shows that that > most of > > the time is being spent doing memory management. > > > > At startup: > > CPU: Core 2, speed 2667 MHz (estimated) > > Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a > unit mask > > of 0x00 (Unhalted core cycles) count 100000 > > samples % image name symbol name > > 52764 22.3913 vc_client.native mark_slice > > 33580 14.2502 vc_client.native caml_page_table_lookup > > 25415 10.7853 vc_client.native sweep_slice > > 10119 4.2942 vc_client.native caml_fl_allocate > > 6423 2.7257 [vdso] (tgid:9015 range:0x7fff4256c000-0x7fff4256d000) > [vdso] > > (tgid:9015 range:0x7fff4256c000-0x7fff4256d000) > > 5233 2.2207 vc_client.native > > camlLividisvc__Nalbuf_tools__replace_pattern_1033 > > 2759 1.1708 vc_client.native caml_iterate_global_roots > > 2728 1.1577 vc_client.native caml_modify > > 2473 1.0495 vc_client.native caml_oldify_one > > 2204 0.9353 vc_client.native > > camlLividisvc__Nalbuf_bytestream__search_1047 > > 2183 0.9264 vc_client.native caml_darken > > 1935 0.8212 vc_client.native caml_stash_backtrace > > 1843 0.7821 vc_client.native caml_do_roots > > 1838 0.7800 vc_client.native caml_delete_global_root > > > > After ca. 24 hours run: > > CPU: Core 2, speed 2667 MHz (estimated) > > Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a > unit mask > > of 0x00 (Unhalted core cycles) count 100000 > > samples % image name symbol name > > 1137401 56.2697 vc_client.native mark_slice > > 405598 20.0658 vc_client.native sweep_slice > > 399832 19.7806 vc_client.native caml_page_table_lookup > > 10106 0.5000 vc_client.native caml_fl_allocate > > 3548 0.1755 vc_client.native caml_iterate_global_roots > > 3397 0.1681 [vdso] (tgid:26129 > range:0x7fff747ff000-0x7fff74800000) > > [vdso] > > (tgid:26129 range:0x7fff747ff000-0x7fff74800000) > > 2797 0.1384 vc_client.native > > camlLividisvc__Nalbuf_tools__replace_ > > pattern_1033 > > 2307 0.1141 vc_client.native > > camlLividisvc__Nalbuf_bytestream__sea > > rch_1047 > > 2005 0.0992 vc_client.native caml_oldify_local_roots > > 1786 0.0884 vc_client.native caml_gc_stat > > 1441 0.0713 vc_client.native caml_oldify_one > > 1163 0.0575 vc_client.native caml_darken > > 1163 0.0575 vc_client.native caml_fl_merge_block > > 1032 0.0511 vc_client.native camlHashtbl__find_1093 > > > > The application uses several 3rd party libraries, including: LablGTK2, > > OCamlNet, LWT and others. > > > > Is there some clever trick that can by used to track down or get a hint > of what > > is causing this? > > > > Thanks, > > > > Hans Ole Rafaelsen > > Are you calling the GC manually somewhere in the code or in one of the > libs? > > MfG > Goswin > --14dae93403d7b0585904bbe5b591 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have tried to trigger Gc.compact but that only have limited ef= fect for a short time.

Hans Ole

On= Thu, Mar 22, 2012 at 4:03 PM, Goswin von Brederlow <<= a href=3D"mailto:goswin-v-b@web.de">goswin-v-b@web.de> wrote:=
Hans= Ole Rafaelsen <hrafaelsen@gmail= .com> writes:

> Hello,
>
> Is there some tools / tricks that can be used to help find memory leak= s?
>
> I have trouble with an application, that when running for a long time,= starts
> to use a lot of CPU and consume more memory. It starts out by using ab= out 20%
> CPU (reported by top) and after 24 hours it has increased to 80% usage= . Also
> physical (RES) memory usage goes from 80M to 160M. The workload for th= e
> application is the same the whole time.
>
> Using OProfile (http://oprofile.sourceforge.net/news/) shows that that mo= st of
> the time is being spent doing memory management.
>
> At startup:
> CPU: Core 2, speed 2667 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a = unit mask
> of 0x00 (Unhalted core cycles) count 100000
> samples=A0 %=A0=A0=A0=A0=A0=A0=A0 image name=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 symbol name
> 52764=A0=A0=A0 22.3913=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 mar= k_slice
> 33580=A0=A0=A0 14.2502=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 cam= l_page_table_lookup
> 25415=A0=A0=A0 10.7853=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 swe= ep_slice
> 10119=A0=A0=A0=A0 4.2942=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 c= aml_fl_allocate
> 6423=A0=A0=A0=A0=A0 2.7257=A0 [vdso] (tgid:9015 range:0x7fff4256c000-0= x7fff4256d000) [vdso]
> (tgid:9015 range:0x7fff4256c000-0x7fff4256d000)
> 5233=A0=A0=A0=A0=A0 2.2207=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0=
> camlLividisvc__Nalbuf_tools__replace_pattern_1033
> 2759=A0=A0=A0=A0=A0 1.1708=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0= caml_iterate_global_roots
> 2728=A0=A0=A0=A0=A0 1.1577=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0= caml_modify
> 2473=A0=A0=A0=A0=A0 1.0495=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0= caml_oldify_one
> 2204=A0=A0=A0=A0=A0 0.9353=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0
> camlLividisvc__Nalbuf_bytestream__search_1047
> 2183=A0=A0=A0=A0=A0 0.9264=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 caml_darken
> 1935=A0=A0=A0=A0=A0 0.8212=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 caml_stash_backtrace
> 1843=A0=A0=A0=A0=A0 0.7821=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 caml_do_roots
> 1838=A0=A0=A0=A0=A0 0.7800=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 caml_delete_global_root
>
> After ca. 24 hours run:
> CPU: Core 2, speed 2667 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a = unit mask
> of 0x00 (Unhalted core cycles) count 100000
> samples=A0 %=A0=A0=A0=A0=A0=A0=A0 image name=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 symbol name
> 1137401=A0 56.2697=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 mark_sl= ice
> 405598=A0=A0 20.0658=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 sweep= _slice
> 399832=A0=A0 19.7806=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 caml_= page_table_lookup
> 10106=A0=A0=A0=A0 0.5000= =A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 caml_fl_allocate
> 3548=A0=A0=A0=A0=A0 0.1755=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0 caml_iterate_global_roots
> 3397=A0=A0=A0=A0=A0 0.1681=A0 [vdso] (tgid:26129 range:0x7fff747ff000-0x7fff74800000)
> [vdso]
> =A0(tgid:26129 range:0x7fff747ff000-0x7fff74800000)
> 2797=A0=A0=A0=A0=A0 0.1384=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0
> camlLividisvc__Nalbuf_tools__replace_
> pattern_1033
> 2307=A0=A0=A0=A0=A0 0.1141=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0
> camlLividisvc__Nalbuf_bytestream__sea
> rch_1047
> 2005=A0=A0=A0=A0=A0 0.0992=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0= caml_oldify_local_roots
> 1786=A0=A0=A0=A0=A0 0.0884=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0= caml_gc_stat
> 1441=A0=A0=A0=A0=A0 0.0713=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0= caml_oldify_one
> 1163=A0=A0=A0=A0=A0 0.0575=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0= caml_darken
> 1163=A0=A0=A0=A0=A0 0.0575=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0= caml_fl_merge_block
> 1032=A0=A0=A0=A0=A0 0.0511=A0 vc_client.native=A0=A0=A0=A0=A0=A0=A0=A0= camlHashtbl__find_1093
>
> The application uses several 3rd party libraries, including: LablGTK2,=
> OCamlNet, LWT and others.
>
> Is there some clever trick that can by used to track down or get a hin= t of what
> is causing this?
>
> Thanks,
>
> Hans Ole Rafaelsen

Are you calling the GC manually somewhere in the code or in one= of the
libs?

MfG
=A0 =A0 =A0 =A0Goswin

--14dae93403d7b0585904bbe5b591--