6.13. Ajustando Limites do Kernel

6.13.1.1. kern.maxfiles

A variável kern.maxfiles pode ter seu valor aumentado ou diminuido baseado nos requisitos do sistema. Esta variável indica o número máximo de descritores de arquivos no seu sistema. Quando a tabela de descritores de arquivos está cheia, a mensagem file: table is full aparecerá várias vezes no buffer de mensagens do sistema, que pode ser visualizado através do comando dmesg.

Cada arquivo aberto, socket, ou fifo usa um descritor de arquivo. Um servidor de produção de larga escala pode facilmente requerer muitos milhares de descritores de arquivos, dependendo do tipo e do número de serviços sendo executados concorrentemente.

O valor padrão da variável kern.maxfile é definido pela opção MAXUSERS no seu arquivo de configuração de kernel. kern.max.files cresce proporcionalmente ao valor de MAXUSERS. Ao compilar um kernel customizado, é uma boa idéia modificar esta configuração de acordo com o uso do seu sistema. A partir deste número, o kernel toma base para muitos limites pré-definidos. Embora uma máquina em produção não tenha 256 usuários conectados ao mesmo tempo, os recursos requeridos podem ser similares aos de um servidor de ponta.

6.13.1.2. kern.ipc.somaxconn

A variável sysctl kern.ipc.somaxconn limita o tamanho da fila de escuta para aceitação de novas conexões TCP. O valor padrão de 128 é tipicamente baixo para uma manipulação robusta de novas conexões em um ambiente de servidor web com alta carga. Para tais ambientes o aumento deste valor para 1024 ou mais é recomendado. O serviço de daemon pode por si só limitar o tamanho da fila (por exemplo, sendmail(8), ou Apache) mas na maioria das vezes existirá uma diretiva em seus arquivos de configuração para ajustar o tamanho da fila. Filas de escuta grandes também podem fazer um bom trabalho evitando ataques de Negação de Serviço (DoS).

6.13.2.1. net.inet.ip.portrange.*

A variável sysctl net.inet.ip.portrange.* controla a faixa de número de portas automaticamente ligadas a sockets TCP e UDP. Existem três faixas: a baixa, a padrão e a faixa alta. Muitos programas de rede usam a faixa padrão, que é controlada pela variável net.inet.ip.portrange.first e net.inet.ip.portrange.last, que possuem valores padrão 1024 e 5000, respectivamente. Faixas de porta padrão são usadas para conexões que saem, e é possível ficar sem portas sob certas circunstâncias. Isto ocorre de forma mais comum quando você roda um servidor proxy que tem muita carga. A faixa de portas não é um problema quando se executa servidores cujo papel principal é receber conexões, como um servdor web normal, ou um servidor que possui um número limitado de conexões que saem, como um relay de correio. Para situações onde você pode ficar sem portas, é recomendado que se aumente modestamente a variável net.inet.ip.portrange.last. Um valor de 10000, 20000 ou 30000 deve ser suficiente. Você também deve considerar os efeitos colaterais que a mudança de faixa de portas pode causar em um firewall. Alguns firewalls podem bloquear grandes faixas de portas (geralmente portas de números baixos) e esperar que os sistemas utilizem faixas de portas altas para conexões que saem -- por esta razão recomenda-se que a variável net.inet.ip.portrange.first tenha seu valor diminuido.

6.13.2.2. TCP Bandwidth Delay Product

A Limitação do Produto de Atraso de Banda TCP é similar ao TCP/Vegas no NetBSD. Pode ser habilitado através da configuração da variável sysctl net.inet.tcp.inflight_enable para o valor 1. O sistema tentará calcular o produto do atraso de banda para cada conexão e limitar a quantidade de dados enfileirados para a rede para apenas a quantidade requerida, com o objetivo de otimizar a quantidade de dados entrando e saindo.

Esta característica é útil se você está servindo dados através de modems, Gigabit Ethernet, ou até mesmo links WAN de alta velocidade (ou qualquer outro link com um alto produto de atraso de banda), especialmente se você também está usando escalamento de janela ou possui uma grande janela de envio configurada. Se você habilitar esta opção, você deve ter certeza de configurar a variável net.inet.tcp.inflight_debug para 0 (desabilitar depuração), e para produção configurar net.inet.tcp.inflight_min para pelo menos 6144 pode ser benéfico. Entretanto, note que configurar valores mínimos altos pode efetivamente desabilitar a limitação de banda dependendo do link. A característica de limitação reduz a quantidade de dados construídos na roda intermediária e trocar as filas de pacotes assim como reduzir a quantidade de dados construídos na interface de enfileiramento da máquina local. Com poucos pacotes enfileirados, conexões interativas, especialmente sob modems lentos, também serão capazes de operar com tempos reduzidos de Round Trip. Entretanto, note que esta característica tem efeito apenas na transmissão de dados (envio de dados / lado do servidor). Não tem efeito na recepção de dados (download)

Ajustar o valor de net.inet.tcp.inflight_stab não é recomendado. Este parâmetro tem valor 20 como padrão, representando 2 pacotes máximos adicionados ao cálculo de janela de produto de atraso de banda. A janela adicional é requerida para estabilizar o algoritmo e melhorar a resposta em condições de mudança, mas também pode resultar em tempos altos de ping em links lentos (ainda mais lentos do que você teria sem o algoritmo inflight). Nestes casos, você pode querer tentar reduzir este parâmetro para 15, 10 ou 5; e talvez tenha que reduzir a variável net.inet.tcp.inflight_min (por exemplo, para 3500) para obter o efeito desejado. Reduzir estes parâmetros deve ser feito como um último recurso somente.