내 홈 디렉터리와 모든 하위 디렉터리를 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 시계 대기열의 길이
그런데 내가 뭔가를 놓친 게 아닐까?
아직 아키텍처에 대해 자세히 알아보지는 않았지만 감시되지 않는 inode/디렉터리/파일/경로의 작업에 영향을 미치는지 궁금합니다.
마찬가지로 에 대해서도 어떻게 다릅니까 fanotify?
답변1
나는 inotifywatch를 사용하지 않고 gidget을 사용하기 때문에 내 대답은 해당 도구에만 국한되지 않고 단지 inotify에 대한 유용한 관찰일 뿐입니다.무겁게사용).
각 inotify watch는 32비트 아키텍처에서 540바이트의 커널 메모리를 사용하고 64비트 아키텍처에서는 1080바이트를 사용합니다. 커널 메모리는 교체할 수 없습니다. 따라서 확실히 메모리 비용이 발생합니다.
그러나 내 경험상 속도를 늦추는 것은 감시 횟수가 아니라 커널이 신속하게 검사합니다. 실제 사용에서 시스템 성능에 영향을 미치는 경향이 있는 것은 inotify 이벤트가 트리거될 때 수행하는 작업입니다. 예를 들어, 기가비트 또는 10기가 링크를 통해 유선 속도로 도착하는 HIPAA 준수 835 파일이 10~4만 개 있는 경우 각 파일을 처리하기 위해 실행되는 사용자 프로세스는 inotify 자체보다 시스템을 훨씬 더 망치게 될 것입니다.
하지만 귀하의 질문 중 하나 이상에 대답하려면: 아니요, 감시 설정은 감시하지 않는 파일이나 폴더에 대한 효과/비용이 없습니다. 커널언제나감시 세트가 있는지 확인하고 감시 중인 다른 파일 시스템 개체 수에 관계없이 감시 세트가 없는 한 검사에는 동일한 시간과 리소스가 소요됩니다. 그러나 어떤 이유로든 지속적으로 엄청난 수의 프로세스를 생성하는 경우 전체 시스템 성능에 확실히 영향을 미칠 것입니다.
또한 사용 중인 도구가 폴더 및 하위 폴더를 반복적으로 감시할 수 있다고 언급하셨습니다. 이는 inotify가 수행하는 작업이 아니라 도구가 수행하는 작업입니다. 하위 폴더에 대해 대상으로 지정한 폴더를 검색하고 모든 폴더에 감시를 설정한 다음 새 폴더가 생성될 때마다 트리거하여 다른 감시를 설정합니다. 따라서 inotify 시스템과 간접적으로만 관련된 오버헤드 활동이 발생하고 이것이 성능에 미치는 영향은 대부분 inotify의 동작이 아닌 도구의 동작으로 인해 발생합니다. 도구가 엉성하고 리소스가 비효율적이라면(모르겠지만, inotify 도구는 일반적으로 C로 작성되기 때문에 의심스럽습니다) 이는 문제가 될 수 있습니다.