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 

-----Original Message-----
From: Chuck Swiger [mailto:[EMAIL PROTECTED] 
Sent: Saturday, January 03, 2004 7:02 PM
Subject: Re: some questions about Tunning FreeBSD

Vahric MUHTARYAN wrote:
> 1)in tuning man siad that " Setting vfs.vmiodirenable improve the
> 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,
> 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
> 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
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
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
process can exceed, just as other resource limits are handled-- man

> 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
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....


[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to