11.11. Ajustando os Limites do Kernel
Anterior | Capítulo 11. Configuração e Ajuste | Próxima

## 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`.

Anterior | Acima | Próxima
11.10. Otimização de Discos | Principal | 11.12. Adicionando Espaço de Swap

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>.