Utilização de IO para redirecionamento / dev / null?

Question

Eu sempre uso nohup para iniciar meu sistema. No entanto, a saída para nohup é tão grande que estou pensando em redirecioná-lo para /dev/null . Minha preocupação é redirecionar para /dev/null também incorrer em algumas operações de E / S, como gravar em um arquivo normal?

Ou, devo descer para o nível de código e remover todas as informações de registro? (Mas eu posso precisar deles).

Minha única preocupação é a utilização e & I de E / S tamanho do arquivo.

    

Answer 1

Os dados gravados em /dev/null não vão a lugar algum. Como não é gravado em nenhum arquivo, não há tamanho de arquivo para causar impacto.

Se um programa gravar em /dev/null , a chamada do sistema ocorrerá. Mas a chamada do sistema retorna quase imediatamente sem gravar os dados em qualquer lugar. Portanto, há E / S do ponto de vista do aplicativo, mas não do ponto de vista do hardware.

Ninguém, a não ser você, pode saber se o pequeno custo de escrever para /dev/null é demais. Se você está preocupado, benchmark.

    

Answer 2

Isso parece um pouco como um problema XY . O que você realmente deveria estar fazendo é adicionar a capacidade de controlar seu nível de registro a partir de um arquivo de configuração ou da linha de comando usando números crescentes de -v , ala. -vvv como muitas ferramentas de linha de comando.

Depois, você ainda pode invocar seu servidor usando nohup e adicionar / remover a alteração de -vv.. e adicioná-lo somente quando necessário.

Além disso, veja como usar um recurso de registro real, como log4j , log4perl , log4X onde X é qualquer que seja seu idioma. Então você pode controlar o nível de log a partir de um arquivo log4X .conf e também especificar coisas como rotação de log, etc.

Obviamente, você pode redirecionar o log como está para /dev/null , mas essas são outras opções que você também deve considerar como desenvolvedor.

    

Answer 3

Gravar para / dev / null incorre em um custo diferente de zero, mas se afetar o desempenho do sistema, o autor do software fez algo muito errado. Chamar sys_write () é altamente otimizado. Escrever os dados que você envia para ele percorre várias bibliotecas e sistemas de kernel até atingir o driver nulo. Esse caminho é altamente eficiente.

Sim, um programa provavelmente deve ter um sinalizador que desabilita a saída, mas se isso não ocorrer e gravar em / dev / null for um problema de desempenho, você terá um sistema estranho.

Lembre-se de que "a otimização prematura é a raiz de todo o mal". Editar o código para corrigir isso é um desperdício de tempo, a menos que você possa primeiro escrever um benchmark que mostre que esse é realmente o maior gargalo de desempenho.

Nota histórica:

As versões originais do Linux tiveram um muito lento / dev / null. Ele fez muito processamento apenas para descartar os dados no final. Havia um benchmark embaraçoso (não consigo encontrar um link, desculpe!), Mostrando que o / dev / null do Linux era muito mais lento que o FreeBSD e o Solaris (os populares sistemas similares ao Unix naquela época). O próximo lançamento do Linux teve um muito mais rápido / dev / null. Da mesma forma, o NIC de loopback no Linux costumava ser muito lento porque processava completamente o pacote, verificando erros de CRC (que possivelmente não poderiam estar errados) e fazendo outros trabalhos desnecessários. Alguns benchmarks embaraçosamente ruins foram publicados e logo as coisas foram corrigidas.