Web site Crash Reason Encyclopedia _ server

There are many reasons why a Web site might not work, which makes it difficult to systematically check all problems. The following is a central analysis of the most common problems that cause Web site crashes. If these conventional issues can be addressed, there will also be the ability to deal with some of the unexpected situations that arise.
The disk is full
The most likely cause of the system not functioning properly is that the disk is full. A good network administrator will pay close attention to disk usage and, at certain times, will need to dump some of the load on the disk onto the backup storage media (such as tape).
The log file quickly runs out of all disk space. The Web server's log files, sql*net log files, jdbc log files, and application server log files are equally harmful to memory leaks. You can take steps to save the log files in a different file system than the operating system. The Web server is also suspended when the log file system space is full, but the chance of the machine itself being suspended has been 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 in the indirect reference pointer (that is, access to memory) can cause the operating system to terminate all programs. In addition, using a bad C-pointer Java simulation (analog) will access an empty object reference. A null reference in Java typically does not result in an immediate exit from the JVM, but only if the programmer is able to properly handle the error using exception handling. In this regard, Java does not need much attention, but using Java to make additional measurements of reliability can have some negative impact on performance.
Memory leaks
There may also be another pointer problem with C + + programs: missing a reference to allocated memory. This problem usually occurs when memory is allocated in a subroutine, and the result is that the program does not release memory when it returns from a subroutine. As a result, a reference to the allocated memory is lost, and the process uses the memory as long as the operating system is still running. As a result, programs that used to consume more memory degrade system performance until the machine completely stops working to completely empty the memory.
One solution is to use code analysis tools, such as purify, to carefully analyze your code to identify possible leak problems. However, this method cannot find a leak in the library caused by other reasons, because the source code of the library is not available. Another approach is to clear and restart the process every once in a while. The Apache Web server creates and clears child processes for this reason.
Although Java itself does not have pointers, overall, Java programs use memory worse 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, you will only return the memory to the virtual machine VM, not to the operating system. As a result: Java programs will run out of all their heaps and never release them. The size of a Java program can sometimes swell to a number of times the maximum heap, because the code generated by the Just in Time,jit compiler is saved.
There is another problem, similar to this. A database connection is assigned from the connection pool, and the assigned connection is not returned to the connection pool. Some connection pools have active timers, which, after a period of inactivity, release the database connection, but this is not enough to mitigate the waste of resources caused by the poor code's fast leaking database connections.
Process lacks file descriptor
If a file descriptor has been assigned to a Web server or other critical process, but it requires more file descriptors, the server or process is suspended or an error occurs until the required 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 the Web server's task of copying files to a network connection. By default, most shells have 64 file descriptors, which means that each process initiated 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
The performance improvements made by multithreading are at the expense of reliability, mainly because it is possible to generate thread deadlocks. 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 where two people meet on the sidewalk, and in order to give way to each other, they take one step at a time, both cannot pass, and take a step towards the other side, which is still impossible to pass. Both sides have blocked the other way with the same approach. Assuming this continues, it is not difficult to understand why deadlocks occur.
There is no easy way to resolve deadlocks, because it is a very specific situation that causes threads to produce this problem and tends to have a high load. Most software tests do not produce enough load, so it is not possible to expose all thread errors. There is a thread deadlock problem in every language that uses threads. Because using Java for threading is easier than using C, the number of threads used in Java programmers is greater, and thread deadlocks are becoming more common. You can increase the use of synchronization keys in Java code to reduce deadlocks, but doing so can also affect performance. If the load is too heavy, deadlocks may also occur inside the database.
If a program uses a permanent lock, such as a lock file, and the program ends without unlocking, 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 unlocked manually.
Server overload
Every connection to a Netscape Web server uses one thread. Netscape Enterprise Web server hangs when the thread is finished, and does not provide any services for existing connections. If there is a load distribution mechanism that detects that the server is not responding, the load on that server can be distributed to other Web servers, which 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, and applications (Web servers) cannot service these connections. The user can see the connected (connected) prompt message on the browser's state line, but nothing will happen after that.
One way to solve the problem is to set the value of the obj.conf parameter rqthrottle to a number below the thread count, so that if the value of Rqthrottle is crossed, the new connection is not received. Those servers that cannot connect will stop working, and the servers on the connection will slow down, but at least the connected servers will not be suspended. At this point, the file descriptor should be set at least 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) for many databases is fixed, and a temporary table is the area of memory that retains the results of the query. Once the data in the temporary table is read, the temporary table is freed, but a large number of simultaneous queries may run out of all the temporary tables that are fixed. At this point, other queries need to be queued until a temporary table is freed before it can be run again.
This is a problem that is not easily noticed by programmers, but it will be exposed during a load test. However, the problem may be obvious to the database administrator (db administrator,dba).
In addition, there are a number of other problems: The table space is not set, the ordinal limit is too low, which can cause a table overflow error. These issues indicate the importance of a good DBA for periodic inspection of database settings and performance for production. Also, most database vendors provide monitoring and modeling tools to help solve these problems.
In addition, there are a number of factors that are most likely to cause web sites to not work. such as: dependencies, subnet traffic overload, poor device drivers, hardware failures, wildcard characters including error files, and accidentally locked key tables.