• Choose a category
• All
• Classic-Fiction

kern.maxfiles: 8192

kern.maxfilesperproc: 4096

If you can't figure out the file-descriptor limit, Squid's ./configure script can do it for you. When you run ./configure, as described in Section 3.4, watch for output like this near the end:

checking Maximum number of file descriptors we can open... 4096

If either limit, ulimit, or ./configure report a value less than 1024, you should invest the time to increase the limit before compiling Squid. Otherwise, Squid's performance will be poor under a moderate load.

Increasing the file descriptor limit varies from system to system. The following sections offer some tips to help get you started.

FreeBSD, NetBSD, OpenBSD

Edit your kernel configuration file, and add a line like this:

options MAXFILES=8192

On OpenBSD, use option instead of options. Then, configure, compile, and install the new kernel. Reboot your system so the change takes effect.

Linux

Configuring file descriptors on Linux is a little complicated. You must edit one of the system include files, and execute some shell commands before compiling and running Squid. Start off by editing the file /usr/include/bits/types.h. Change the value for _ _FD_SETSIZE as follows:

#define _ _FD_SETSIZE 8192

Next, increase the kernel file descriptor limit with this command:

# echo 8192 > /proc/sys/fs/file-max

Finally, increase the process file-descriptor limit in the same shell in which you will configure and compile Squid:

sh# ulimit -Hn 8192

This command must be executed as root and only works from the bash shell. There is no need to reboot on Linux.

* * *

Tip

With this technique, you must execute the echo and ulimit commands each time your system boots, or at least before starting Squid. If you use an rc.d script to start Squid (see Section 5.6.2), that is a good place to stick these commands.

* * *

Solaris

Add this line to your /etc/system file:

set rlim_fd_max = 4096

Then, reboot the system for the change to take effect.

Mbuf Clusters

The BSD-based networking code uses a data structure known as an mbuf (see W.R.Stevens' book, TCP/IP Illustrated, Vol 2). Mbufs are typically small (e.g., 128 octets) chunks of memory. The data for larger network packets are stored in mbuf clusters. The kernel may enforce an upper limit on the total number of mbuf clusters available in the system. You can find this limit with the netstat command:

% netstat -m

196/6368/32768 mbufs in use (current/peak/max):

146 mbufs allocated to data

50 mbufs allocated to packet headers

103/6182/8192 mbuf clusters in use (current/peak/max)

13956 Kbytes allocated to network (56% of mb_map in use)

0 requests for memory denied

0 requests for memory delayed

0 calls to protocol drain routines

In this example, there are 8,192 mbuf clusters available, but there are never more than 6,182 used at once. When the system runs out of mbuf clusters, I/O routines such as read( ) and write( ) return the "No buffer space available" error message.

NetBSD and OpenBSD don't display mbuf usage in netstat -m output. Instead, they report "WARNING: mclpool limit reached" via syslog.

To increase the number of mbuf clusters, you need to add an option to your kernel configuration file:

options NMBCLUSTERS=16384

Ephemeral Port Range

Ephemeral ports are the local port numbers the TCP/IP stack assigns to outgoing connections. In other words, when Squid makes a connection to an origin server, the kernel assigns a port number to the local socket. These local port numbers fall within a certain range. On FreeBSD, for example, the default ephemeral port range is 1024-5000.

A shortage of ephemeral ports may adversely affect performance for very busy proxies (i.e., hundreds of requests per second). This is because some TCP connections enter a TIME_WAIT state when they are closed. An ephemeral port number can't be reused while the connection is in the TIME_WAIT state.

You can see how many connections are in this state with the netstat command:

% netstat -n | grep TIME_WAIT

Proto Recv-Q Send-Q Local Address Foreign Address (state)

tcp4 0 0 192.43.244.42.19583