Re: load level?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Jason Pyeron wrote:
-----Original Message-----
From: centos-bounces@xxxxxxxxxx [mailto:centos-bounces@xxxxxxxxxx] On
Behalf Of Milton Calnek
Sent: Friday, April 25, 2008 3:56 PM
To: CentOS mailing list
Subject: Re:  load level?



Jason Pyeron wrote:
-----Original Message-----
Starting sendmail back up puts me in the high 1's to low 2's


Nope it is behind a firewall, no port 25 access.

mailq is 55k (logwatch)

(55 kilobytes? or 55,000 messages?? Just curious; the former is nothing of particular interest...the latter is a concern.)

Sounds like sendmail is hanging up on DNS lookups or other network I/O. This wont slow your system down necessarily, it will just inflate your load averages. The system load is just a measure of how many processes are in the run queue averaged over the preceding 1/5/15 minutes.

So if sendmail (and other processes) are waiting for slow DNS responses, the process will sit in the run queue until it either times out, or gets a response. Additionally, if sendmail is trying to connect to unresponsive SMTP hosts, it will sit with a process in the run queue until the remote SMTP server either responds or times out. The fact the load dropped and then spiked again with the shutdown/restart of sendmail seems to lend credibility to my hypothesis.

Check your DNS settings and also check to see if you are logging FQDN's in Apache as this will add significantly to your load average if your DNS is a little flaky. If you're worried about security, you only need to allow UDP/53 for DNS lookups in 99.99% of cases - it would be very unlikely that a DNS RR exceeds the maximum size of a UDP packet. To be completely covered also open TCP/53 *to* your DNS server(s) and allow connections that are related/established.

Lastly, make sure you reject (as opposed to "drop") any egress traffic you don't want going out. This way the local processes wont sit around waiting as they will get an ICMP connection refused/RST/FIN or whatever and terminate the connection immediately, clean up and get out of the run queue. If you silently drop egress packets at your edge, the local process will have no idea what happened to it's SYN packet etc, and will just sit around in the run queue (inflating your load averages) waiting for a reply that will never come, until it times out.

HTH,

James

<<attachment: smime.p7s>>

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux