Quais são os custos de aumentar o valor '/ proc / sys / fs / inotify / max_user_watches'?

4

Para assistir meu diretório inicial e todos os subdiretórios recursivamente por 60 segundos:

$ inotifywatch -v -r -t 60 /path

Você pode receber o erro Failed to watch /path; upper limit on inotify watches reached! , que pode ser corrigido por limite crescente, por exemplo, para 128k: # echo $[ 128*1024 ] | tee /proc/sys/fs/inotify/max_user_watches

Isso me fez pensar:

Que custos exatos trazem n inotify relógios?

Eu pergunto em ambos: custos de complexidade concretos e asfíticos (eu não pesquisei ainda, quais as estruturas de dados em que partes da pilha do kernel e como são enganchadas como implementação do inotify).

Quero dizer: computacional, memória e outros custos.

Eu imagino que essas sejam funções (dando números concretos em KiB, ou estimativas de carga de CPU (talvez existam alguns bons benchmarks), ou mesmo assimptóticas (por exemplo, "cada io)) de:

  • arquivos / diretórios assistidos
  • operações em arquivos / diretórios executados
  • comprimentos de filas de relógios inotify

mas talvez eu tenha perdido alguma coisa?

Ainda não mergulhei na arquitetura, mas gostaria de saber se isso afeta as operações em inodes / directories / files / paths não assistidos?

Similarmente, como isso difere para fanotify ?

    
por Grzegorz Wierzowiecki 21.05.2017 / 11:17

0 respostas