Pode diminuir a velocidade de gravação de log no Linux (ext3)?

Question

Gostaria de saber se o tailf pode gerar E / S de bloqueio, o que diminuirá a capacidade de resposta do servidor devido ao registro em log.

Por ex. assumindo a seguinte configuração:

Debian linux server (foo) que é gerenciado via terminal (foo é hospedado no EC2).

O Foo executa vários aplicativos, cada um gravando em seu próprio arquivo de log. Por exemplo, o Apache httpd para /var/log/apache/access.log & Tomcat 5.5 para /var/log/tomcat5.5/myApp.log.

Se eu abrir uma conexão ssh com foo, (note: link de Internet, alta latência, upload relativamente lento) e executar tail -F /var/log/apache/access.log não consigo alcançar uma situação em que o kernel bloqueia as gravações do httpd nesse arquivo de log o desempenho do httpd por causa da espera imposta em cada thread?

Para dar alguns números, vamos assumir que foo registra ~ 200kb de dados de log por segundo que precisam ser enviados por push para o cliente ssh.

Outro aspecto teórico: O que aconteceria se o sistema de arquivos / var / log fosse definido em um tamanho infinito (lembre-se: Teoricamente falando) para que o tempo de busca do disco rígido fosse eliminado?

Terceiro aspecto, o que aconteceria se eu abrisse a conexão ssh a partir de um link muito lento (vamos supor que foo tem o formato de tráfego para enviar apenas 5kb / s)?

Adoraria ouvir o que você acha que é pessoal.

Obrigado pela leitura Maxim.

    

Answer 1

Eu não acho que haverá algum bloqueio sobre I / O aqui. Quando você faz "tail -f", o que está acontecendo é

1. seu processo de shell, digamos bash, gerará um novo processo 'tail'.
2. cauda abrirá o arquivo, moverá o ponteiro para o final, aguardará 3 segundos e verificará se há novos dados.
3. se houver novos dados, tail irá empurrá-lo de volta para o bash usando unix pipe.
4. esses dados são transmitidos do servidor para sua máquina pelo bash + ssh.

Como você pode ver, uma conexão lenta com a Internet não afetará a etapa 2, que é a chave para o desempenho de E / S de qualquer maneira.

Além disso, o tail abre o arquivo no modo 'somente leitura' e, um palpite bem informado, os logs são abertos no modo 'somente acréscimo', portanto não deve haver muito bloqueio aqui para se preocupar. Se isso ainda é um pouco de preocupação para você, então você pode querer experimentar o inotail que é baseado no mais recente linux inotify api para evitar sondando o arquivo.

Espero que isso ajude, Alex

    

Answer 2

Eu não acho que seja provável. Acredito que as escritas serão colocadas em cache no RAM e, uma vez que elas foram escritas, imagino que a cauda também esteja lendo essas páginas do RAM. As páginas serão periodicamente sincronizadas com o disco. Eu ficaria surpreso se o Apache bloqueasse esperando que os logs fossem gravados no disco.

    

Answer 3

A resposta correta é que o processo de leitura do log e o processo de gravação do log não estão relacionados de alguma forma. Eles são processos separados e não threads. Eles não compartilham memória e eles têm seus próprios identificadores de arquivo com seus próprios ponteiros de identificador de arquivo. Nenhum afeta o outro de forma alguma. O kernel não irá parar uma gravação em um arquivo porque algum outro programa o está lendo. Ele fará coisas para acelerar (gravar o cache na RAM quando o disco estiver ocupado, compartilhar o cache com todos os descritores de arquivo que usam esse arquivo, etc), mas não atrasá-lo!

A outra resposta sobre como funciona a cauda é a metade certa. Não usa um cano para falar com o bash. Bash é suspenso esperando na cauda para terminar (a menos que seja executado com &). Cauda herda o descritor de arquivo "stdout" (conectado ao seu terminal por padrão) do bash e grava diretamente nele. Seria ineficiente canalizá-lo de volta para o bash, fazer um comutador de tarefa para bash para ler os dados e ter o bash para gravar a saída. O Unix é projetado para ser simples e efetivo, stdin para stdout para quase tudo.

As versões atuais do GNU tail suportam totalmente a API inotify para evitar polling. Isso normalmente não vai fazer muita diferença para a cauda. É principalmente para que os gerenciadores de arquivos possam atualizar os diretórios e os servidores sabem quando reler um arquivo de configuração (sem reiniciar o servidor). Você também pode ter rotações de log de acompanhamento de cauda (normalmente ele mantém seu descritor de arquivo). Outro lado útil é o "tac", que irá reverter suas linhas de entrada. Isso permite que você tenha as informações mais recentes na parte superior ao processar um arquivo de log para exibição na web. Finalmente, o ccze irá colorir seus arquivos de log para facilitar a visualização (ANSI ou HTML).