sending email is slow

[someone_4]

Hello everyone,
I have an issue with my mailserver. When the end user trys to send email though the mailserver the connection is very slow. But when they try to get email it goes though really fast. But it is from a specific location not from all areas. To me it sounds like some kind of networking problem since it is from one location. But the networking team insist that is is something in the mailserver. I was wondering if there are any settings in HPUX or sendmail 8.8.3 that limit the number of smpt connections that are comming in. Any ideas?

Richard

[someone_4]

the only thing i could find in the sendmail.cf file was

DaemonPortOptions=options
[O] Set server SMTP options. The options are key=value pairs. Known keys are:

Port Name/number of listening port (defaults to "smtp")
Addr Address mask (defaults INADDR_ANY)
Family Address family (defaults to INET)
Listen Size of listen queue (defaults to 10)
SndBufSize Size of TCP send buffer
RcvBufSize Size of TCP receive buffer


___

But I have not messed with it yet. Am i going down the right track?

Richard

[Craig Rants · Accepted solution]

What happens when you telnet to the mail server?

telnet mailserver.com 25

helo yourdomain.com

mail from:youremail

rcpt to:someoneelsesemail

data
Test
.

quit

See how fast that goes, and see if there is a difference.

We can go from there.

GL,
C

[Christopher Caldwell]

Look at these tunings in sendmail.cf

# load average at which we just queue messages
O QueueLA=20

# load average at which we refuse connections
O RefuseLA=22

# maximum number of children we allow at one time
#O MaxDaemonChildren=12

# maximum number of new connections per second
#O ConnectionRateThrottle=3
O ConnectionRateThrottle=1

It's useful to have the sendmail book (a.k.a. the Bat Book) by Costales w/ Allman. Though we could explain in detail the interactions and implementation of the tunes - the book is very useful (and detailed).

A couple of other pointers that help performance:

1) make sure to separate
/var/mail
/var/spool/mqueue

and any other filesystems that service mail (we use /var/spool/popper for POP3). We've got all of the filesystems striped across a fair number of platters.

2) *(Best with sendmail 8.11) if you're getting lots of spam, consider subscribing to RBL mail-abuse.org or ORBZ http://www.orbz.org/. Both of these organizations help you kill bad SMTP connections long before you get into the expensive delivery process (writing the data to disk).

3) Use the virtusertable or virtuser-domains (sendmail 8.11) to limit the cost misdelivered mail or probes from spammers.

4) If mis-delivery or connection rate is a big problem - think about splitting initial mail service by front-ending the boxes that check mail with a box that recieves mail from the Internet (see mailertable). To scale, you can split the "check" boxes or the frond-end boxes (or both).

[Jeff Schussele]

Richard,

Check these two fields out:

# maximum number of children we allow at one time
O MaxDaemonChildren=12

# maximum number of new connections per second
O ConnectionRateThrottle=3

The first limits number of simultaneous host connections (inbound & outbound combined - I believe).

Second limits rate of connections.

May be these users are "flooding" you with outbound at the same time - but pick up mail whenever.

Also I've seen this problem being related to DNS - usually reverse lookup.

I would suspect the latter as it appears subnet specific.

HTH,
Jeff

[Jeff Schussele]

To expand on the DNS topic - if I remember correctly, by default, the receiving SMTP server ALWAYS performs both forward & reverse DNS lookups.

Therefore first step I would take is to nslookup the host & IP in question & see what results you get as well as response time.

[someone_4]

The connection to port 25 via telnet is slow too. But it is just the connection part once we get a promt everything is fast. maybe a dns issue? If it is a dns issue why would it be location specific?

richard

[someone_4]

nslookup comes back fine and fast,

Richard

[Jeff Schussele]

Richard

Sorry - host specific is what I meant.

Is is coming from another domain in your network? If so is their DNS server setup correctly?

Do an nslookup by hostname - from the mail server - to determine IP. Then nslookup the IP.

Could possibly be a primary server timeout causing secondary DNS servers to service the request - hence the additional time required to connect.

[Christopher Caldwell]

In addition, make sure this option is set

O Timeout.ident=0s

It causes user delays, especially if users are behind firewalls. By default (i.e. if you still see ident commented out) the timeout is 30 seconds. Most folks don't actually use identd, anyway.

[Mark Greene_1]

if telnet is slow, do a traceroute to the server and see how fast/slow and how many hops. show that output to your network guys and see what they say.

HTH
mark

[Jeff Schussele]

Richard,

If forward & reverse lookups to that specific host are OK & no other users see the problem then I would suspect, as you, a network problem. Sure doesn't sound like a config or load problem. You certainly can check that with top & ps -ef | grep send commands - but you'd think other users would have reported such.

What do large packet size pings to that host produce?

Jeff

[someone_4]

whooo hooo !! IT WORKS !!
I made all theese changes
O Timeout.ident=0s

# load average at which we just queue messages
O QueueLA=20

# load average at which we refuse connections
O RefuseLA=22

# maximum number of children we allow at one time
#O MaxDaemonChildren=12

# maximum number of new connections per second
O ConnectionRateThrottle=1

and now it works faster then ever !! 10s for everyone!!
AND IF YOU GUYS CAN TELL ME WHY THEESE CHANGES MADE THIGNS GO FASTER .. ANOUTHER ROUND OF 10S

Richard

[Jeff Schussele]

Richard,

I suspect the MaxDaemonChildren is what did the trick. Commenting it out sets NO limit by default. This lets the server spawn as many connections as it can handle( Note though this can be problematic if this server gets hit by a spammer). If you had a low value in there. connections will be on an as-serviced basis & if you have some large mail deliveries to slow receiving servers - this could affect internal connections. This is why Christopher is 100% correct RE the value of seperate inbound/internal & outbound servers

Also you could probably set the Connectio nIRateThrottle up to at least 3 & higher if you have fairly robust system. This just basically sets the limit of connections per second. I've used 5 on a G-class w/o a problem. Again - commented out is NO limit.

The "LA" settings are load limts whereby when the server values are reached the system will stop:

a) accepting connections for RefuseLA
b) Accept connections but only queue them up for QueueLA

BTW - these are a little high in my humble opinion. I would set QueueLA to 6-10 & RefuseLA to 11-14.

HTH,
Jeff

[Christopher Caldwell]

This option controls the use of identd when you get inbound connections:
O Timeout.ident=0s
Effectively turns of identd. You don't need it; (you probably weren't using it anyway); causes hangs on firewalls.


These options are use to meter/throttle sendmail to control load and resource utilization.

# load average at which we just queue messages
O QueueLA=20
When the LA is over 20, just write messages to the queue, don't try to send them. This probably didn't do anything for you.


# load average at which we refuse connections
O RefuseLA=22
Don't even accept a connection if the LA is over 22. This probably didn't do anything for you.


# maximum number of children we allow at one time
#O MaxDaemonChildren=12
This option isn't in effect (it's comment out). If it was commented in, it would say don't run any more than 12 sendmail processes (in addition to the initial sendmail process).
Generally used in queue processing. Generally not used in sendmail.cf (can result in a DOS attack); better to use throttle options. Default is unlimited (actually maxproc).

# maximum number of new connections per second
O ConnectionRateThrottle=1

Slows down the socket acceptance rate (and consequently the fork another sendmail rate). Used to slow incoming connections. No limit if default (not present or not commented)
or negative. If positive, sendmail won't accept any more than num connections per second. In your case, num is 1.

This option probably didn't help you too much.

[Jeff Schussele]

Richard,

I suspect the MaxDaemonChildren is what did the trick. Commenting it out sets NO limit by default. This lets the server spawn as many connections as it can handle( Note though this can be problematic if this server gets hit by a spammer). If you had a low value in there. connections will be on an as-serviced basis & if you have some large mail deliveries to slow receiving servers - this could affect internal connections. This is why Christopher is 100% correct RE the value of seperate inbound/internal & outbound servers

Also you could probably set the
Connectio nIRateThrottle up to at least 3 & higher if you have fairly robust system. This just basically sets the limit of connections per second. I've used 5 on a G-class w/o a problem. Again - commented ut is NO limit.

The "LA" settings are load limts whereby when the server values are reached the system will stop:

a) accepting connections for RefuseLA
b) Accept connections but only queue the data up for QueueLA

BTW - these are a little high in my humble opinion. I would set QueueLA to 6-10 & RefuseLA to 11-14.

Also I agree that the O'reilly "Bat Book" is absolutely essential.

HTH,
Jeff

[Christopher Caldwell]

BTW, if you want to see which option fixed your problem, put the tune back to when your system was slow and change the tunes 1 at a time until you see which one makes a difference.

(The tunes we gave don't have to be used together, each one does something different).