Slashdot Log In
Sendmail Performance Tuning
from the the-mail's-gotta-get-there dept.
| Sendmail Performance Tuning | |
| author | Nick Christenson |
| pages | 256 |
| publisher | Addison Wesley |
| rating | 9 |
| reviewer | Andy Murren |
| ISBN | 0321115708 |
| summary | Compact but well-constructed book; shows you ways to cost-effectively improve your sendmail setup, and much of the rest of your system along the way. |
This book was very easy to read and kept moving along. While I did not find it as much of a page turner as Douglas Adams' Hitchhikers Guide, it did keep me interested. One word of warning though: do not read this when you are tired. You will miss some really good information and have to re-read parts.
I was surprised and very pleased with how much I learned about so many things about Unix, networking and hardware while learning more about sendmail. There is a wide range of information presented that readers at almost any skill level would be able to use. The writing style and use of language was easy to read. The wealth of information packed into the pages of this book I found immediately usable on my Linux boxes and for my job.
I think the only drawback to the book was that there was not more specific sendmail information. Due to the nature of the topic, a lot of the book is devoted to how Unix systems work, more than specific sendmail configuration tasks. Time and detail is spent on other more important considerations such as logging, disk performance, test planning and file systems.
Chapter 1 gets us started with an overview of tuning in general. One of the more important themes of the book is established up front: It is that a cost/benefits analysis should be done for each step.
Sections 1.5, "Tuning Isn't Always Necessary" and 1.6, "Not So Fast ..." establish baseline considerations for making a decision on what, if any, tuning efforts should be made. Throughout the book Christenson reminds the reader to decide on a path that is most cost effective for his organization. Is it the most cost-effective use of the company money and time to have the IT staff hand-craft solutions, or is it better to throw some hardware at the problem?
Let's face it -- if you are running sendmail for a small company and only move a few hundred emails a week, how much performance tuning do you need? If, however, you are running an ISP, a mailing list server or a medium- (or even a large-) sized company mail server, then you need to tune your mail server. This is the book for you. The information in this book, while oriented for sendmail, is actually applicable for tuning any Unix based Mail Transport Agent (MTA) server.
Each solution is an individual matter, that is wholly dependent on several factors. Some of these factors are: volume of email, what the main use of the email system is, how the end users interact with the system, what hardware is being used, how much bandwidth you have and much time and money you have to throw at the problem. Of course, what management considers important is the overriding factor in all decisions.
Chapter 2 is a ten-page introductory overview to sendmail, covering versions, obtaining the (Open Source) code and building sendmail. One of the important things covered is the queue and message spool layouts and permissions. This is helpful for making sense of things later in the book.
A few very important pages are spent on creating the .cf file and why you should use M4, the macro language, for managing the configuration files. Having hand-crafted a .cf file myself several years ago then having to deal with maintaining it, I can vouch for the wisdom of using M4.
The maintainers of sendmail update the M4 macros for new features and changes. The 200 - 300 lines of M4 macro files are converted into a 1500to 2000 line configuration file. While it may be easier to figure out the configuration file to make changes, those changes may not be valid from one version of sendmail to the next.
Christenson admits that he does not always use M4 when in a rush or to test some things. What he does is copy the working configuration file to sendmail.cf.REAL before making changes and updating the .mc file afterward.
The next chapter, Chapter 3 'Tuning Email Relaying' starts with an overview of the email relaying sequence. Most of the discussion in this chapter is not sendmail specific. The importance of data synchronization is emphasized here. Section 6.1 of RFC 2821 is quoted, where it states the email server 'MUST NOT lose the message'. Once that is stated and understood all of the requirements that are discussed in the rest of the chapter are clear.
The next 17 pages are spent discussing how file systems, networking and effective use of file space support, and can detract from, meeting the edict of the RFC. For me, these sections are some of the most interesting, filled with information presented in a concise, readable and detailed manner. I learned a lot about what impact some very basic decisions have on email performance. I also learned how much better I could have made the email servers I have worked on. I will be turning to this chapter the next time I am putting together a box, be it a web server, mail server, file server or even a workstation or laptop. This is a great chapter that can help with any system configuration.
Email reception is covered in chapter 4. Different strategies for verifying recipient, tuning POP and IMAP are covered. Effective use of Local Delivery Agents (LDAs), including procmail, is covered here also.
Additionally, an excellent discussion of storage systems, including disks and solid-state disks, is in this chapter. The sections covering RAID levels, benchmarking and use are well written and informative. Available options on drives, ATA vs. SCSI, Solid State, are just as well done. Section 4.4.2, 'Stupid Disk Drive Tricks,' has some nifty information about how to set up disk drives for even better performance.
Sending email is the next chapter. Here we see some more sendmail-specific information. Tuning of mailing lists and mass mailing is part of the discussion here. One of the more important sections is 'Draining Queues.' How backups are caused and what to do to recover are discussed in this section. This has good information that can be used with any MTA.
One of the most important chapters for me is Chapter 6 'Configuration, Security and Architecture.' Sendmail specific configuration and tuning options are discussed. Section 6.1 covers configuration and is in many ways the heart of the book. This is where sendmail directives that can directly impact performance are covered. How a system's architecture (and DNS) is laid out can have a significant impact on performance.
The section on security is good, but brief. Most of the discussion is on privacy and stopping spam. The use of Transport Layer Security (TLS) is covered in less than a page. With a smattering of security in other parts of the book, this is the sum total of the security discussion of the book. Considering some of the problems with sendmail in the past, I would have liked some more information on this topic.
The next two chapters, 'Finding and Removing Bottlenecks' and 'Load Generation and Testing,' are good, solid, well-written sections that are applicable to most any email system. We are given some effective ways of making systems run better, and how to prove that the system actually does work better. This is where we justify to the boss that the work we have done is really cost effective.
Chapter 9, 'Conclusion' is basically a very brief wrap up and a list of books Christenson thinks we should read.
My own conclusion is that I have learned and relearned a lot of things about Unix and email. Even if you do not use sendmail, I recommend this book without reservation. It is an excellent reference on general system performance tuning, with information on making your sendmail installation run better.
Table of contents
- Introduction
- 1.1 Performance Tuning Examples
- 1.2 sendmail Versions Covered
- 1.3 Definitions
- 1.4 Email Server Tasks
- 1.5 Tuning Isn't Always Necessary
- 1.6 Not So Fast...
- 1.7 Email System Profiling
- 1.8 General Tuning Ideas
- 1.9 Summary
- Sendmail Introduction
- 2.1 Obtaining Sendmail
- 2.2 Building Sendmail
- 2.3 Creating a .cf file
- 2.4 Why Use M4?
- 2.5 System Setup
- 2.6 Summary
- Tuning Email Relaying
- 3.1 What Happens During Relaying
- 3.2 Synchronization
- 3.3 File Systems
- 3.4 File Space
- 3.5 Networking
- 3.6 Summary
- Tuning Email Reception
- 4.1 What Happens During Email Reception
- 4.2 Recipient Verification
- 4.3 Storage Systems
- 4.4 Disks
- 4.5 Solid State Disks
- 4.6 POP Tuning Specifics
- 4.7 Message Storage Hashing
- 4.8 IMAP Tuning Specifics
- 4.9 Summary
- Tuning Email Sending
- 5.1 Mailing Lists
- 5.2 Command-Line Message Generation
- 5.3 Draining Queues
- 5.4 Another Mailing List Strategy
- 5.5 SMTP PIPELINING
- 5.6 More Notes on Mass Mailing
- 5.7 Summary
- Configuration, Security and Architecture
- 6.1 Configuration
- 6.2 Security and Performance
- 6.3 Other General Strategies
- 6.4 Summary
- Finding and Removing Bottlenecks
- 7.1 Kernel Parameters Run Amok
- 7.2 The Quick Fix
- 7.3 Tools
- 7.4 syslog
- 7.5 Removing Bottlenecks
- 7.6 Summary
- Load Generation and Testing
- 8.1 Test System Setup
- 8.2 Testing Tools
- 8.3 Load Testing Pitfalls
- 8.4 Summary
- Conclusion
You can purchase Sendmail Performance Tuning from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Qmail! (Score:1, Offtopic)
Re:Qmail! (Score:5, Funny)
Re:Qmail! (Score:4, Insightful)
Oh Yes! (Score:4, Funny)
Sendmail Performance Tuning - the short guide (Score:1)
#rpm -i exim-foo.bar.rpm
That ought to do it... (Debian wienies can feel free to use apt there or *chortle* dselect)
apache and sendmail books not quite useful (Score:4, Insightful)
I have administered NIS+ apache, and sendmail, and these topics are so vast, that buying books doesn't help. However searching through google/deja does help a lot.
But that is just my opinion....
Sendmail tuning? (Score:4, Insightful)
Tuning Sedmail is about as smart as tuning MS Exchange. Both are fat, bloated, and have a history of secutiry holes. Performance tuning Sendmail is like performance tuning an AMC Gremlin made out of spare junkyard parts - you end up with a cobbeled peice of crap with a spoiler.
Sendmail is so bloated that it apparently takes books to get decent performance out of it.
Sendmail doesen't fit the one of the core Unix ideas - use simple, robut and elegent programs, chained together, to do cool things.
Check out Postfix or Qmail for decent replacements to Sendmail. Enjoy the performance of well toughtout software. Postfix was so easy to use, that I went from reading the man pages to a working system in one hour.
Re:Sendmail tuning? (Score:4, Insightful)
I guess it works okay, but only a badly twisted mind could have devised the configuration system that qmail uses. Once you add one of the various virtual domain hacks it becomes nearly impenetrable. Then you try to integrate a mail list manager or spam tool, and before you know it, you're waist deep in GID's and SUID bits and log files, and you find yourself trying to read a Google translation from the original Slovenian.
Nice to see M4 (Score:5, Funny)
I'm trying to remember who said this:
Re:Nice to see M4 (Score:5, Insightful)
pretty annoying to have to preprocess one's config file.
If I ran the world, sendmail would optionally preprocess
its config file itself. In other words, you'd be able to use
the m4 file directly.
One word of warning though... (Score:1)
Damnit! I'm always tired. Guess I can't read the book at all.
Performance tuning? (Score:3, Funny)
Don't forget... (Score:4, Funny)
My sendmail.. (Score:2)
.. always needs tuning. The strings need replacing, the wood frame warps in the humidity. It's a real bitch.
What is with all the sendmail bashing? (Score:5, Insightful)
If you like another mail program, DO A BOOK REVIEW ON THAT MAIL PROGRAM and share your "wisdom" with the rest of us.
As for sendmail, it is not meant for Windows weenies or wanna be Unix sysadmins, only for "real" Unix admins and those that wish to use a VERY robust product and are willing to learn the product to reap the rewards. I personally feel that this book is a great quick reference for when you have a brain fart and don't feel like mulling through the O'Reiley "bat-book" for a simple answer
Just my $0.02 cents
Re:What is with all the sendmail bashing? (Score:5, Insightful)
Are you kidding?
I can get PostgreSQL to master/slave replicate a database cluster over 5 servers in faster time that I can get Sendmail do somthing simple. Really.
The Sendamil config files might as well be binary - there useless to human eye. And, no, you shouldent have to learn a line-noise language just for a silly MTA.
Sendmail is just a bitch. I had it's time in the sun, and it's time to move on.
only for "real" Unix admins
A 'real' Unix admin wants to get work done and learn somthing usefull. Managing Sendmail is just memorising a bunch of trivia about it and hoping it works as you think it should. Managing Postfix or Qmail is like managing any other decent Unix server - and by learning one of them you can take that knowlage and use it somewhere else.
A 'real' Unix admin knows when a peice of software is a cobbled peice of crap and when to move on to somthing sane.
Egads! (Score:1)
That's an unfair assessment. No book could compare.
(I have attempted to read the Bat Book on numerous occations, only to be reminded that it's topic is actually sendmail.)
heh (Score:5, Funny)
Spock: K4YM3
Computer: Correct. What was Kiri-kin-tha's first law of metaphysics?
Spock: Nothing unreal exists.
Computer: Correct. Adjust the sine wave of this magnetic envelope so that anti-neutrons can pass through it but anti-gravitons cannot.
Spock: (Spock works keypad and the image of the envelope is changed on one of the screens.)
Computer: Correct. Identify: (an image appears)
Spock: A Klingon mummification glyph from the earliest part of the Zanxthkolt dynasty.
Computer: Correct. Reconfigure the rulesets from this sendmail configuration to first consult a DNS RBL before delivery to local users without using M4.
Spock:
computer: Reconfigure the rulesets from this sendmail configuration to first consult a DNS RBL before delivery to local users without using M4.
Spock:
Spock's Mom: What is it, Spock, what's wrong?
Spock: The question is irrelevant.
Exchange Killer (Score:2, Insightful)
Postfix: Add mine to the list of redundant posts (Score:2)
Far better performance than sendmail for my piddling needs. Why, again, would I want sendmail back, and play around tuning?
The Author knows a few things about scalability (Score:4, Informative)
Sendmail books... (Score:5, Informative)
And on a side rant to those who bitch about sendmail, If you don't like it.. don't use it. All of the gripes I've seen about it seem to derive from the posters ignorance on how to set it up. Granted,
sendmail performance tuning (Score:2, Funny)
$ apt-get remove sendmail
$ apt-get install mailer-of-your-choice
$
Improves system security, too.
works for me.. (Score:1)
Nice to see a positive review (Score:4, Interesting)
Sendmail (the app, not the company) scales quite nicely if you know what you are doing - I've installed sendmail on a couple of old dual-proc HP's and they handle about 2 million messages a day. Yes, that's right; 2 MILLION. It's a "simple" matter of tuning and knowing the file system.
Don't hack the
And, if another tool works better for you (exim, postfix, qmail) - use it! I don't always recommend sendmail, either.
Bobcat
disclaimer: I used to work for Sendmail, Inc. - my cubicle/cage was about 40 feet from where Nick used to sit...
Good luck... (Score:1)
There are always special circumstances, especially with things that have been around as long as sendmail, when there is no alternative to complete a specific task, but I *never* have run into one (only heard about a couple).
Use Exim, and trust Cambridge over Berkeley...
Best thing I ever did was *de*tune sendmail (Score:5, Informative)
You can run dictionary attacks against domains I handle mail for, but at least it will take you a damn long time! I just wish everybody was doing it. Eventually it would take too long to spam effectively.
Coming soon... (Score:1)
sendmail.cf humor (Score:1)
Sticking up for sendmail (Score:1)
Before you throw up your hands and try something else, read this. [astatic.net] I wrote this to clarify the concepts behind sendmail, and SMTP in general and to offer come canned configs for new users. If you use my HOWTO, you will be up and running in under 10 minutes, even if you are an MCSE. You don't have to be a 31337 UN1X DuD3 or anything to figure it out.
I have customers who run sendmail on very modest hardware that handle tens of thousands of messages per week for months on end with no attention required. I can do things that the other MTAs only wish they could do in their wettest dreams, even when installed on that old ProSignia sitting in the corner. Before you bash it, give it a try. If you still can't figure it out, send me an email.
XMAIL (Score:1)
are like me and got tired of trying to figure out sendmail, you should give XMAIL [xmailserver.org] a shot
It is both a SMTP and POP3 server, will soon support IMAP, and has been incredibly reliable and easy to
set up for me, YMMV.
Re:How to improve Sendmail performance. (Score:3, Informative)
Since Sendmail hasn't been monolithic for a couple of versions now, have you considered switching back?
Re:Simply, small, secure. (Score:2)
Re:I would love to get sendmail running (Score:2)
However, all POP protocols are brain-dead and lame. You should be using IMAP, which is supported by all decent end-user mailers (MUAs, or Mail User Agents) as well as by Microsoft's latest MUAs.
In v5-7.3 RedHats, type ntsysv from the command line and turn on IMAP (or, better yet, IMAPS, if you comprendhez crypto) and SENDMAIL in the runlevel of your preference (I recommend 3, since Xwindows is bloated and unreliable).
If you want an exchange server clone (NOTE: only really useful if you run Outlook, the world's absolute worst MUA for security and reliability, which runs only on proprietary opsystems that have high hardware requirements) use HP Openmail. Or wait for Miguel de Icaza to write something better.
One thing to remember, regardless of what MTA you use, it should NOT relay Email from any address other than 127.0.0.1 unless you specifically configure in the addresses/domains you want to relay from. So you will need to edit
I ran 400 users on redhat5.2+sendmail+ipop3d server and win98+pegasus clients, the clients popped the mail server every 7 seconds, and the server was a pentium 133 with four ethernet cards on it. No performance problems in our real-world shop.
For my users, reliability + performance = ability to generate profit = paychecks for workers. Features that cannot be obtained without sacrificing reliability or price/performance will not be implemented, because the goal is to earn enough to feed the kiddies, not to be 1337.
All that being said, I recommend you install Postfix rather than sendmail. I use sendmail because I already know how to do it, and it works with OpenLDAP. I don't think you fit the profile.
Re:Tuning for performance isn't really the problem (Score:1)
KTHXBYE!
Re:Die Sendmail, die!! (Score:2)
The best tuning is to get rid of that software (which was OK for the 80's, but not for the 21st century)....
You know, I would be angry at you moderators except your mothers are under my desk right now making me happy as I type