From owner-freebsd-questions Tue Jun 4 09:33:39 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA23709 for questions-outgoing; Tue, 4 Jun 1996 09:33:39 -0700 (PDT) Received: from mistery.mcafee.com (jimd@mistery.mcafee.com [192.187.128.69]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA23703 for ; Tue, 4 Jun 1996 09:33:35 -0700 (PDT) Received: (from jimd@localhost) by mistery.mcafee.com (8.6.11/8.6.9) id JAA01344; Fri, 4 Jun 2010 09:43:01 -0700 From: Jim Dennis Message-Id: <201006041643.JAA01344@mistery.mcafee.com> Subject: Re: Relation between RAM & no: of users To: vdongre@rolta.com (Vrushal Dongre) Date: Fri, 4 Jun 110 09:43:01 -0700 (PDT) Cc: questions@FreeBSD.org In-Reply-To: <199606041337.AA02867@68f800.rolta.com> from "Vrushal Dongre" at Jun 4, 96 01:37:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Hello All ! > I am a newcomer to the FreeBSD world . > I want to set up a mailserver at my office. > I have FreeBSD 2.0 running on a 486-DX2 system with four IDE HDDs > of 1GB each . I have alotted 150MB as swap space. > There will be approximately 200 users, using the system primaraly > for email; some will use mail/elm others will use email clients like > Eudora through Windows.. > I have 32MB of RAM on board. > My question is :- is 32 MB sufficient , or do i need to add some > more RAM ? > Your help will be greatly appreciated. > Cheers, The vital question is: how many concurrent shell (elm/pine/mh) users do you want/need to support? Your POP (Pegasus/Eudora) users are less of a problem since the sessions are typically quite short and most of the memory overhead is at the client workstation. If some of the clients will be using other Unix hosts they can use 'popclient' to fetch their mail from the gateway and append it to their local spool file (or to append it to a special mail folder). Your real concern is the users who are telnetting in, using a shell account to launch elm or pine, or running mh commands. In particular you have to worry about users that telnet in and take up one session all day long, every day. My guess is that you should figure on about a half meg per *active* concurrent shell user (giving you roughly enough for 60 users in 32Mb of RAM). You can have quite a bit of swap space because many of the sessions are likely to be inactive most of the time. With your 150Mb of swap you should be able to handle all 200 users logged in to elm. If more than about 30 of them were active (most e-mail users I've seen start a session and leave it backgrounded, minimized, whatever -- all day) then it will probably seem *slooooowwwwww*. Having more RAM won't hurt. Distributing the load over two system will hurt even less ;). This is especially true if the machines can be located on your LAN in such a way as to minimize traffic. Unless your site is using intelligent swithing hubs (assuming that you're on ethernet) you're probably segmented (probably along some departmental boundary). Putting one department's mail server on it's segment and another's on "their" segment will minimize the load on your routers. Of course you can also put multiple ethernet interfaces in your FreeBSD boxes and have them stradling the segments. Finally, by having two or more identically configured mailhosts you can easily implement a disaster plan. Plan ahead and keep the account tables (passwd files) synchronised (either by hand or using NIS+). Using the aliases files (which would mostly be complements of one another) you can ensure that the mail gets forwarded to the "right" box. However if one box fails you can make a quick change to the aliases files, and possibly a quick DNS change or IP alias to force the other box to handle the whole load. I've found that nothing makes a user community crankier faster than than a dead mail server. Being able to their mail back up in minutes rather than hours or days is *vital*. Jim Dennis, System Administrator, McAfee Associates