Analysis of Reasons for IIS web site crash

There are many reasons why the web site may not work properly, which makes it difficult to check all problems systematically. The following will analyze and summarize the most common problems that cause the web site to crash. If you can solve these general problems, you will be able to deal with unexpected situations.

The disk is full.

The most likely cause of system failure is that the disk is full. A good network administrator will pay close attention to the disk usage. after a certain period of time, some loads on the disk need to be transferred to the backup storage media (such as tape ).

Log Files will soon use up all disk space. Web server log files, SQL * Net log files, JDBC log files, and applicationsProgramServer log files are equally harmful to memory leaks. You can save log files in different file systems than the operating system. When the log file system space is full, the web server will also be suspended, but the chance of the machine being suspended is greatly reduced.

C Pointer Error

Programs written in C or C ++, such as the Web Server API module, may cause system crash, because as long as the pointer is indirectly referenced (that is, access to the memory pointed) if an error occurs, the operating system terminates all programs. In addition, the Java analog (analog) with a bad C pointer will access an empty object reference. A blank reference in Java usually does not cause the JVM to exit immediately, but the premise is that the programmer can use the Exception Handling Method to properly handle the error. In this regard, Java does not require much attention, but using Java to perform additional measurements on reliability will have some negative impact on performance.

Memory leakage

The C/C ++ program may also cause another pointer problem: the reference to the allocated memory is lost. When the memory is allocated in the subroutine, this problem usually occurs. The result is that the program will not release the memory when it returns from the subroutine. As a result, the reference to the allocated memory will be lost. As long as the operating system is still running, the process will continue to use the memory. As a result, programs that have occupied more memory will reduce the system performance and completely clear the memory until the machine stops working completely.

One solution is to useCodeAnalysis tools (such as purify) carefully analyze the code to identify possible leaks. However, this method cannot find the library leakage caused by other reasons, because the librarySource codeIs unavailable. Another method is to clear and restart the process at intervals. The Apache Web Server creates and clears sub-processes for this reason.

Although Java itself does not have pointers, in general, the memory usage of Java programs is worse than that of C Programs. In Java, objects are frequently created, and the garbage collection program will release the memory until all references to the objects disappear. Even if the garbage collection program is run, the memory is returned to the VM rather than the OS. The result is that the Java program runs out of all the heaps and never releases them. To save the code generated by the just in time (JIT) compiler, the size of a Java program may sometimes expand to several times the maximum heap.

Another problem is similar. Allocate a database connection from the connection pool, but cannot return the allocated connection back to the connection pool. Some connection pools have active timers. After a period of static state is maintained, the timer will release the database connection, but this is not enough to alleviate the waste of resources caused by the rapid leakage of bad code database connections.

The process lacks file descriptors.

If a file descriptor has been assigned to a Web server or another key process, but it requires more file descriptors, the server or process will be suspended or report an error, until the required file descriptor is obtained. File descriptors are used to keep track records of open files and open sockets. Open files and open sockets are critical components of web servers, and their tasks are to copy files to network connections. By default, most shells have 64 file descriptors, which means that each process started from the shell can open 64 files and network connections at the same time. Most shells have an embedded ulimit command to increase the number of file descriptors.

Thread deadlock

The performance improvement brought about by multithreading is at the cost of reliability, mainly because it may lead to a thread deadlock. When a thread is deadlocked, the first thread waits for the second thread to release resources, and the second thread is waiting for the first thread to release resources. Let's imagine a situation where two people face each other on the sidewalk. In order to give way to each other, the two take one step at the same time, and the two sides cannot pass, while taking one step at the same time, this still fails. Both parties blocked the other party's path in the same way. Assuming that this situation persists, it is difficult to understand why a deadlock occurs.

There is no simple way to solve the deadlock, because it is very specific to cause this problem to the thread, and there is often a high load. Most software tests do not generate enough load, so it is impossible to expose all thread errors. There is a thread deadlock problem in every language that uses threads. Since it is easier to use Java for Thread Programming than to use C, there are more threads used by Java programmers, and thread deadlocks become more and more common. You can add synchronization keywords in Java code to reduce deadlocks, but this will also affect performance. If the load is too heavy, the database may also experience deadlocks.

If the program uses a Permanent Lock, such as a lock file, and the lock state is not lifted at the end of the program, other processes may not be able to use this type of lock, neither locking nor unlocking. This will further cause the system to become abnormal. In this case, you must manually unlock it.

Server overload

Each connection of the Netscape Web server uses a thread. The Netscape Enterprise Web Server suspends after the threads are used up without providing any services for existing connections. If a load distribution mechanism detects that the server has no response, the load on the server can be distributed to other web servers, this may cause these servers to use up all threads one by one. In this way, the entire server group will be suspended. At the operating system level, new connections may still be received, but applications (Web servers) cannot provide services for these connections. You can see the connected message in the browser status line, but nothing will happen in the future.

One way to solve the problem is to set the value of rqthrottle in OBJ. conf to a value under the number of threads, so that if the value of rqthrottle is crossed, no new connections will be received. Those servers that cannot be connected will stop working, and the response speed of the connected servers will slow down, but at least the connected servers will not be suspended. In this case, the file descriptor should be set to at least the same value as the number of threads. Otherwise, the file descriptor will become a bottleneck.

Temporary tables in the database are not enough

The number of temporary tables (cursor) in many databases is fixed. The temporary table retains the memory area of the query results. After the data in the temporary table is read, the temporary table is released, but a large number of simultaneous queries may consume a fixed number of temporary tables. In this case, other queries need to wait until a temporary table is released.

This is a problem that cannot be easily discovered by programmers, but will be exposed during load testing. However, this problem may be obvious for database administrators (DBAs.

In addition, there are some other problems: the table overflow error may occur if the tablespace is not enough and the number limit is too low. These problems indicate the importance of a good DBA to regularly check the database settings and performance for production. Most database vendors also provide monitoring and modeling tools to help solve these problems.

In addition, there are also many factors that may make the web site unable to work. Such as: correlation, subnet traffic overload, bad device drivers, hardware faults, wildcards including error files, accidentally locking key tables.