Re: [Caml-list] Strategies for finding memory leaks

[Hans Ole Rafaelsen <hrafaelsen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3822 bytes --]

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 <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 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
>

[-- Attachment #2: Type: text/html, Size: 5173 bytes --]