From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2MF3GZD012179 for ; Thu, 22 Mar 2012 16:03:17 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsDABQ+a0/ZSMD3jWdsb2JhbABEtiQEgRIiAQEBAQkJCwkSBSSCCQEBBAEyAUYFCwshJQ8BBA0bIRMah2sJB7hkiW2BFIVjBJs6hVSHYQ X-IronPort-AV: E=Sophos;i="4.73,630,1325458800"; d="scan'208";a="150738697" Received: from fmmailgate06.web.de ([217.72.192.247]) by mail1-smtp-roc.national.inria.fr with ESMTP; 22 Mar 2012 16:03:16 +0100 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate06.web.de (Postfix) with ESMTP id 818F5100CC0B for ; Thu, 22 Mar 2012 16:03:16 +0100 (CET) Received: from frosties.localnet ([95.208.118.96]) by smtp.web.de (mrweb001) with ESMTPA (Nemesis) id 0LwZA7-1SM9BD0h1L-018FHh; Thu, 22 Mar 2012 16:03:16 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.77) (envelope-from ) id 1SAjXn-0005rh-8k; Thu, 22 Mar 2012 16:03:15 +0100 From: Goswin von Brederlow To: Hans Ole Rafaelsen Cc: caml-list@inria.fr References: Date: Thu, 22 Mar 2012 16:03:14 +0100 In-Reply-To: (Hans Ole Rafaelsen's message of "Wed, 21 Mar 2012 10:49:22 +0100") Message-ID: <874ntgadal.fsf@frosties.localnet> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V02:K0:MQj0OmxXYhLxpzcgYP9dbbUm0r0WzGr1xlom/Fw2aFW myvmAI9P2epkmTX7ygpQEVdZUXSZ4BRJUAdrb2vdrg2buV9Q5o 3oLrVkFREl/kTQnbQZ05bi2Fcgh6RbdKLGS0QqQEMwFxi/3/o4 6f+nIHwHtEN3jH2r7DygxFRpJf+j98TfC95NxtY8IoYvSSFYMh NTov/njyLHRkDZp02YcPg== Subject: Re: [Caml-list] Strategies for finding memory leaks 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