From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.5 required=5.0 tests=SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 22CA2BB84 for ; Mon, 12 Jan 2009 08:41:53 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG+CaklSkiEx/2dsb2JhbADSLoVv X-IronPort-AV: E=Sophos;i="4.37,252,1231110000"; d="scan'208";a="19453469" Received: from 5070.info ([82.146.33.49]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jan 2009 08:41:52 +0100 X-Bogosity: Unsure, tests=bogofilter Received: from [82.146.37.6] (john.ispsystem.net [82.146.37.6]) (authenticated bits=0) by 5070.info (8.14.3/8.14.0) with ESMTP id n0C7flKZ052157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Jan 2009 07:41:50 GMT (envelope-from john@ispsystem.com) Subject: memory usage From: John Lepikhin To: caml-list@yquem.inria.fr Content-Type: text/plain Date: Mon, 12 Jan 2009 15:41:46 +0800 Message-Id: <1231746106.4376.27.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 07:41:50 +0000 (UTC) X-Spam: no; 0.03; descriptors:01 4800:98 4800:98 960:98 2880:98 2880:98 threads:01 threads:01 heap:01 heap:01 roots:02 bytes:03 bytes:03 size:95 90%:94 Hello, I have developed an application and have issue with memory usage. Application was designed for work as server, 24x7. After several hours of work, RSS memory grows up to 40-50MB. Each thread must not use more than 100-200KB of memory (maximum 20 threads are run at the same time). GC debug information: Growing heap to 3840k bytes Growing heap to 4320k bytes Shrinking heap to 3840k bytes Growing heap to 4320k bytes Growing heap to 4800k bytes Growing heap to 5280k bytes Shrinking heap to 4800k bytes Shrinking heap to 4320k bytes Shrinking heap to 3840k bytes Growing heap to 4320k bytes Growing heap to 4800k bytes Growing heap to 5280k bytes Shrinking heap to 4800k bytes Shrinking heap to 4320k bytes Shrinking heap to 3840k bytes Shrinking heap to 3360k bytes Growing heap to 3840k bytes Growing heap to 4320k bytes Growing heap to 4800k bytes Growing heap to 960k bytes Shrinking heap to 4320k bytes Shrinking heap to 3840k bytes Shrinking heap to 3360k bytes Shrinking heap to 2880k bytes Growing heap to 3360k bytes Shrinking heap to 2880k bytes Shrinking heap to 2400k bytes Growing heap to 2880k bytes Growing heap to 3360k bytes Growing heap to 3840k bytes Shrinking heap to 3360k bytes Shrinking heap to 2880k bytes Growing heap to 3360k bytes Shrinking heap to 2880k bytes As you can see, heap size never gets bigger 5-6MB. I made core dump of process. 90% of memory was filled with values which are created inside threads and never been copied outside of them. Each thread is killed after work is done, I am absolutely sure in it; all unused file descriptors are closed. Playing with Gc.set has not brought notable results. Please, give me some start point to find the roots of the problem. Sorry for my English.