Seven of the most common causes for Web site crashes

Disk is full
The most likely cause of the system not working correctly is that the disk is full. A good network administrator will pay close attention to the use of the disk, a certain amount of time, you need to dump some of the load on the disk to the backup storage media (such as tape).
The log file will quickly run out of all disk space. The Web server's log files, sql*net log files, JDBC log files, and application server log files are all equally harmful to memory leaks. You can take steps to save the log file in a different file system than the operating system. The Web server will also be suspended when the log file system is full, but the chance of the machine itself being suspended is greatly reduced.

C Pointer Error
Programs written in C or C + +, such as the Web Server API module, can cause the system to crash because an error occurs in the indirect reference pointer (that is, access-directed memory), which causes the operating system to terminate all programs. In addition, Java Analog (analog), which uses a bad C pointer, accesses an empty object reference. A null reference in Java usually does not cause the JVM to exit immediately, but only if the programmer is able to handle the error appropriately using the exception handling method. In this regard, Java does not require much attention, but using Java to measure reliability with additional metrics can have some negative effects on performance.

Memory Leaks
Another pointer problem may be generated by C + + programs: Missing references to allocated memory. This problem typically occurs when memory is allocated in a subroutine, and the result is that the program does not free memory when it returns from the subroutine. As a result, a reference to the allocated memory is lost, and the process will always use that memory as long as the operating system is still running. As a result, programs that have used up more memory will degrade system performance until the machine completely stops working before it completely empties the memory.
One solution is to use code analysis tools, such as Purify, to carefully analyze the code to identify possible leak issues. However, this method cannot find leaks in libraries caused by other causes because the source code of the library is not available. Another way is to clear and restart the process every once in a while. The Apache Web server creates and cleans up child processes for this reason.
Although Java itself has no pointers, in general, Java programs use memory more poorly than C programs. In Java, objects are created frequently, and the garbage collector frees memory until all references to the object disappear. Even if you run the garbage collector, only the memory is returned to the virtual machine VM, not to the operating system. The result: Java programs run out of all their heaps and never release them. Because you want to save the code generated by the real-time (Just in Time,jit) compiler, the size of the Java program can sometimes swell to a number of times the maximum heap.
There is one more problem, which is similar to the situation. A database connection is assigned from the connection pool, and the allocated connection is not returned to the connection pool. Some connection pools have an active timer, and after a period of inactivity, the timer frees up the database connection, but that's not enough to alleviate the resource waste caused by the poor code's quick leak of the database connection.

Process lacks file descriptor
If a Web server or other critical process has been assigned a file descriptor, but it requires more file descriptors, the server or process will be suspended or error-marked until the desired file descriptor is obtained. File descriptors are used to keep track of open files and open sockets, and open files and open sockets are a critical part of a Web server that is tasked with copying files to a network connection. 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 inline ulimit command to increase the number of file descriptors.

Thread Deadlock
performance improvements caused by multithreading are at the cost of reliability, primarily because of the potential for thread deadlock. When a thread is deadlocked, the first thread waits for the second thread to release the resource while the second thread waits for the first thread to release the resource. Let's imagine a situation in which two people meet on the sidewalk, and in order to give way to each other, two people take one step at the same time, both sides cannot pass, and at the same time take a step to the other side, this still cannot pass. Both sides blocked each other's path in the same way. Assuming this continues, it is not difficult to understand why deadlocks occur.
There is no easy way to resolve deadlocks, because it is very specific to cause the thread to produce this problem and often has a high load. MostSoftwareNot enough load is generated, so it is impossible to expose all threading errors. There is a thread deadlock problem in each language that uses threading. Because of the use of Java thread programming is better than usingCEasy, soJavathe number of threads used in programmers is more, and thread deadlock is becoming more common. Can be inthe use of synchronous keywords in Java code can reduce deadlocks, but it also affects performance. If the load is too heavy, a deadlock may occur inside the database.
If a program uses a permanent lock, such as a lock file, and the program ends without unlocking the lock, other processes may not be able to use this type of lock, either locked or unlocked. This will further cause the system to not function properly. This must be manually unlocked.

Server Overload
Netscape Webeach connection to the server uses a single thread. Netscape Enterprise Web server hangs after the thread is exhausted, and does not provide any services for existing connections. If there is a load distribution mechanism to detect that the server is not responding, the load on that server can be distributed to otherthe Web server, this may cause these servers to run out of all threads one after another. As a result, the entire server group will be suspended. The operating system level may also continue to receive new connections, while the application (Webserver) But cannot service these connections. The user can see on the browser status lineconnected(connected) prompt message, but nothing will happen after this.
One way to solve the problem is toobj.confParametersRqthrottleis set to a value below the number of threads, so if it crosses the The Rqthrottle value, the new connection is not received. Servers that cannot connect will stop working and the servers on the connection will respond slowly, but at least the connected servers will not be suspended. At this point, the file descriptor should at least be set to the same number as the thread, otherwise the file descriptor becomes a bottleneck.

temporary tables in the database are not sufficient
The number of temporary tables (cursor) in many databases is fixed, and temporary tables retain the memory area of the query results. After the data in the staging table is read, the temporary table is freed, but a large number of simultaneous queries may run out of all temporary tables that are fixed. At this point, other queries need to be queued until a temporary table is released before it can continue to run.
This is a problem that is not easily noticed by programmers, but is exposed during load testing. However, this problem may be obvious to the database administrator (db administrator,dba).
In addition, there are some other problems: the table space is not set enough, the sequence number limit is too low, which can cause table overflow error. These issues indicate the importance of a good DBA for periodic checks of database settings and performance for production. Also, most database vendors provide monitoring and modeling tools to help address these issues.
In addition, there are a number of factors that are most likely to cause the Web site to not work. such as: correlation, subnet traffic overload, bad device drivers, hardware failures, wildcard characters including error files, and inadvertent locking of critical tables.

This article is from the "No Trace" blog, make sure to keep this source http://hackwuhen.blog.51cto.com/6253667/1420817