From owner-freebsd-isp Wed Sep 18 8: 5:17 2002 Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C57F337B401 for ; Wed, 18 Sep 2002 08:05:14 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EE9B43E42 for ; Wed, 18 Sep 2002 08:05:14 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from smtp-relay01.mac.com (smtp-relay01-en1 [10.13.10.224]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id g8IF5DWI000753 for ; Wed, 18 Sep 2002 08:05:13 -0700 (PDT) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtp-relay01.mac.com (8.12.1/8.12.1/1.0) with ESMTP id g8IF5DVw024523 for ; Wed, 18 Sep 2002 08:05:13 -0700 (PDT) Received: from bust ([12.38.161.88]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H2N38O00.671 for ; Wed, 18 Sep 2002 08:05:12 -0700 Date: Wed, 18 Sep 2002 11:05:09 -0400 Subject: Re: SV: Inactive memory in FreeBSD Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: Chuck Swiger To: isp@FreeBSD.ORG Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <06319CE3-CB18-11D6-ABD2-000A27D85A7E@mac.com> X-Mailer: Apple Mail (2.482) Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wednesday, September 18, 2002, at 09:19 AM, pzw@aabc.dk wrote: > However, when you compile a program or FTP a file to the server, the > chances > of you doing that over and over again is almost null, therefore caching > these processes are a total waste. Caching pages used by the FTP daemon or the C compiler executables in memory isn't a total waste, because those processes are running. Note that the system will not cache an excessive amount of the files being used by those programs; the disk I/O buffer is constrained. > So, FreeBSD is best used for a server system, where you have more RAM than > you use for all normal activity, and to prevent some seldom used tasks to > hog up memory, you should reboot often. FreeBSD makes a good server system. All well-designed systems perform better when the amount of physical RAM available is greater than their VM working set. I don't think your analysis of memory usage is correct. Take a look at the resident size (RSS), not the VM size (VSZ). However, you may have a program that is leaking memory, which is causing the swapfile to fill up. Killing that process will solve the problem without having to reboot. You should never need to reboot FreeBSD, short of reinstalling the kernel. > As a workstation system, you're better of using Windows or Linux, unless > ofc. You're a secretary using the same word processor program day in and > day > out. Opinion. Besides, platform advocacy is off topic. > IMHO it would be a far better solution, for you to be able to specify the > maximum amount of memory that a program could hog up, so you don't have to > reboot all the time to free memory. RTFM. You can specify the maximum amount of memory that a program can use-- see "man setrlimit" or the "limit" command in the shell: int setrlimit(int resource, const struct rlimit *rlp); DESCRIPTION Limits on the consumption of system resources by the current process and each process it creates may be obtained with the getrlimit() call, and set with the setrlimit() call. The resource parameter is one of the following: RLIMIT_CORE The largest size (in bytes) core(5) file that may be cre- ated. RLIMIT_CPU The maximum amount of cpu time (in seconds) to be used by each process. RLIMIT_DATA The maximum size (in bytes) of the data segment for a process; this defines how far a program may extend its break with the sbrk(2) system call. [ ... ] RLIMIT_RSS The maximum size (in bytes) to which a process's resident set size may grow. This imposes a limit on the amount of physical memory to be given to a process; if memory is tight, the system will prefer to take memory from pro- cesses that are exceeding their declared resident set size. RLIMIT_STACK The maximum size (in bytes) of the stack segment for a process; this defines how far a program's stack segment may be extended. Stack extension is performed automati- cally by the system. -Chuck Chuck Swiger | chuck@codefab.com | All your packets are belong to us. -------------+-------------------+----------------------------------- "The human race's favorite method for being in control of the facts is to ignore them." -Celia Green To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message