FreeBSD Handbook/Administração/Configuração e Ajuste/Ajustando Limites do Kernel

Origem: Wikilivros, livros abertos por um mundo aberto.
Saltar para a navegação Saltar para a pesquisa


11.13 Ajustando Limites do Kernel[editar | editar código-fonte]

11.13.1 Limites de Arquivos/Processos[editar | editar código-fonte]

11.13.1.1 kern.maxfiles[editar | editar código-fonte]

kern.maxfiles pode ser aumentado ou diminuído baseado nos requisitos do sistema. Esta variável indica o número máximo de descritores de arquivos em seu sistema. Quando a tabela de descritores de arquivos está cheia, "file: table is full" vai aparecer várias vezes no buffer de mensagem do sistema, que pode ser visto com o comando dmesg.

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

Em versões mais antigas do FreeBSD, o valor padrão de kern.maxfiles é derivada da opção maxusers em seu arquivo de configuração do kernel. kern.maxfiles cresce proporcionalmente ao valor de maxusers. Ao compilar um kernel personalizado, é uma boa idéia ajustar esta opção de configuração do kernel de acordo com os usos de seu sistema. A partir deste número, o kernel é dada a maioria de seus limites pré-definidos. Mesmo que uma máquina de produção não pode realmente ter 256 usuários conectados ao mesmo tempo, os recursos necessários podem ser semelhantes a um servidor web de alta escala.

A variável kern.maxusers é dimensionada automaticamente na inicialização com base na quantidade de memória disponível no sistema, e pode ser determinada em tempo de execução, inspecionando o valor somente-leitura kern.maxusers sysctl. Alguns locais exigem valores maiores ou menores de kern.maxusers e pode defini-lo como um carregador sintonizável; valores de 64, 128 e 256 não são incomuns. Nós não recomendamos ir acima de 256 a menos que você precisa de um grande número de descritores de arquivos, muitos dos valores ajustáveis para os padrões estabelecidos pelo kern.maxusers pode ser substituído individualmente na inicialização ou no tempo de execução em /boot/loader.conf ( ver a página de manual do loader.conf (5) ou o arquivo /boot/defaults/loader.conf para algumas dicas) ou conforme descrito em outras partes deste documento.

Em versões mais antigas, o sistema ajusta automaticamente para você, se você defini-lo explicitamente para 0 [1]. Ao definir esta opção, você vai querer definir maxusers para pelo menos, 4, especialmente se você estiver usando o sistema X Window System ou compilando programas. A razão é que a tabela mais importante ajustada por maxusers é o número máximo de processos, o que está definido para 20 + 16 * maxusers, por isso, se você definir maxusers como 1, então você pode ter apenas 36 processos simultâneos, incluindo os 18 ou assim que o sistema começa a funcionar em tempo de inicialização e os 15 ou assim que você provavelmente irá criar quando iniciar o sistema X Window System. Mesmo uma tarefa simples como ler uma página de manual irá iniciar nove processos para filtro, descomprimir, e visualizá-lo. Definindo maxusers como 64 lhe permitirá ter até 1044 processos simultâneos, o que deve ser suficiente para quase todas as utilizações. Se, todavia, você ver uma faixa de erro com término em tabela cheia proc (dreaded proc table full error) ao tentar iniciar outro programa, ou estiver executando um servidor com um grande número de usuários simultâneos (como ftp.FreeBSD.org), você pode sempre aumentar o número e reconstruir.

Nota: maxusers não limita o número de usuários que podem logar em sua máquina. Ele simplesmente define tamanhos de tabelas diferentes para valores razoáveis considerando o número máximo de usuários que você provavelmente terá em seu sistema e quantos processos cada um deles irá executar.

11.13.1.2 kern.ipc.somaxconn[editar | editar código-fonte]

A variável kern.ipc.somaxconn sysctl limita o tamanho da fila de escuta para aceitar novas conexões TCP. O valor padrão de 128 é tipicamente baixo para uma manipulação robusta de novas ligações em um ambiente carregando um servidor web. Para tais ambientes, recomenda-se aumentar este valor para 1024 ou maior. O serviço de daemon pode-se limitar o tamanho da fila de escuta (por exemplo, sendmail (8), ou Apache), mas que muitas vezes têm uma diretiva no seu arquivo de configuração para ajustar o tamanho da fila. Grandes filas de escutas também podem também fazer um trabalho melhor para evitar Ataques Denial of Service (DoS).