Why my e-mail server slows down

Everything is so quiet, all the Internet services are silently working. However, in recent times, people often call to reflect the same problem: in the receipt of e-mail, the server side often answer the timeout, which can not normally receive e-mail, but if you receive a while later, it may be received normally. People have shown great dissatisfaction with this. So we quickly start looking for the root of the problem and try to fix it as quickly as possible.

　　first, access to basic information

First we looked at the archive, confirmed the e-mail run in a configuration for PIII 500mhz,128m memory, 20G hard drive on the IPC, the operating system is Redhat Linux 6.5, using SendMail as an e-mail Server, and use the system passwd file as the SendMail mail user's authentication document.

Users of this messaging system have been developing very rapidly over the period of time, according to the network management log, and the number of users has increased from 10,000 to more than 20,000.

　　Second, preliminary analysis

By understanding the above information, we basically recognize that the main reason for slow speed is the increase in user volume. Therefore, the analysis is carried out under this premise.

Under the Linux console, enter the following command to view the process of the system:

Ps–auxw

We found that the command listed a large number of send mail and pop processes. Then according to the records of the network management log, respectively in the low peak, average, peak period of concurrent user checks, found in the peak situation, the number of concurrent users from the original 20 users up to 40 users.

So far, we have come to the conclusion that because of the growing number of users, concurrent users are more and more, so that the machine can not handle these concurrent requests, so that the e-mail server response to users too slow, or even timed out to use. Therefore, we believe that the solution to this problem is to upgrade the machine.

　　third, in-depth analysis

At this time, we suddenly notice the number 40, we feel that the current use of the e-mail server server performance should not be able to handle 40 users at the same time access. We have a faint sense that the previous analysis must have been overlooked, so that an incorrect result has been obtained.

So we looked at another server with the same configuration, which is running the Web service, and we found that the server did not feel inadequate in processing 50 simultaneous user visits.

At this point, we began to further analyze the whole process of e-mail service. First, the user's mail receiving program through the POP protocol and the server's pop module to communicate, and provide user name and password; then the pop module of the e-mail server will encrypt the password provided by the user, and then match the user's password in the system file/ETC/PASSWD. and find the corresponding user name, and then a second match, if the match succeeds, the checksum passes, otherwise the user name or password is returned incorrectly. After the checksum is passed, the server starts sending messages belonging to that user to the user's mail recipient. At this time, we thought, all the user connection has a common link, that is to open the system file/etc/passwd, user verification, will not be the bottleneck problem?

So, let's just enter the following command on the Linux console to see how many processes are using the/etc/passwd file:

fuser/etc/passwd

At this time, listed a lot of pop process, the crux finally found. The original is because the system file/etc/passwd is a text file, in the user name, password matching process, is to use line to match, and our/etc/passwd file has more than 20,000 lines, so the best case is the first match on the success, the worst case is 20,000 times after the match is successful, So the average needs to match 10,000 times. This process consumes enough time to cause the e-mail receiver to timeout, and cannot wait until the match is over.

　　Iv. methods of settlement

The root of the fault is found, and the solution is naturally simple. Because the server pop module verifies a user's identity by searching for a password file for a long time, the process accumulates, which in fact adds to the burden of the system, which means that users who are using the mail receiver will remain connected for a long time and will not be able to do the next job properly. Therefore, the main solution is to use File file/etc/passwd method into the form of a database.

Therefore, one of the following two methods can be used to resolve:

1 Use Linux NIS system to transform the system's password file/etc/passwd into NIS information base. Because NIS uses the database engine, it runs so that it is easy to find, and the efficiency can be greatly improved.

2 Reconfigure SendMail, so that it does not use the system file/etc/passwd for user verification, but the use of a specific database storage, because it is also using the database engine, so run up, easy to query, efficiency can also be greatly improved.

You can also use Postfix and other built-in database support of the e-mail system to replace SendMail, because Postfix can be directly on the basis of sendmail data conversion, because some of the whole operation is very simple.

　v. Resolution of the effect

We finally adopted the Postfix replacement SendMail, the conversion of its user password list into a database mode, the problem is solved. Now that we are still using this machine, and the user has grown to 30,000, the number of users in the peak period has risen from 40 to 60-70, but now the system is still in an orderly manner, running well.

　　Six, Experience

In this simple example, we are deeply aware of the need to carefully analyze the problem in day-to-day system management, rather than easily attributing the problem to server hardware capabilities.

The main approach is to carefully and realistically examine what each process is doing; Carefully study the entire process of the service, analyze where the problem is most likely to occur, and then design the corresponding testing work, collect the situation, and prove it. Only in this way can the final positioning of the problem, and on this basis to put forward effective solutions, and ultimately solve the problem.

At the same time also from the other side to tell every webmaster, daily active and effective record of some of the changes in the network, in the event of failure, these data can effectively provide data for problem analysis.