From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr 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 86BB4BC57 for ; Mon, 30 Aug 2010 12:33:50 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0BAG4me0zVhjEYkGdsb2JhbACgVAEBAQEJCQwHEQMfuGaCbYJKBIx9 X-IronPort-AV: E=Sophos;i="4.56,292,1280700000"; d="scan'208";a="68361158" Received: from ihsmtp02voda.lis.interhost.com (HELO ihsmtp02cons.lis.interhost.com) ([213.134.49.24]) by mail4-smtp-sop.national.inria.fr with ESMTP; 30 Aug 2010 12:33:50 +0200 Received: from [172.29.149.150] ([193.136.33.132]) by ihsmtp02cons.lis.interhost.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Aug 2010 11:33:49 +0100 Message-ID: <4C7B890C.7090704@inescporto.pt> Date: Mon, 30 Aug 2010 11:33:48 +0100 From: Hugo Ferreira User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Richard Jones Cc: caml-list@inria.fr Subject: Re: [Caml-list] Tracking memory usage: GC output not same order as unix top command References: <4C7B7D4E.4020500@inescporto.pt> <20100830100252.GA7715@annexia.org> <20100830100648.GB7715@annexia.org> In-Reply-To: <20100830100648.GB7715@annexia.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Aug 2010 10:33:49.0777 (UTC) FILETIME=[D57F3410:01CB482E] X-Spam: no; 0.00; 0100,:01 0100,:01 escapes:01 pointer:01 wrote:01 wrote:01 unix:01 unix:01 heap:01 caml-list:01 data:02 output:02 output:02 interpret:03 install:05 Hi, Richard Jones wrote: > On Mon, Aug 30, 2010 at 11:02:52AM +0100, Richard Jones wrote: >> On Mon, Aug 30, 2010 at 10:43:42AM +0100, Hugo Ferreira wrote: >>> The output >>> shows memory usage below the 100M mark, however the unix command >>> "top" shows usage in the order of Gigabytes (at least 4.8). This >>> memory consumption grows gradually. >> The output of top isn't a reliable way to measure memory usage. >> >> Really you should be looking at /proc//maps. That will show you >> if, for example, the heap is becoming fragmented or if there's some >> memory leak. No looking for exact or detailed data. Just trying to identify which function is the culprit. An order of magnitude in difference makes me think I am doing something wrong. >> There is a nice utility for examining maps files and >> system memory usage, but the name of it escapes me at the moment. > > I might have been thinking of this one: > > http://lwn.net/Articles/329458/ > I looked at this tool. Going to ask the admin if he can install this because I cannot interpret the output from the "/proc//maps". Thanks for the pointer, Hugo F. > Rich. >