From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA12879 for caml-red; Mon, 2 Oct 2000 10:47:23 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA24505 for ; Sat, 30 Sep 2000 21:58:39 +0200 (MET DST) Received: from fiji01.liquidmarket.com (oahu02.liquidmarket.com [208.244.147.130]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e8UJwcX06993 for ; Sat, 30 Sep 2000 21:58:38 +0200 (MET DST) Received: from maui00.liquidmarket.com (maui00.liquidmarket.com [192.168.1.63]) by fiji01.liquidmarket.com (8.9.3/8.9.3) with ESMTP id MAA12271; Sat, 30 Sep 2000 12:58:36 -0700 Message-Id: <200009301958.MAA12271@fiji01.liquidmarket.com> To: "David McClain" cc: caml-list@inria.fr Subject: Re: Garbage collection in OCaml In-Reply-To: Message from "David McClain" of "Fri, 29 Sep 2000 15:50:45 PDT." <000501c02a67$c5307820$210148bf@dylan> Date: Sat, 30 Sep 2000 12:58:36 -0700 From: Francois Rouaix Sender: weis@pauillac.inria.fr > OTOH, I found by tinkering that placing a Gc.compact() in a periodically > performed place, I manage to keep the entire system running within about 70 > MBytes. (My machines all have 256 MB RAM or more). > I have found that placing a Gc.full_major() does virtually nothing to > prevent the exhaustion of memory, although it slows it down ever so > slightly. That would be typical of an application that is stable in memory allocation (no leaks), but has a pattern of allocation that causes fragmentation. I have that a lot in network applications that use buffers for I/O, and I usually either call Gc.compact once in a while, or I set max_overhead in Gc.control to something like 50. For example, one of the servers behind shopping.nbci.com uses anywhere from 300M to 500M, but I have to leave the compaction to avoid swapping. --f