11.11. Ajustando os Limites do Kernel

11.11.1. Limites de arquivos/processos

11.11.1.1. kern.maxfiles

A variável kern.maxfiles sysctl(8) pode ser aumentada ou diminuída com base nos requisitos do sistema. Essa variável indica o número máximo de descritores de arquivos no sistema. Quando a tabela do descritor de arquivos estiver cheia, o erro file: table is full aparecerá repetidamente no buffer de mensagem do sistema, que pode ser visualizado usando dmesg(8).

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

Em versões mais antigas do FreeBSD, o valor padrão de kern.maxfiles é derivado do maxusers no arquivo de configuração do kernel. O kern.maxfiles cresce proporcionalmente ao valor do maxusers. Ao compilar um kernel personalizado, considere configurar esta opção de configuração do kernel de acordo com o uso do sistema. A partir desse número, o kernel recebe a maioria dos seus limites predefinidos. Mesmo que uma máquina de produção não tenha 256 usuários simultâneos, os recursos necessários podem ser semelhantes a um servidor da Web de alta escala.

A variável read-only sysctl(8)kern.maxusers é dimensionada automaticamente na inicialização com base na quantidade de memória disponível no sistema, e pode ser determinado em tempo de execução, inspecionando o valor de kern.maxusers. Alguns sistemas requerem valores maiores ou menores de kern.maxusers e valores de 64, 128, e 256 não são incomuns. Ir acima de 256 não é recomendado, a menos que seja necessário um grande número de descritores de arquivos. Muitos dos valores ajustáveis definidos para seus padrões por kern.maxusers podem ser individualmente sobrescritos no tempo de inicialização ou em tempo de execução no /boot/loader.conf. Consulte loader.conf( 5 ) e /boot/defaults/loader.conf para mais detalhes e algumas dicas.

Em versões mais antigas, o sistema ajustará automaticamente o maxusers se ele estiver definido como 0. [2]. Ao configurar esta opção, configure o maxusers para pelo menos 4, especialmente se o sistema executar o Xorg ou se for usado para compilar software. A tabela mais importante definida por maxusers é o número máximo de processos, que é definido como 20 + 16 * maxusers. Se maxusers for definido como 1, só podem existir 36 processos simultâneos, incluindo 18 ou mais para que o sistema seja iniciado no boot ou 15 usado pelo Xorg. Até mesmo uma tarefa simples, como ler uma página de manual, iniciará nove processos para filtrar, descompactar e visualizar. Configurar o maxusers para 64 permite até 1044 processos simultâneos, o que deve ser suficiente para quase todos os usos. Se, no entanto, o erro proc table full for exibido ao tentar iniciar outro programa ou se um servidor estiver sendo executado com um grande número de usuários simultâneos, aumente o número e recompile.

Nota:

O maxusers não limita o número de usuários que podem logar na máquina. Em vez disso, ele configura vários tamanhos de tabela para valores razoáveis, considerando o número máximo de usuários no sistema e quantos processos cada usuário executará.

11.11.1.2. kern.ipc.soacceptqueue

A variável kern.ipc.soacceptqueue do sysctl(8) limita o tamanho da fila de escuta para aceitar novas conexões TCP. O valor padrão de 128 é normalmente muito baixo para o manuseio robusto de novas conexões em um servidor Web com carga pesada. Para tais ambientes, recomenda-se aumentar este valor para 1024 ou superior. Um serviço como o sendmail(8), ou Apache pode limitar por ele mesmo o tamanho da fila de escuta, mas frequentemente terá uma diretiva em seu arquivo de configuração para ajustar o tamanho da fila. Filas de escuta grandes fazem um trabalho melhor evitando ataques de negação de serviço (Denial of Service - DoS).

11.11.2. Limites de rede

A opção de configuração do kernel NMBCLUSTERS determina a quantidade de Mbufs de rede disponível para o sistema. Um servidor com muito tráfego e um baixo número de Mbufs prejudicará o desempenho. Cada cluster representa aproximadamente 2K de memória, portanto, um valor de 1024 representa 2 megabytes de memória do kernel reservada para buffers de rede. Um cálculo simples pode ser feito para descobrir quantos são necessários. Um servidor web que suporte um maximo de 1000 conexões simultâneas onde cada conexão usa um buffer de envio de 16K e recebe 6K, requer aproximadamente 32 MB de buffers de rede para cobrir o servidor web. Uma boa regra é multiplicar por 2, então 2x32MB / 2KB = 64MB / 2kB = 32768. Valores entre 4096 e 32768 são recomendados para máquinas com maiores quantidades de memória. Nunca especifique um valor arbitrariamente alto para este parâmetro, pois isso pode levar a uma falha no tempo de inicialização. Para observar o uso do cluster de rede, use a opção -m com o netstat(1).

A variável kern.ipc.nmbclusters deve ser usada para configurar isso no momento da inicialização. Apenas as versões mais antigas do FreeBSD irão requerer o uso da opção NMBCLUSTERS no config(8) do kernel.

Para servidores 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 do kernel NSFBUFS ou definindo seu valor no /boot/loader.conf (veja loader(8) para detalhes). Um indicador comum de que esse parâmetro precisa ser ajustado é quando os processos são vistos no estado sfbufa. A variável sysctl(8) kern.ipc.nsfbufs é somente de leitura. Este parâmetro nominalmente escala com o kern.maxusers, no entanto, pode ser necessário ajustar de acordo.

Importante:

Mesmo que um socket tenha sido marcado como non-blocking, chamar o sendfile(2) em um socket non-blocking pode resultar no bloqueio do sendfile(2) até que sejam disponibilizados struct sf_buf suficientes.

11.11.2.1. net.inet.ip.portrange.*

As variáveis net.inet.ip.portrange.* do sysctl(8) controlam os intervalos de números de porta automaticamente ligados a sockets TCP e UDP. Existem três intervalos: um intervalo baixo, um intervalo padrão e um intervalo alto. A maioria dos programas de rede usam o intervalo padrão que é controlado por net.inet.ip.portrange.first e net.inet.ip.portrange.last, cujo padrão é 1024 e 5000, respectivamente. Intervalos de porta ligados são usados para conexões de saída e é possível executar o sistema fora das portas sob certas circunstâncias. Isso ocorre mais comumente ao executar um proxy web com muita carga. O intervalo de portas não é um problema ao executar um servidor que lida principalmente com conexões de entrada, como um servidor Web, ou que tenha um número limitado de conexões de saída, como um mail relay. Para situações em que há falta de portas, é recomendado aumentar modestamente o net.inet.ip.portrange.last. Um valor de 10000, 20000 ou 30000 pode ser razoável. Considere os efeitos do firewall ao alterar o intervalo de portas. Alguns firewalls podem bloquear grandes intervalos de portas, geralmente portas de numeração baixa, e esperam que os sistemas usem intervalos mais altos de portas para conexões de saída. Por esta razão, não é recomendado que o valor de net.inet.ip.portrange.first seja diminuído.

11.11.2.2. Produto de atraso de largura de banda TCP

A limitação do produto de atraso de largura de banda TCP pode ser ativada configurando a variável net.inet.tcp.inflight.enable do sysctl(8) para 1. Isso instrui o sistema a tentar calcular o produto de atraso de largura de banda para cada conexão e a limitar a quantidade de dados na fila para envio à rede para a quantidade necessária para manter o rendimento ideal.

Esse recurso é útil ao servir dados sobre modems, Gigabit Ethernet, links WAN de alta velocidade ou qualquer outro link com um produto de atraso de largura de banda alta, especialmente quando também estiver usando dimensionamento de janela ou quando uma janela de envio grande tiver sido configurado. Ao habilitar essa opção, defina também a variável net.inet.tcp.inflight.debug para 0 para desabilitar a depuração. Para uso em produção, definir a variável net.inet.tcp.inflight.min para pelo menos 6144 pode ser benéfico. Definir valores mínimos altos pode efetivamente desabilitar a limitação de largura de banda, dependendo do link. O recurso de limitação reduz a quantidade de dados acumulados nas rotas intermediárias e nas filas de pacotes de switchs e reduz a quantidade de dados acumulados na fila de interface do host local. Com menos pacotes enfileirados, as conexões interativas, especialmente os modems lentos, funcionarão com menores Round Trip Times. Esse recurso afeta apenas a transmissão de dados do lado do servidor, como o upload. Não tem efeito na recepção ou download de dados.

Ajustar o valor da variável net.inet.tcp.inflight.stab não é recomendado. Este parâmetro é padronizado para 20, representando 2 pacotes máximos adicionados ao cálculo da janela de produto de atraso de largura de banda. A janela adicional é necessária para estabilizar o algoritmo e melhorar a capacidade de resposta às mudanças de condições, mas também pode resultar em um ping(8) mais alto em links lentos , embora ainda muito menor do que sem o algoritmo inflight. Nesses casos, tente reduzir esse parâmetro para 15, 10 ou 5 e reduza a variável net.inet.tcp.inflight.min para um valor como 3500 para obter o efeito desejado. A redução desses parâmetros deve ser feita apenas como último recurso.

11.11.3. Memória virtual

11.11.3.1. kern.maxvnodes

Um vnode é a representação interna de um arquivo ou diretório. Aumentar o número de vnodes disponíveis para o sistema operacional reduz a I/O do disco. Normalmente, isso é tratado pelo sistema operacional e não precisa ser alterado. Em alguns casos em que o I/O de disco é um gargalo e o sistema está ficando sem vnodes, essa configuração precisa ser aumentada. A quantidade de RAM inativa e livre precisará ser levada em conta.

Para ver o número atual de vnodes em uso:

# sysctl vfs.numvnodes
vfs.numvnodes: 91349

Para ver o máximo de vnodes:

# sysctl kern.maxvnodes
kern.maxvnodes: 100000

Se o uso atual do vnode estiver próximo do máximo, tente aumentar o kern.maxvnodes por um valor de 1000. Fique de olho no número de vfs.numvnodes. Se subir até o máximo novamente, o kern.maxvnodes precisará ser aumentado ainda mais. Caso contrário, uma mudança no uso da memória como reportado pelo top(1) deve estar visível e mais memória deve estar ativa.



[2] O algoritmo de ajuste automático define o maxusers igual à quantidade de memória no sistema, com um mínimo de 32 e um máximo de 384.

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.