성능 문제와 오류를 확인하는 웹사이트가 있는데, 수천 개의 파일을 디렉터리에 캐시하는 캐싱 코드를 발견했습니다.
나는 이것이 좋지 않다는 것을 알고 있으며 I/O 속도가 느려질 것이며 잠재적인 inode 문제에 대해 들었습니다.
캐시 코드를 수정하는 방법을 알고 있지만 문제는 현시점에서 수정 비용이 매우 많이 든다는 것입니다.
질문: 내가 이렇게 살면 어떤 최악의 상황이 일어날까? 웹사이트는 어떻게 되나요? (현재 이 단일 캐시 디렉터리에는 400,000개의 파일이 있습니다)
저는 우분투를 처음 사용합니다. 나는 이것이 주제에서 약간 벗어날 수 있다는 것을 알고 있습니다. 그러나 나는 이것이 "시스템" 문제이고 stackoverflow의 "프로그래밍" 섹션에 속하지 않는다고 생각합니다.
감사해요!
고쳐 쓰다:파일 시스템은 UFS입니다.
답변1
상황은 다소 놀랍습니다.초고속 파일 시스템프로덕션 Linux 설치를 위한 특이한 파일 시스템입니다. Linux에서의 UFS 쓰기 액세스는 일반적으로 커널에서 명시적으로 활성화되어야 합니다.실험적인 것으로 간주몇 년 동안:
CONFIG_UFS_FS_WRITE: UFS 파일 시스템 쓰기 지원 (위험함)
UFS 파티션에 쓰려면 여기에서 Y를 선택하세요. 이것은 실험적이므로 미리 UFS 파티션을 백업해야 합니다.
많은 기존 파일 시스템과 마찬가지로 UFS는 디렉터리에서 순차적 파일 조회를 사용합니다. 검색 시간은 파일 수에 따라 선형적으로 증가하므로 많은 파일이 포함된 디렉터리의 경우 성능 문제가 발생합니다. BSD에서 UFS는 일반적으로기본 파일 시스템, 이 문제는 직접적으로 발생합니다.디해쉬, 디렉토리의 해시 테이블 조회로 인해 성능이 크게 향상됩니다.
내가 아는 한, Linux에서의 UFS 지원은 Dirhash를 사용하지 않습니다. 따라서 디렉터리의 파일 수가 증가하면 성능 문제가 점점 더 많이 발생할 수 있습니다. 400K 파일은 순차 액세스 측면에서 많은 양을 차지하며 상당한 성능 저하를 예상할 수 있습니다.
하위 디렉터리 간에 파일을 분할하면 순차적 액세스 문제를 효과적으로 관리할 수 있습니다. 또는 더 복잡한 파일 저장 구조를 지원하는 파일 시스템으로 마이그레이션할 수 있습니다. 예를 들어,XFS구현하다대규모 디렉토리에 대한 빠른 파일 액세스사용하여B+트리.
두 번째 질문은 inode에 관한 것입니다. 일반적으로 파일 시스템의 inode 수는 고정되어 있으며 이는 일반적으로 파일 시스템이 생성될 때 사용 가능한 공간의 양에 따라 달라집니다. 예를 들어, /etc/mke2fs.confext 파일 시스템에 대한 기본 inode 비율(x바이트당 inode 수)을 저장합니다.
일반적으로 이 숫자는 생성할 파일 수보다 훨씬 크므로 걱정하지 마십시오. 그러나 다음을 df -i사용하여 inode 사용량을 확인할 수 있습니다. inode 제한이 실제로 문제가 될 수 있는 경우, 디렉토리를 조작하는 것은 도움이 되지 않습니다. 왜냐하면 inode는 디렉토리와는 별개로 파일 시스템 전체에 적용되는 개념이기 때문입니다. 이 경우 파일 시스템을 다시 생성하고 inode 매개변수를 적절하게 설정해야 합니다( -i) mkfs.
답변2
일반적인 UNIX(inode 기반) 파일 시스템(UFS 포함)에서는 생성하는 모든 파일이나 디렉터리가 inode를 사용한다고 말하는 것이 합리적인 근사치입니다. 디렉토리에 파일 수가 많다고 해서 이것이 바뀌지는 않습니다.
설명하는 접근 방식의 일반적인 문제는 다음과 같습니다.
- 파일 시스템은 검색 및 생성 속도를 높이기 위해 디렉터리 조회에 해시 또는 트리 데이터 구조를 사용합니다. 단일 디렉터리에 파일이 많을수록 속도가 느려집니다. 해시의 경우 충돌이 발생할 때 이러한 속도 저하가 매우 눈에 띄게 나타날 수 있습니다.
- 일반적인 Unix 명령(특히 정렬 및 쉘 글로브 확장)에는 문제가 있지만
ls일반적으로 파일 시스템 속도가 느려지기 오래 전에 문제가 발생합니다. - 디렉터리에 새 파일이 추가되고 더 많은 블록이 할당되면 점점 더 조각화되고 액세스하는 데 더 많은 디스크 IO가 필요합니다.
최신 파일 시스템(ext3/4)은 B 트리와 유사한 데이터 구조를 사용하여 디스크 데이터의 일부로 디렉터리 순서를 유지합니다. 나는 UFS 구현이 메모리 내 해시를 사용한다고 생각합니다(FreeBSD 사용 및 문서를 기반으로 하며 Linux에서 UFS에 대한 직접적인 경험이 많지 않습니다). 왜냐하면 온디스크 형식은 해시를 사용하지 않기 때문입니다.
다음은 좋은 UFS 정보와 링크입니다.https://serverfault.com/questions/53416/max-total-files-in-a-directory-in-freebsd-6-ufs
가장 가능성이 높은 최악의 시나리오는 어느 시점에서 이 디렉터리에 액세스할 때 심각하고 악화되는 속도 저하를 경험하게 되는 것입니다. 이 지점에 도달하면 수정하는 것이 지루해질 것입니다(sendmail 대기열이 폭발적으로 증가한 경험에 비추어 볼 때).
시스템을 모니터링하고 차트를 작성하는 것이 좋습니다.기다리다아직 모르신다면 시간을 내어 알아보세요 iotop.slabtop
가능하다면 캐시 디렉터리에 1000개의 파일이 생성되는 시간을 측정하고 이를 빈 디렉터리의 파일과 비교하여 몇 가지 간단한 실험을 시도해 보는 것도 좋습니다.