Capítulo 11. Configuração e Ajuste

Infelizmente, ainda existem muitos fornecedores que não fornecem esquemas para seus drivers para a comunidade de código aberto porque consideram essas informações como segredos comerciais. Consequentemente, os desenvolvedores do FreeBSD e de outros sistemas operacionais são deixados com duas opções: desenvolver os drivers por um processo longo e complexo de engenharia reversa ou usar os binários de drivers existentes disponíveis para plataforma Microsoft™ Windows™.

O FreeBSD fornece suporte "nativo" para a especificação de interface de driver de rede (NDIS). Ele inclui o ndisgen(8) que pode ser utilizado para converter um driver Windows™ XP num formato que pode ser usado no FreeBSD. Como o driver ndis(4) usa um binário Windows™ XP, ele só é executado em sistemas i386™ e amd64. Dispositivos PCI, CardBus, PCMCIA e USB são suportados.

Para usar o ndisgen(8) , três coisas são necessárias:

Faça o download dos arquivos .SYS e .INF para a NIC específica. Geralmente, eles podem ser encontrados no CD do driver ou no site do fornecedor. Os exemplos a seguir usam o W32DRIVER.SYS e o W32DRIVER.INF .

A largura do bit do driver deve corresponder à versão do FreeBSD. Para FreeBSD/i386, use um driver de 32 bits Windows™. Para o FreeBSD/amd64, é necessário um driver de 64 bits do Windows™.

O próximo passo é compilar o binário do driver em um módulo do kernel carregável. Como root , use ndisgen(8) :

Este comando é interativo e solicita qualquer informação extra necessária. Um novo módulo do kernel será gerado no diretório atual. Use kldload(8) para carregar o novo módulo:

Além do módulo do kernel gerado, os módulos ndis.ko e if_ndis.ko devem ser carregados. Isso deve acontecer automaticamente quando qualquer módulo que dependa do ndis(4) for carregado. Caso contrário, carregue-os manualmente, usando os seguintes comandos:

O primeiro comando carrega o wrapper do driver da miniporta ndis(4) e o segundo carrega o driver NIC gerado.

Execute o comando dmesg(8) para ver se houve algum erro de carregamento. Se tudo correu bem, a saída deve ser semelhante à seguinte:

A partir daqui, o ndis0 pode ser configurado como qualquer outra NIC.

Para configurar o sistema para carregar os módulos ndis(4) no momento da inicialização, copie o módulo gerado, W32DRIVER_SYS.ko , para /boot/modules . Em seguida, adicione a seguinte linha ao /boot/loader.conf :

Para verificar se uma placa Ethernet está configurada corretamente, execute um ping(8) na própria interface e, em seguida, ping(8) outra máquina na LAN:

Para testar a resolução da rede, use o nome do host em vez do endereço IP. Se não houver nenhum servidor DNS na rede, o /etc/hosts deve ser configurado primeiro. Para este propósito, edite o /etc/hosts para adicionar os nomes e os endereços IP dos hosts na LAN, se eles ainda não estiverem lá . Para maiores informações, consulte hosts(5) e /usr/shared/examples/etc/hosts .

Ao solucionar problemas de configurações de hardware e software, verifique primeiro as coisas simples. O cabo de rede está conectado? Os serviços de rede estão configurados corretamente? O firewall está configurado corretamente? A NIC é suportada pelo FreeBSD? Antes de enviar um relatório de bug, sempre verifique as Notas de Hardware, atualize a versão do FreeBSD para a versão mais recente do STABLE, verifique os arquivos da lista de discussão e pesquise na Internet.

Se a placa funcionar, mas o desempenho for ruim, leia tuning(7) . Além disso, verifique a configuração da rede, pois configurações de rede incorretas podem causar conexões lentas.

Alguns usuários experimentam uma ou duas mensagens de device timeout , o que é normal para algumas placas. Se eles continuarem ou forem incômodos, verifique se o dispositivo está em conflito com outro. Verifique novamente as conexões dos cabos. Considere tentar outra placa.

Para resolver erros de watchdog timeout , primeiro verifique o cabo de rede. Muitas placas requerem um slot PCI que suporte a masterização de barramento. Em algumas placas-mãe antigas, apenas um slot PCI permite, normalmente o slot 0. Verifique a NIC e a documentação da placa-mãe para determinar se esse pode ser o problema.

As mensagens No route to host ocorrem se o sistema não puder rotear um pacote para o host de destino. Isso pode acontecer se nenhuma rota padrão for especificada ou se um cabo for desconectado. Verifique a saída do netstat -rn e certifique-se de que haja uma rota válida para o host. Se não houver, leia Gateways e Rotas .

As mensagens de erro ping: sendto: Permission denied são geralmente causadas por um firewall mal configurado. Se um firewall está habilitado no FreeBSD, mas nenhuma regra foi definida, a política padrão é negar todo o tráfego, mesmo o ping(8) . Consulte Firewalls para maiores informações.

Às vezes, o desempenho da placa é ruim ou abaixo da média. Nesses casos, tente configurar o modo de seleção de mídia de autoselect para a seleção de mídia correta. Embora isso funcione para a maioria dos hardwares, isso pode ou não resolver o problema. Novamente, verifique todas as configurações de rede e consulte tuning(7) .

Um servidor de log é um sistema que foi configurado para aceitar informações de log de outros hosts. Antes de configurar um servidor de log, verifique o seguinte:

No servidor de log, edite o /etc/syslog.conf para especificar o nome do cliente para receber as entradas de log, o recurso de log a ser usado e o nome do log para armazenar as entradas de log do host. Este exemplo adiciona o nome do host de B , registra todos os recursos e armazena as entradas de log em /var/log/logclient.log .

Ao adicionar vários clientes de log, adicione uma entrada semelhante de duas linhas para cada cliente. Maiores informações sobre os recursos disponíveis podem ser encontradas em syslog.conf(5) .

Em seguida, configure o /etc/rc.conf :

A primeira entrada inicia o syslogd na inicialização do sistema. A segunda entrada permite entradas de log do cliente especificado. A opção -v -v aumenta a verbosidade das mensagens registradas. Isso é útil para ajustar os recursos, pois os administradores podem ver o tipo de mensagens que estão sendo registradas em cada facility.

Múltiplas opções -a podem ser especificadas para permitir o registro de múltiplos clientes. Endereços IP e netblocks inteiros também podem ser especificados. Consulte syslogd(8) para obter uma lista completa de opções possíveis.

Finalmente, crie o arquivo de log:

Neste ponto, o syslogd deve ser reiniciado e verificado:

Se um PID for retornado, o servidor será reiniciado com êxito e a configuração do cliente poderá ser iniciada. Se o servidor não reiniciar, consulte /var/log/messages para visualizar o erro.

Um cliente de log envia entradas de log para um servidor de log na rede. O cliente também mantém uma cópia local de seus próprios logs.

Uma vez que o servidor de log foi configurado, edite o /etc/rc.conf no cliente de registro:

A primeira entrada ativa o syslogd na inicialização. A segunda entrada impede que os logs sejam aceitos por esse cliente de outros hosts ( -s ) e aumenta a verbosidade das mensagens registradas.

Em seguida, defina o servidor de log no /etc/syslog.conf do cliente. Neste exemplo, todos os facilities registrados são enviados para um sistema remoto, indicado pelo símbolo @ , com o nome do host especificado:

Depois de salvar a edição, reinicie o syslogd para que as alterações entrem em vigor:

Para testar se as mensagens de log estão sendo enviadas pela rede, use o logger(1) no cliente para enviar uma mensagem para syslogd:

Esta mensagem agora deve existir tanto no /var/log/messages do cliente e no /var/log/logclient.log do servidor de log.

Se nenhuma mensagem estiver sendo recebida no servidor de log, a causa provavelmente é um problema de conectividade de rede, um problema de resolução de nome de host ou um erro de digitação em um arquivo de configuração. Para isolar a causa, certifique-se de que o servidor de log e o cliente de log sejam capazes de comunicarem através do ping usando o nome do host especificado em seu /etc/rc.conf . Se isso falhar, verifique o cabeamento da rede, o conjunto de regras do firewall e as entradas de nome de host no servidor DNS ou /etc/hosts no servidor de log e nos clientes. Repita até que o ping seja bem-sucedido em ambos os hosts.

Se o ping for bem-sucedido em ambos os hosts, mas as mensagens de log ainda não estiverem sendo recebidas, aumente temporariamente o detalhamento do log para diminuir o problema de configuração. No exemplo a seguir, o /var/log/logclient.log no servidor de log está vazio e o /var/log/messages no cliente de log não indica uma razão para a falha. Para aumentar a saída de debug, edite a entrada syslogd_flags no servidor de log e execute uma reinicialização:

Dados de debug semelhantes aos seguintes irão aparecer no console imediatamente após a reinicialização:

Neste exemplo, as mensagens de log estão sendo rejeitadas devido a um erro de digitação que resulta em uma incompatibilidade de nome de host. O nome do host do cliente deve ser logclient , não logclien . Corrija o erro de digitação, execute uma reinicialização e verifique os resultados:

Neste ponto, as mensagens estão sendo recebidas e colocadas corretamente no arquivo correto.

Como com qualquer serviço de rede, os requisitos de segurança devem ser considerados antes de implementar um servidor de log. Os arquivos de log podem conter dados confidenciais sobre serviços ativados no host local, contas de usuário e dados de configuração. Os dados enviados pela rede do cliente para o servidor não serão criptografados nem protegidos por senha. Se houver necessidade de criptografia, considere o uso do security/stunnel , que transmitirá os dados de log em um túnel criptografado.

A segurança local também é um problema. Os arquivos de log não são criptografados durante o uso ou após a rotação do log. Usuários locais podem acessar arquivos de log para obter informações adicionais sobre a configuração do sistema. Definir permissões adequadas nos arquivos de log é crítico. O rotacionador de log integrado, newsyslog, suporta a configuração de permissões em arquivos de log recém-criados e rotacionados. A configuração de arquivos de log no modo 600 deve impedir o acesso indesejado por usuários locais. Consulte newsyslog.conf(5) para obter informações adicionais.

Como um sistema FreeBSD acessa o Sistema de Nomes de Domínio da Internet (Internet Domain Name System - DNS) é controlado por resolv.conf(5) .

As entradas mais comuns para o /etc/resolv.conf são:

Um típico /etc/resolv.conf é assim:

Ao usar o DHCP, o dhclient(8) geralmente reescreve o /etc/resolv.conf com informações recebidas do servidor DHCP.

O /etc/hosts é um banco de dados de texto simples que funciona em conjunto com o DNS e o NIS para fornecer o nome do host aos mapeamentos de endereços IP. Entradas para computadores locais conectados através de uma LAN podem ser adicionadas a este arquivo para propósitos simplistas de nomeação em vez de configurar um servidor named(8) . Além disso, o /etc/hosts pode ser usado para fornecer um registro local de nomes da Internet, reduzindo a necessidade de consultar servidores DNS externos para nomes comumente acessados.

O formato do /etc/hosts é o seguinte:

Por exemplo:

Consulte hosts(5) para obter maiores informações.

A variável vfs.vmiodirenable sysctl(8) pode ser definida como 0 (off ) ou 1 (on). Está definida para 1 por padrão. Esta variável controla como os diretórios são armazenados em cache pelo sistema. A maioria dos diretórios é pequena, usando apenas um único fragmento (normalmente 1K) no sistema de arquivos e, normalmente, 512 bytes no cache de buffer. Com esta variável desativada, o cache de buffer armazenará apenas um número fixo de diretórios, mesmo que o sistema tenha uma quantidade enorme de memória. Quando ativado, este sysctl(8) permite que o cache de buffer use o cache de página VM para armazenar em cache os diretórios, disponibilizando toda a memória para fazer cache dos diretórios. No entanto, a memória mínima no núcleo usada para armazenar em cache um diretório é o tamanho da página física (geralmente 4K) em vez de 512 bytes. Manter esta opção ativada é recomendado se o sistema estiver executando quaisquer serviços que manipulem um grande número de arquivos. Esses serviços podem incluir caches da web, grandes sistemas de correio e sistemas de notícias. Manter essa opção geralmente não reduz o desempenho, mesmo com a memória desperdiçada, mas deve-se experimentar para descobrir.

A variável vfs.write_behind sysctl(8) é padronizada para 1 (ligada). Isso informa ao sistema de arquivos para emitir gravações de mídia à medida que clusters completos são coletados, o que normalmente ocorre ao gravar arquivos sequenciais grandes. Isso evita saturar o cache de buffer com buffers sujos quando não beneficia o desempenho de I/O. No entanto, isso pode atrasar os processos e, sob certas circunstâncias, deve ser desativado.

A variável vfs.hirunningspace sysctl(8) determina quanto de I/O de gravação pendente pode ser enfileirado no sistema de controladores de disco como um todo em qualquer instância. O padrão é geralmente suficiente, mas em máquinas com muitos discos, tente aumentar para quatro ou cinco megabytes . Definir um valor muito alto, que exceda o limite de gravação do cache de buffer, pode levar a um mau desempenho de cluster. Não defina esse valor arbitrariamente alto, pois valores de gravação mais altos podem adicionar latência a leituras que ocorrem ao mesmo tempo.

Há vários outros caches de buffer e valores de cache de página VM relacionados a sysctl(8) . Modificar esses valores não é recomendado, pois o sistema VM faz um bom trabalho de ajuste automático.

A variável vm.swap_idle_enabled sysctl(8) é útil em grandes sistemas multiusuários com muitos usuários ativos, e muitos processos ociosos. Tais sistemas tendem a gerar pressão contínua nas reservas de memória livre. Ativar esse recurso e aprimorar a histerese de troca (em segundos ociosos) por meio de vm.swap_idle_threshold1 e vm.swap_idle_threshold2 reduz a prioridade das páginas de memória associadas aos processos inativos mais rapidamente do que no algoritmo de pageout normal. Isso dá uma ajuda ao daemon de pageout. Apenas ative essa opção se necessário, porque a compensação é essencialmente fazer o pre-page da memoria mais cedo, o que consome mais swap e largura de banda de disco. Em um sistema pequeno, esta opção terá um efeito determinável, mas em um sistema grande que já está paginando moderadamente, esta opção permite que o sistema VM instale processos inteiros dentro e fora da memória facilmente.

Desativar o cache de gravação IDE reduz a largura de banda de gravação em discos IDE, mas às vezes pode ser necessário devido a problemas de consistência de dados introduzidos por fornecedores de disco rígido. O problema é que algumas unidades IDE mentem sobre quando uma gravação é concluída. Com o cache de gravação IDE ativado, os discos rígidos IDE gravam os dados fora de ordem e às vezes atrasam a gravação de alguns blocos indefinidamente quando estão sob carga pesada de disco. Uma falha ou falha de energia pode causar corrupção séria do sistema de arquivos. Verifique o padrão no sistema observando a variável hw.ata.wc sysctl(8) . Se o cache de gravação IDE estiver desativado, pode-se definir essa variável somente leitura como 1 em /boot/loader.conf para ativar no momento da inicialização.

Para maiores informações, consulte ata(4) .

A opção de configuração do kernel SCSI_DELAY pode ser usada para reduzir os tempos de inicialização do sistema. Os padrões são razoavelmente altos e podem ser responsáveis por 15 segundos de atraso no processo de inicialização. Reduzindo-o para 5 segundos geralmente funciona com unidades modernas. A variável de tempo de inicialização kern.cam.scsi_delay deve ser usada. A opção de configuração ajustável e a configuração do kernel aceitam valores em termos de milissegundos e não__segundos .

As atualizações de metadados são atualizações para dados que não são de conteúdo, como inodes ou diretórios. Existem duas abordagens tradicionais para gravar os metadados de um sistema de arquivos em disco.

Historicamente, o comportamento padrão era gravar atualizações de metadados de forma síncrona. Se um diretório fosse alterado, o sistema aguardava até que a alteração fosse gravada no disco. Os buffers de dados do arquivo (conteúdo do arquivo) foram passados pelo cache de buffer e foram copiados para o disco posteriormente de maneira assíncrona. A vantagem dessa implementação é que ela opera com segurança. Se houver uma falha durante uma atualização, os metadados estarão sempre em um estado consistente. Um arquivo é criado completamente ou não é de todo. Se os blocos de dados de um arquivo não encontrarem saída do cache de buffer para o disco no momento da falha, o fsck(8) reconhece isso e repara o sistema de arquivos definindo o comprimento do arquivo como 0 . Além disso, a implementação é clara e simples. A desvantagem é que as alterações nos metadados são lentas. Por exemplo, rm -r toca todos os arquivos em um diretório sequencialmente, mas cada alteração de diretório será gravada de forma síncrona no disco. Isso inclui atualizações para o próprio diretório, para a tabela de inode e possivelmente para blocos indiretos alocados pelo arquivo. Considerações semelhantes aplicam-se ao desenrolar hierarquias grandes usando tar -x .

A segunda abordagem é usar atualizações de metadados assíncronas. Este é o padrão para um sistema de arquivos UFS montado com mount -o async . Como todas as atualizações de metadados também são passadas pelo cache de buffer, elas serão mescladas com as atualizações dos dados de conteúdo do arquivo. A vantagem dessa implementação é que não há necessidade de esperar até que cada atualização de metadados seja gravada no disco, portanto, todas as operações que causam grandes quantidades de atualizações de metadados funcionam muito mais rápido do que no caso síncrono. Essa implementação ainda é clara e simples, portanto, há um baixo risco de erros se infiltrarem no código. A desvantagem é que não há garantia para um estado consistente do sistema de arquivos. Se houver uma falha durante uma operação que atualizou grandes quantidades de metadados, como uma falha de energia ou alguém pressionando o botão de reinicialização, o sistema de arquivos será deixado em um estado imprevisível. Não há oportunidade de examinar o estado do sistema de arquivos quando o sistema é reativado, pois os blocos de dados de um arquivo já podem ter sido gravados no disco enquanto as atualizações da tabela de inodes ou do diretório associado não foram. É impossível implementar um fsck(8) que é capaz de limpar o caos resultante porque as informações necessárias não estão disponíveis no disco. Se o sistema de arquivos foi danificado além do reparo, a única opção é reformatá-lo e restaurá-lo a partir do backup.

A solução usual para este problema é implementar dirty region logging , que também é chamado de journaling . As atualizações de metadados ainda são gravadas de forma síncrona, mas apenas em uma pequena região do disco. Mais tarde, eles são movidos para o local apropriado. Como a área de registro é uma região pequena e contígua no disco, não há longas distâncias para as cabeças de disco se moverem, mesmo durante operações pesadas, portanto, essas operações são mais rápidas do que as atualizações síncronas. Além disso, a complexidade da implementação é limitada, portanto, o risco de erros estarem presentes é baixo. Uma desvantagem é que todos os meta-dados são gravados duas vezes, uma vez na região de registro e uma vez no local apropriado, portanto, pode resultar em "piora" na performance. Por outro lado, em caso de falha, todas as operações de metadados pendentes podem ser rapidamente recuperadas ou concluídas a partir da área de registro depois que o sistema for ativado novamente, resultando em uma inicialização rápida do sistema de arquivos.

Kirk McKusick, o desenvolvedor do Berkeley FFS, resolveu esse problema com o Soft Updates. Todas as atualizações de meta-dados pendentes são mantidas na memória e gravadas no disco em uma sequência ordenada ("atualizações de metadados ordenadas"). Isso tem o efeito de que, no caso de operações pesadas de meta-dados, atualizações posteriores em um item "catch" as anteriores que ainda estão na memória e ainda não foram gravadas no disco. Todas as operações são geralmente executadas na memória antes da atualização ser gravada no disco e os blocos de dados são classificados de acordo com sua posição, de modo que não estarão no disco antes de seus meta-dados. Se o sistema travar, um "reenvio de log" implícito faz com que todas as operações que não foram gravadas no disco apareçam como se nunca tivessem acontecido. Um estado consistente do sistema de arquivos é mantido e parece ser o de 30 a 60 segundos antes. O algoritmo usado garante que todos os recursos em uso sejam marcados como tal em seus blocos e inodes. Após uma falha, o único erro de alocação de recursos que ocorre é que os recursos são marcados como "used", que são, na verdade, "free". O fsck(8) reconhece essa situação e libera os recursos que não são mais usados. É seguro ignorar o estado sujo do sistema de arquivos após uma falha forçando a montagem com mount -f . Para liberar recursos que podem não ser utilizados, O fsck(8) precisa ser executado posteriormente. Esta é a idéia por trás do fsck(8) em background : no momento da inicialização do sistema, apenas um snapshot do sistema de arquivos é gravado e o fsck(8) é executado posteriormente. Todos os sistemas de arquivos podem ser montados "sujos", para que a inicialização do sistema prossiga no modo multiusuário. Em seguida, o fsck(8) em background é planejado para todos os sistemas de arquivos em que isso é necessário, para liberar recursos que podem não ser utilizados. Os sistemas de arquivos que não usam Soft Updates ainda precisam executar o fsck(8) em primeiro plano de forma usual .

A vantagem é que as operações de meta-dados são quase tão rápidas quanto as atualizações assíncronas e são mais rápidas que o logging , que precisa escrever os meta-dados duas vezes. As desvantagens são a complexidade do código, um maior consumo de memória e algumas idiosincrasias. Depois de uma falha, o estado do sistema de arquivos parece ser um pouco mais "velho". Em situações onde a abordagem síncrona padrão teria causado a existencia de alguns arquivos de comprimento zero após o fsck(8) , esses arquivos sequer chegam a existir com Soft Updates porque nem os metadados e nem o conteúdo do arquivo foram gravados no disco. O espaço em disco não é liberado até que as atualizações tenham sido gravadas no disco, o que pode ocorrer algum tempo depois de executar rm(1) . Isso pode causar problemas ao instalar grandes quantidades de dados em um sistema de arquivos que não tenha espaço livre suficiente para armazenar todos os arquivos duas vezes.

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

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

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.

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.

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:

Para ver o máximo de vnodes:

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.

Em alguns casos, retomar a partir de uma operação de suspensão fará com que o mouse falhe. Um work around conhecido é adicionar hint.psm.0.flags="0x3000" ao /boot/loader.conf .

O ACPI tem três estados de suspensão para RAM (STR), S1 - S3 , e um de suspensão de estado para disco (STD), chamado S4 . O STD pode ser implementado de duas maneiras separadas. O S4 BIOS é uma suspensão para disco auxiliada pelo BIOSe o S4 OS é implementado inteiramente pelo sistema operacional. O estado normal em que o sistema se encontra quando conectado, mas não ligado, é "soft off" ( S5 ).

Use o sysctl hw.acpi para verificar os itens relacionados à suspensão. Estes resultados de exemplo são de um Thinkpad:

Use o acpiconf -s para testar os estados S3 , S4 e S5 . Um s4bios de um ( 1 ) indica suporte ao S4 BIOS em vez do S4 suportado pelo sistema operacional.

Ao testar as ações de suspend/resume, inicie com o S1 , se suportado. É mais provável que esse estado funcione, pois não requer muito suporte ao driver. Ninguém implementou S2 , que é similar ao S1 . Em seguida, tente o S3 . Este é o estado mais profundo do STR e requer muito suporte ao driver para reinicializar corretamente o hardware.

Um problema comum com suspend/resume é que muitos drivers de dispositivo não salvam, restauram ou reinicializam seu firmware, registros ou memória do dispositivo adequadamente. Como primeira tentativa de depuração do problema, tente:

Esse teste emula o ciclo de suspend/resume de todos os drivers de dispositivo sem entrar realmente no estado S3 . Em alguns casos, problemas como perder o estado do firmware, tempo limite do watchdog do dispositivo e tentar novamente para sempre podem ser capturados com esse método. Note que o sistema não entrará realmente no estado S3 , o que significa que os dispositivos não perderão energia, e muitos funcionarão bem mesmo se os métodos suspend/resume estiverem totalmente ausentes, ao contrário do real estado S3 .

Casos mais difíceis requerem hardware adicional, como uma porta serial e um cabo para depuração através de um console serial, uma porta Firewire e um cabo para o uso do dcons(4) e habilidades de depuração do kernel.

Para ajudar a isolar o problema, descarregue o maior número possível de drivers. Se funcionar, diminua o driver que é o problema carregando os drivers até que ele falhe novamente. Normalmente, drivers binários como nvidia.ko , drivers de exibição e USB terão mais problemas, enquanto as interfaces Ethernet normalmente funcionam bem. Se os drivers puderem ser carregados e descarregados adequadamente, automatize isso colocando os comandos apropriados em /etc/rc.suspend e /etc/rc.resume . Tente configurar o hw.acpi.reset_video para 1 se a tela estiver desarrumada após a retomada. Tente definir valores mais longos ou mais curtos para hw.acpi.sleep_delay para ver se isso ajuda.

Tente carregar uma distribuição recente do Linux™ para ver se o suspend/resume funciona no mesmo hardware. Se funciona no Linux™, é provável que seja um problema no driver do FreeBSD. Descobrir qual driver causa o problema ajudará os desenvolvedores a corrigir o problema. Como os mantenedores do ACPI raramente mantêm outros drivers, como som ou ATA, qualquer problema de driver também deve ser postado na lista freebsd-current e enviada para o mantenedor do driver. Os usuários avançados podem incluir os printf(3) s de debug do driver problemático para rastrear onde, em sua função de reinício, ele é interrompido.

Por fim, tente desativar o ACPI e ativar o APM. Se o comando suspend/resume funcionar com APM, use o APM, especialmente em hardware mais antigo (anterior a 2000). Demorou algum tempo para que os fornecedores obtivessem suporte ACPI correto e os hardwares antigos são mais prováveis de terem problemas de BIOS com ACPI.

A maioria dos travamentos do sistema é resultado de interrupções perdidas ou de uma tempestade de interrupções. Chipsets podem ter problemas com base na inicialização, como o BIOS configura as interrupções antes da correção da tabela APIC (MADT) e o roteamento do sistema de controle de interrupções (SCI).

Tempestades de interrupção podem ser distinguidas de interrupções perdidas, verificando a saída do vmstat -i e observando a linha que possui acpi0 . Se o contador está aumentando em mais de um par por segundo, há uma tempestade de interrupção. Se o sistema parece travado, tente acessar o DDB ( CTRL + ALT + ESC no console) e digite show interrupts .

Ao lidar com problemas de interrupção, tente desativar o suporte ao APIC com hint.apic.0.disabled="1" no /boot/loader.conf .

Os panics são relativamente raros para ACPI e são a prioridade máxima a ser corrigida. O primeiro passo é isolar as etapas para reproduzir o panic, se possível, e obter um backtrace. Siga as instruções para habilitar options DDB e configurar um console serial em Entrando no Depurador DDB da Linha Serial ou configurar uma partição de despejo. Para obter um backtrace no DDB, use tr . Ao escrever o backtrace, obtenha pelo menos as cinco últimas e as cinco principais linhas do rastro.

Em seguida, tente isolar o problema inicializando com ACPI desabilitado. Se isso funcionar, isole o subsistema ACPI usando vários valores de debug.acpi.disable . Veja acpi(4) para alguns exemplos.

Primeiro, tente definir hw.acpi.disable_on_poweroff="0" no /boot/loader.conf . Isso impede que a ACPI desative vários eventos durante o processo de desligamento. Alguns sistemas precisam desse valor definido como 1 (o padrão) pelo mesmo motivo. Isso geralmente corrige o problema de um sistema ser ativado espontaneamente após uma suspensão ou desligamento.

Alguns fornecedores de BIOS fornecem bytecode incorreto ou com bugs. Isso geralmente é manifestado por mensagens do console do kernel como esta:

Geralmente, esses problemas podem ser resolvidos com a atualização do BIOS para a revisão mais recente. A maioria das mensagens do console é inofensiva, mas se houver outros problemas, como o status da bateria não estar funcionando, essas mensagens são um bom lugar para começar a procurar por problemas.