[277] in The Cryptographic File System users list
cfs and memory usage . . .
daemon@ATHENA.MIT.EDU (Brian T. Schellenberger)
Thu Oct 31 04:25:11 2002
From owner-cfs-users@crypto.com Thu Oct 31 09:25:11 2002
Return-Path: <owner-cfs-users@crypto.com>
Delivered-To: cfs-mtg@CHARON.mit.edu
Received: (qmail 9732 invoked from network); 31 Oct 2002 09:25:10 -0000
Received: from mx.crypto.com (207.140.168.138)
by charon.mit.edu with SMTP; 31 Oct 2002 09:25:10 -0000
Received: (from majordomo@localhost)
by MultiHostMXServer (8.9.3/8.9.x4) id EAA11948
for cfs-users-list; Thu, 31 Oct 2002 04:13:50 -0500 (EST)
Received: from dockmaster.research.att.com (H-135-207-24-155.research.att.com [135.207.24.155])
by MultiHostMXServer (8.9.3/8.9.x4) with ESMTP id EAA25357
for <cfs-users@crypto.com>; Thu, 31 Oct 2002 04:13:49 -0500 (EST)
Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.30.103])
by dockmaster.research.att.com (8.12.1/8.12.1) with ESMTP id g9V8Tfxi012751
for <cfs-users@nsa.research.att.com>; Thu, 31 Oct 2002 03:29:41 -0500 (EST)
Received: from janus (fpfw.research.att.com [135.207.1.2])
by mail-green.research.att.com (Postfix) with SMTP id 614A41E105
for <cfs-users@nsa.research.att.com>; Thu, 31 Oct 2002 04:13:18 -0500 (EST)
Received: from mail-red.research.att.com ([192.20.225.110]) by janus; Thu, 31 Oct 2002 04:13:18 -0500 (EST)
Received: (from postfixfilter@localhost)
by mail-red.research.att.com (8.11.6/8.11.6) id g9VAE8903953
for cfs-users@nsa.research.att.com; Thu, 31 Oct 2002 05:14:08 -0500
X-Authentication-Warning: mail-red.research.att.com: postfixfilter set sender to bts@fake.com using -f
Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83])
by mail-red.research.att.com (Postfix) with ESMTP id 70FD81AB4BA
for <cfs-users@nsa.research.att.com>; Thu, 31 Oct 2002 05:14:08 -0500 (EST)
Received: from mail7.nc.rr.com (fe7 [24.93.67.54])
by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id g9V9Cxup025660;
Thu, 31 Oct 2002 04:12:59 -0500 (EST)
Received: from this.is.fake.com ([24.162.238.30]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75);
Thu, 31 Oct 2002 04:12:22 -0500
Received: by this.is.fake.com (Postfix, from userid 111)
id D8471BA12; Thu, 31 Oct 2002 04:12:48 -0500 (EST)
Content-Type: text/plain;
charset="us-ascii"
From: "Brian T. Schellenberger" <bts@babbleon.org>
To: cfs-users@research.att.com
Subject: cfs and memory usage . . .
Date: Thu, 31 Oct 2002 04:12:48 -0500
User-Agent: KMail/1.4.2
Cc: jdp@polstra.com, green@freebsd.org, cfs-users@nsa.research.att.com,
freebsd-ports@freebsd.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200210310412.48667.bts@babbleon.org>
X-Spam-Status: No, hits=-2.9 required=5.0
tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT,
USER_AGENT_KMAIL
version=2.43-cvs
X-Spam-Level:
Sender: owner-cfs-users@crypto.com
Precedence: bulk
I use the FreeBSD "port" of cfs, and I have noticed that it is very
greedy in using memory.
Now, I'm a little unfriendly to it now in that I have a number of cfs
file systems set up but even when I only had one or two it would behave
the same way:
Memory usage is fine for "normal" activities, but if I do something that
scans lots of files, such as running a "find" command that greps over
the files in the CFS area or something, memory usage will shoot up to
astronomical levels (eg, over 300M or more).
And that memory will never be freed.
This will so exhaust memory that the system will frequently crash not
long afterwards.
Now, it looks like cfs is *meant* to respond to a SIGALRM and clean up
memory that's no longer needed, and additionally to go through this
cleanup automatically every 60 seconds:
signal(SIGALRM,grimreap);
alarm(60); /* every 60 secs */
(at the end of main).
But it looks like something is preventing this from happening, or the
grimreap routine just never agrees to clean up anything.
I know that there are parameters I can tune to use less total memory but
I'm wondering if other people have seen this behavior and what, if
anything you did to deal with it.
Thanks for any hints that anybody can offer.
--
Brian, the man from Babble-On . . . . bts@babbleon.org (personal)
