내 홈 디렉터리와 모든 하위 디렉터리를 60초 동안 반복적으로 감시하려면 다음을 수행하세요.
$ inotifywatch -v -r -t 60 /path
오류가 발생할 수 있으며 Failed to watch /path; upper limit on inotify watches reached!, 제한을 128k로 높여 해결할 수 있습니다.# echo $[ 128*1024 ] | tee /proc/sys/fs/inotify/max_user_watches
이것이 나를 궁금하게 만든다:
n개의 시계를 소유하는 데 드는 구체적인 비용은 얼마입니까 inotify?
나는 두 가지 질문을 하고 있습니다: 구체적이고 점근적인 복잡성 비용(아직 커널 스택의 어느 부분이 데이터 구조를 가지고 있는지, 그리고 어떻게 inotify 구현에 연결하는지 조사하지 않았습니다).
내 말은 컴퓨팅, 메모리 및 기타 비용입니다.
내 생각에 이것은 함수입니다(KiB로 구체적인 숫자 또는 CPU 로드 추정치(좋은 벤치마크가 있을 수 있음) 또는 심지어 점근적으로(예: "io당")) 다음과 같습니다.
- 감시할 파일/디렉터리
- 파일/디렉터리에서 수행되는 작업
- inotify는 대기열의 길이를 모니터링합니다.
하지만 제가 뭔가를 놓치고 있는 게 아닐까요?
아직 스키마를 조사하지 않았지만 모니터링되지 않는 노드/디렉터리/파일/경로의 작업에 영향을 미치는지 궁금합니다.
다시 말하지만, 어떤 차이가 있습니까 fanotify?
답변1
나는 inotifywatch를 사용하지 않고 gidget을 사용하므로 내 답변은 해당 도구에만 국한되지 않고 단지 inotify에 대한 유용한 관찰일 뿐입니다.무겁게사용).
각 inotify 모니터는 32비트 아키텍처에서 540바이트의 커널 메모리를 사용하고 64비트 아키텍처에서는 1080바이트를 사용합니다. 커널 메모리는 교체할 수 없습니다. 그래서 확실히 메모리 비용이 발생합니다.
하지만 내 경험상 속도를 늦추는 것은 감시 횟수가 아니라 커널이 신속하게 검사합니다. 실제 사용에서 시스템 성능에 영향을 미칠 가능성이 가장 높은 것은 inotify 이벤트가 트리거될 때 수행하는 작업입니다. 예를 들어, 기가비트 또는 10기가비트 링크를 통해 회선 속도로 도착하는 HIPAA 준수 835 파일이 10~4만 개 있는 경우 각 파일을 처리하기 위해 사용자 프로세스를 시작하는 것은 Inotify Impact 자체보다 시스템에 더 많은 부담을 줍니다.
하지만 귀하의 질문 중 하나 이상에 대답하자면 아니요, 모니터링 설정은 모니터링되지 않는 파일이나 폴더에 영향/비용을 미치지 않습니다. 핵심언제나모니터링 세트가 있는지 확인하는 데에는 모니터링 세트가 없는 한 모니터링되는 다른 파일 시스템 개체 수에 관계없이 동일한 시간과 리소스가 소요됩니다. 그러나 다시 한번 말씀드리지만, 이유가 무엇이든 계속해서 많은 프로세스를 생성한다면 이는 확실히 전체 시스템 성능에 영향을 미칠 것입니다.
또한 사용 중인 도구가 폴더와 하위 폴더를 반복적으로 모니터링할 수 있다고 언급하셨습니다. 이것은 inotify가 수행하는 작업이 아니라 도구가 수행하는 작업입니다. 지정한 하위 폴더에 대한 폴더를 검색하고 모든 폴더에 감시를 설정한 다음 새 감시가 생성될 때 다른 감시를 설정하도록 트리거할 수 있습니다. 따라서 inotify 시스템과 간접적으로만 관련된 일부 오버헤드 활동을 수행하게 되며 성능에 미치는 영향은 주로 inotify의 동작보다는 도구의 동작에 기인합니다. 도구가 엉성하고 리소스가 비효율적이라면 문제가 될 수 있습니다. (모르겠지만 inotify 도구는 일반적으로 C로 작성되기 때문에 의심스럽습니다.)