From owner-freebsd-questions@FreeBSD.ORG Sat Jan 3 15:21:15 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D193C16A4CE for ; Sat, 3 Jan 2004 15:21:15 -0800 (PST) Received: from etrn2.doruk.net.tr (etrn2.doruk.net.tr [212.58.5.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id A00E143D5E for ; Sat, 3 Jan 2004 15:21:04 -0800 (PST) (envelope-from vahric@doruk.net.tr) Received: from mail.doruk.net.tr ([212.58.5.6] helo=doruk.net.tr) by etrn2.doruk.net.tr with smtp (Exim 4.24) id 1AcvAO-0007C3-6h; Sun, 04 Jan 2004 01:26:48 +0200 Received: from [82.151.156.1] (account vahric HELO hpvaho) by doruk.net.tr (CommuniGate Pro SMTP 4.1.8) with ESMTP id 70150042; Sun, 04 Jan 2004 01:24:52 +0200 From: "Vahric MUHTARYAN" To: "'Chuck Swiger'" Date: Sun, 4 Jan 2004 01:20:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcPSG9xkHRStoN7gSIWBZ0uUtYbxcwAMkPBA In-Reply-To: <3FF6F588.4050706@mac.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: cc: freebsd-questions@freebsd.org Subject: RE: some questions about Tunning FreeBSD X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2004 23:21:15 -0000 Hi, Okey your right because with maildir-style each messages are saving in different files but this files are downloaded from client with using POP3 at this moment I wonder How caching Directory or files improve the performans because files are not available after download .. But if you mean that, those directories and files are caching when new email address arrive . I think everything will be okey ... I will try Kern.maxfilesperproc=0 parameter because I think that if maxusers=0 is woking which is default, at this moment Kern.maxfilesperproc=0 Too . I will inform you Can I say kern.pc.somaxconn limits for system and no service can exceed this limit like apache or mail services ?! Another point of view about large listen queue, Okey you are thinking valid request but DoS can over this listen queue easy.Doesn'T it ?! Thanks For You Help Vahric -----Original Message----- From: Chuck Swiger [mailto:cswiger@mac.com] Sent: Saturday, January 03, 2004 7:02 PM To: Vahric MUHTARYAN Cc: freebsd-questions@freebsd.org Subject: Re: some questions about Tunning FreeBSD Vahric MUHTARYAN wrote: > 1)in tuning man siad that " Setting vfs.vmiodirenable improve the performans > of sevices that manipulating a large number of file like Web Cache,large > Mail System and News System " But I don't agree with it for mail system, or > What type of mail systems can imporved with this settings ... [ ... ] Consider using Maildir-style mailboxes rather than MBOX-style. [cf procmail] > 2)Can I set Kern.maxfilesperproc=0 because I don't want to seperate > maxfilesize for seperate process ?! I mean I don't want to limit it for any > process ?! I'm not sure whether 0 means "unlimited" for that parameter. It's safer to set a reasonable limit to prevent a malicious or runaway process from hogging finite resources; set it to a few thousand or so and not worry about it. Unless you've got a monster news server or squid or something which wants lots of descriptors... > 3)I think setting kern.pc.somaxconn is not necessary because all programs > can handle their self listen queue size like Apache and Mail Programs . Yes, but it reasonable for the system (aka root) to set a maximum that no user process can exceed, just as other resource limits are handled-- man getrusage. > One sentence disturb me in tunning man, "Larger listen queue also do a > better job of fending off denial service attack" I can't imagine How ?! While your inbound pipe might be full of DoS traffic, there may still be some valid requests coming in, as well as local network traffic which is still getting through. A longer listen queue lets the machine at least try to service those connections rather than having them get dropped.... -- -Chuck