Complete port> resource restrictions (Collection)

Resource restrictions

Robustness is the primary goal when designing any server application. That is to say,

Your application must be able to cope with any unexpected problems, such as the peak number of concurrent customer requests, the temporary shortage of available memory, and other short-term phenomena. This requires the program designers to pay attention to the resource restrictions in Windows NT and 2000 systems and handle emergencies with ease.

The most basic resource you can directly control is the network bandwidth. Generally, applications using User Datagram Protocol (UDP) may pay more attention to bandwidth restrictions to minimize packet loss. However, when using TCP connections, the server must be carefully controlled to prevent network bandwidth overload from exceeding a certain period of time. Otherwise, a large number of packets may need to be resold or cause a large number of connection interruptions. The bandwidth management method should be determined based on different applications, which is beyond the scope discussed in this article.

The use of virtual memory must also be managed very carefully. By carefully applying for and releasing memory or applicationsLookaside lists(A high-speed cache) technology to reuse allocated memory will help to control the memory overhead of server applications (the original article is "Let the server application leave a little footprint "), this prevents the operating system from frequently switching the physical memory applied by the application to the virtual memory (the original article is "enabling the operating system to always keep more application address space in the memory "). You can alsoSetworkingsetsize ()This Win32 API allows the operating system to allocate more physical memory to your applications.

When using WinSock, you may encounter two other non-direct resource insufficiency situations. One is the limit of the locked memory page. If you disable the buffer of AFD. sys, when the application sends and receives data, all pages in the application buffer will be locked to the physical memory. This is because the kernel driver needs to access the memory, during which these pages cannot be exchanged. If the operating system needs to allocate some paging physical memory to other applications, and there is not enough memory, the problem will occur. Our goal is to prevent writing a sick program that locks all the physical memory and crashes the system. That is to say, when your program locks the memory, do not exceed the system's memory paging limit.

On Windows NT and 2000 systems, the total memory that all applications can lock is about 1/8 of the physical memory (but this is only a rough estimate, not the basis for your computing memory ). If your application does not pay attention to this, when you issue too many overlapping sending and receiving calls and I/O is not completed, the error error_insufficient_resources may occasionally occur. In this case, you must avoid over-locking the memory. At the same time, note that the system will lock the entire memory page that contains your buffer, so there is a price when the buffer is close to the page boundary (the translator understands that if the buffer just exceeded the page boundary, even if it is 1 byte, the page where the extra byte is located will also be locked ).

Another restriction is that your program may encounter a systemNon-Paging poolInsufficient resources. The so-calledNon-Paging poolIt is a memory area that will never be swapped out. This memory is used to store data accessed by various kernel components. Some kernel components cannot access those page spaces that are swapped out. Drivers for Windows NT and 2000 can allocate memory from this particular non-Paging pool.

When an application creates a socket (OR opens a file in a similar way), the kernel will not allocate a certain amount of memory in the paging pool, and when the socket is bound or connected, the kernel will not reallocate some memory in the paging pool. When you observe this behavior, you will find that if you send some I/O requests (such as sending and receiving data ), you will not allocate more memory in the paging pool (for example, to track a pending I/O operation, you may need to add a custom structure for this operation, as mentioned above ). In the end, this may cause some problems. The operating system will limit the amount of non-Paging memory.

On Windows NT and 2000 operating systems, the number of non-Paging memory allocated to each connection is different, and Windows may be different in future versions. In order to make the application have a longer life cycle, you should not calculate the specific demand for memory in the non-Paging pool.

Your program must prevent consumption to the limit of the non-Paging pool. When there is too much space in the paging pool in the system, some kernel drivers that have nothing to do with your applications will go crazy and even cause system crashes, this is especially likely to happen (and unpredictable) when there are third-party devices or drivers in the system ). At the same time, you also need to remember that there may be other applications that consume non-Paging pools on the same computer, so when designing your applications, we should be especially conservative and cautious in estimating the amount of resources.

It is very complicated to handle the problem of insufficient resources, because you will not receive any special error code in the case above. Generally, you can only receive general wsaenobufs or error_insufficient_resources errors. To handle these errors, first adjust the working configuration of your application to a reasonable maximum value, see the http://msdn.microsoft.com/msdnmag/issues/1000/Bugslayer/Bugslayer1000.asp for memory optimization. If errors continue, check whether the network bandwidth is insufficient. Then, make sure that you have not sent too many sending and receiving calls at the same time. Finally, if you still receive the error of insufficient resources, it is likely that you have encountered the problem of insufficient memory pool without paging. To release the non-Paging memory pool space, close a considerable number of connections in the application and wait for the system to pass through and correct this instantaneous error.