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:[EMAIL PROTECTED] Sent: Saturday, January 03, 2004 7:02 PM To: Vahric MUHTARYAN Cc: [EMAIL PROTECTED] 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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"