Para observar meu diretório inicial e todos os subdiretórios recursivamente por 60 segundos:
$ inotifywatch -v -r -t 60 /path
Você pode receber Failed to watch /path; upper limit on inotify watches reached!um erro, que pode ser corrigido aumentando o limite, por exemplo, para 128k:# echo $[ 128*1024 ] | tee /proc/sys/fs/inotify/max_user_watches
Isso me fez pensar:
Quais são os custos exatos de ter n inotifyrelógios?
Eu pergunto em ambos: custos de complexidades concretas e assintóticas (ainda não investiguei quais estruturas de dados em quais partes da pilha do kernel e como são conectadas como implementação do inotify).
Quero dizer: custos computacionais, de memória e outros.
Imagino que sejam funções (fornecendo números concretos em KiB ou estimativas de carga da CPU (talvez haja alguns bons benchmarks) ou mesmo assintóticas (por exemplo, "each io )) de:
- arquivos/diretórios monitorados
- operações em arquivos/diretórios realizadas
- comprimentos de filas de relógios inotify
mas talvez eu tenha perdido alguma coisa?
Ainda não me aprofundei na arquitetura, mas me pergunto se isso afeta as operações em inodes/diretórios/arquivos/caminhos não monitorados?
Da mesma forma, como isso difere para fanotify?
Responder1
Eu não uso o inotifywatch, eu uso o gidget, então minha resposta não é específica para essa ferramenta, é apenas uma observação útil sobre o inotify (que eufortementeusar).
Cada relógio inotify usa 540 bytes de memória do kernel em arquiteturas de 32 bits e 1080 bytes em arquiteturas de 64 bits. A memória do kernel não pode ser trocada. Portanto, certamente há um custo de memória.
Mas, na minha experiência, não é o número de relógios que retarda as coisas - o kernel as verifica rapidamente. O que tende a impactar o desempenho do sistema, em uso real, é o que você está fazendo quando os eventos inotify são acionados. Se você tiver (por exemplo) dez a quarenta mil arquivos 835 compatíveis com HIPAA chegando em velocidade de fio através de um link de gigabit ou dez gigabits, os processos do usuário que estão sendo acionados para lidar com cada um deles irão martelar o sistema com muito mais força do que o próprio inotify.
Porém, para responder a pelo menos uma de suas perguntas: Não, definir monitoramentos não terá nenhum efeito/custo para arquivos ou pastas não monitorados. O núcleosempreverifica se há um conjunto de observação, e a verificação levará a mesma quantidade de tempo e recursos, desde que não haja um, não importa quantos outros objetos do sistema de arquivos estejam sendo observados. Mas, novamente, se você estiver gerando constantemente um grande número de processos (por qualquer motivo), isso certamente terá um impacto no desempenho total do sistema.
Além disso, você mencionou que a ferramenta que está usando pode monitorar recursivamente pastas e subpastas. Isso não é algo que o inotify faz, é algo que sua ferramenta está fazendo. Provavelmente está verificando a pasta que você destinou em busca de subpastas, configurando monitoramentos em todas elas e, em seguida, acionando sempre que um novo for criado para configurar outro monitoramento. Então você tem alguma atividade de sobrecarga acontecendo lá que está apenas indiretamente relacionada ao sistema inotify, e o impacto que isso tem no desempenho será principalmente devido ao comportamento da ferramenta e não ao comportamento do inotify. Se a ferramenta for desleixada e ineficiente em termos de recursos (não sei, mas duvido, já que as ferramentas inotify geralmente são escritas em C), isso pode ser um problema.