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.
Nota: Assim como no FreeBSD 4.5, configurar a opção MAXUSERS para 0 no seu arquivo de configuração de kernel faz com que um valor padrão razoável seja configurado de acordo com a memória RAM presente no seu sistema.
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).
A opção de configuração de kernel NMBCLUSTERS dita a quantidade de Mbufs de rede disponível para o sistema. Um servidor com muito tráfego e um número pequeno de Mbufs limitarão a habilidade do FreeBSD. Cada cluster representa aproximadamente 2 K de memória, então um valor de 1024 representa 2 megabytes de memória de kernel reservada para buffers de rede. Um cálculo simples pode ser feito para saber quantos são necessários. Se você possui um servidor web que chega a um máximo de 1000 conexões simultâneas, e cada conexão consome 16 K de buffer de envio e 16 K de recepção, você precisa de aproximadamente 32 MB de buffers de rede para cobrir seu servidor web. Uma boa regra geral é multiplicar por 2, então 2x32 MB / 2 KB = 64 MB / 2 kB = 32768. Recomendamos valores entre 4096 e 32768 para máquinas com grandes quantidades de memória. Sob nenhuma circunstância você deve especificar valores arbitrariamente altos para este parâmetro, pois pode causar travamentos durante a inicialização. A opção -m do netstat(1) pode ser usada para observar o uso do cluster de rede.
kern.ipc.nmbclusters pode ser usado para ajustar isto no momento da inicialização. Somente versões antigas do FreeBSD irão requerer o uso da opção config(8) de kernel NMBCLUSTERS.
Para servidores mais ocupados, que fazem uso extensivo da chamada de sistema sendfile(2), pode ser necessário aumentar o número de buffers sendfile(2) através da opção de configuração de kernel NSFBUFS colocando seu valor no arquivo /boot/loader.conf (veja loader(8) para mais detalhes). Um indicador comum que indica que este parâmetro precisa ser ajustado é quando processos são vistos no estado ``sfbufa''. A variável sysctl kern.ipc.nsfbufs oferece uma visão apenas de leitura de como esta variável está configurada no kernel . Este parâmetro aumenta nominalmente com o kern.maxusers, entretanto pode ser necessário ajustar de acordo com a necessidade.
Importante: Mesmo que o socket tenha sido marcado como não bloqueador, invocar o sendfile(2) neste socket pode resultar em bloqueamento de chamadas no sendfile(2) até que struct sf_buf's tenham sido disponibilizados.
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.
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.
Este, e outros documentos, podem ser obtidos em ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.
Para perguntas sobre FreeBSD, leia a documentação antes de contatar <questions@FreeBSD.org>.
Para perguntas sobre esta documentação, envie e-mail para <doc@FreeBSD.org>.