From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <john@ispsystem.com>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,SPF_SOFTFAIL 
	autolearn=disabled version=3.1.3
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by yquem.inria.fr (Postfix) with ESMTP id 61CF9BB84
	for <caml-list@yquem.inria.fr>; Mon, 12 Jan 2009 16:05:50 +0100 (CET)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAGPraklSkiEx/2dsb2JhbADScIVv
X-IronPort-AV: E=Sophos;i="4.37,253,1231110000"; 
   d="scan'208";a="33622297"
Received: from 5070.info ([82.146.33.49])
  by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jan 2009 16:05:50 +0100
X-Bogosity: Unsure, tests=bogofilter
Received: from [192.168.1.21] (92-124-51-69.pppoe.irtel.ru [92.124.51.69] (may be forged))
	(authenticated bits=0)
	by 5070.info (8.14.3/8.14.0) with ESMTP id n0CF5Q4e040732
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <caml-list@yquem.inria.fr>; Mon, 12 Jan 2009 15:05:48 GMT
	(envelope-from john@ispsystem.com)
Subject: Re: [Caml-list] memory usage
From: John Lepikhin <john@ispsystem.com>
To: caml-list@yquem.inria.fr
In-Reply-To: <20090112114837.GB18405@janestcapital.com>
References: <1231746106.4376.27.camel@john-laptop>
	 <20090112114837.GB18405@janestcapital.com>
Content-Type: text/plain
Date: Mon, 12 Jan 2009 23:05:20 +0800
Message-Id: <1231772720.4376.217.camel@john-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.2 
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (5070.info [82.146.33.49]); Mon, 12 Jan 2009 15:05:49 +0000 (UTC)
X-Spam: no; 0.00; lib:01 libc:01 lib:01 libc:01 2048:01 2048:01 gdb:01 anon:98 anon:98 threads:01 threads:01 partial:01 caml-list:01 grep:01 data:02 


> > Please, give me some start point to find the roots of the problem.
> I assume you're running on Linux.

I've got this issue on FreeBSD box. On Linux test box process grows only
up to 2MB (but there is no production data and clients). Here is partial
pmap output:

Address              Kbytes        RSS     Shared       Priv Mode
Mapped File
...
00000000408AA000        932        548        932          -
r-x   /lib/libc.so.7
0000000040993000          4          4          4          -
r-x   /lib/libc.so.7
0000000040994000       1020          0       1020          -
r-x   /lib/libc.so.7
0000000040A93000        116        116          -        116
rw-   /lib/libc.so.7
0000000040AB0000         92         44          -         92 rw-
[ anon ]
0000000040B00000       1024        904          -       1024 rw-
[ anon ]
0000000040C00000      34816      19652          -      34816 rw-
[ anon ]
0000000042E00000       1024        200          -       1024 rw-
[ anon ]
0000000042F00000       2048        400          -       2048 rw-
[ anon ]
00007FFFFB9BE000        128         20          -        128 rw-
[ anon ]
00007FFFFBBBF000        128         20          -        128 rw-
[ anon ]
...
---------------- ---------- ---------- ---------- ----------
Total Kb              48552      23736       4352      44528

Most of memory is allocated here:

0000000040C00000      34816      19652          -      34816 rw-
[ anon ]

It gets bigger and bigger:

0000000040C00000      34816      20660          -      34816 rw-
[ anon ]

0000000040C00000      34816      21216          -      34816 rw-
[ anon ]

> One other thing to check is to ensure that threads really are being killed
> at the times you expect.  (Check "/proc/<pid>/status | grep Threads", or use
> "gdb -p" to attach to the running process then "info thr".)

I checked it. Only valid threads run.