To assist with the rapid processing of requests, NGINX uses hash tables.
During startup and with each reconfiguration, NGINX selects the smallest possible size for the hash tables, taking into account the size of basket, where keys with the coinciding hashed values fall, would not exceed the assigned parameter (hash bucket size).
Selection is conducted until the size of table exceeds parameter hash max size. For the majority of hashes there are directives, which make it possible to change these parameters. For example, the hash with the names of servers are controlled by the directives server_names_hash_max_size and server_names_hash_bucket_size. Parameter hash bucket size is always equalized to the size, multiple to the size of the line of processor cache. This makes it possible to accelerate the search for key in hash on processors, after decreasing the number of turnings to memory. If hash bucket size is equal to the size of one line of processor cache, then during the search for key the number of turnings to memory in the worst case will be equal to two - for the first time for determining the address of basket, and the second - with the search for key inside the basket. Accordingly, if NGINX gave out communication about the need for increasing hash max size or hash bucket size, then it is first necessary to increase the first parameter.
NGINX supports the following methods of treating the connections, which
can be assigned by the
/proc/sys/kernel/rtsig-max. However, starting with Linux 2.6.6-mm2, this parameter is no longer available, and for each process there is a separate queue of signals, the size of which is assigned by RLIMIT_SIGPENDING. When the queue becomes overcrowded, NGINX discards it and begins processing connections using the
pollmethod until the situation normalizes.