하위 디렉토리의 수는 Linux에서 드라이브 읽기 / 쓰기 성능에 어떤 영향을 줍니까?

Linux CentOS 서버에 EXT3 형식의 드라이브가 있습니다. 이것은 웹앱 데이터 드라이브이며 모든 사용자 계정에 대한 디렉토리를 포함합니다 (사용자 25,000 명). 각 폴더에는 해당 사용자가 업로드 한 파일이 포함되어 있습니다. 전체적으로이 드라이브에는 약 250GB의 데이터가 있습니다.

이러한 모든 디렉토리로 드라이브를 구성하면 드라이브 읽기 / 쓰기 성능에 영향을 줍니까? 내가 모르는 다른 성능 측면에 영향을 줍니까?

이런 식으로 구조를 구성하는 데 본질적으로 잘못되었거나 나쁜 것이 있습니까? 아마도 파일 시스템의 잘못된 선택일까요?

최근에 두 개의 데이터 드라이브를 병합하려고 시도했으며 EXT3이 32,000 개의 하위 디렉토리로 제한되어 있음을 깨달았습니다. 이것은 왜 내가 궁금해했다. 각 파일에 데이터베이스의 ID에 해당하는 고유 ID가 있다는 점을 고려 하여이 방법으로 빌드 한 것은 어리석은 것처럼 보입니다. 아아 ...

이를 통해 사용자 환경에서 직접 옵션을 테스트 하고 결과를 비교할 수 있습니다. 예. 디렉토리 수가 증가함에 따라 성능에 부정적인 영향을 미칩니다. 예, 다른 파일 시스템은 이러한 장벽을 극복하거나 영향을 줄일 수 있습니다.

XFS 파일 시스템은 더 나은 디렉토리 구조의 유형입니다. ext4는 아마도 오늘날에는 괜찮을 것입니다. 하위 디렉토리 및 파일 수가 증가함에 따라 디렉토리에 대한 액세스 및 조작이 느려집니다. 이것은 ext3에서 매우 두드러지며 XFS에서는 그다지 중요하지 않습니다.

대답은 파일 시스템을 선택하는 것만 큼 간단하지 않습니다. Sane 파일 시스템은 오래 전에 디렉토리에 선형 목록 사용을 중지했습니다. 즉, 디렉토리의 항목 수가 파일 액세스 시간에 영향을 미치지 않습니다.

때를 제외하고.

실제로 각 작업은 항목 수에 관계없이 빠르고 효율적으로 유지되지만 일부 작업에는 점점 더 많은 작업이 필요합니다. 분명히 간단한 ls작업을 수행하는 데 시간이 오래 걸리며 모든 inode를 읽고 정렬하기 전까지는 아무것도 보이지 않습니다. 이렇게 ls -U(정렬되지 않은)는 당신이 안 죽었어 볼 수 있기 때문에 조금 도움이되지만 지각 할 시간을 감소하지 않습니다. 와일드 카드 확장시 각각의 모든 파일 이름을 확인해야하며, 대부분의 경우 전체 inode도 읽어야합니다.

한마디로 : 셸 액세스를 포함하여 어떤 응용 프로그램도 와일드 카드를 사용하지 않을 것이라고 확신 할 수 있다면 후회없이 큰 디렉토리를 얻을 수 있습니다. 그러나 코드에 일부 와일드 카드가 숨겨져 있으면 디렉토리를 각각 천 항목 이하로 유지하는 것이 좋습니다.

편집 :

모든 최신 파일 시스템은 큰 디렉토리에 대해 우수한 데이터 구조를 사용하므로 특정 파일 의 inode를 찾아야하는 단일 작업은 거대한 디렉토리에서도 상당히 빠릅니다.

그러나 대부분의 응용 프로그램은 단일 작업 만 수행하지 않습니다. 대부분은 전체 디렉토리 또는 와일드 카드 일치를 수행합니다. 그것들은 모든 항목을 읽는 것을 포함하기 때문에 무엇이든 느립니다.

예를 들어, 'foo-000000.txt'에서 'foo-999999.txt'까지의 백만 개의 파일과 단일 'natalieportman.jpeg'가있는 디렉토리가 있다고 가정합니다. 이것들은 빠를 것이다 :

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

이것들은 실패하지만 빨리 실패합니다.

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

결과가 거의 반환되지 않더라도 속도가 느려집니다. 실패한 경우에도 모든 항목을 스캔 한 후 실패합니다.

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

먼저 ext3 파티션에 dir_index플래그가 설정되어 있는지 확인하십시오 .

sudo dumpe2fs /dev/sdaX |grep --color dir_index

누락 된 경우 활성화 할 수 있습니다. 파일 시스템을 마운트 해제 한 후 다음을 실행해야합니다.

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

그런 다음 파일 시스템을 마운트하십시오.

디렉토리 당 ext3 32,000 개의 이름 제한에 도달 할 때까지 차이가 ​​없습니다. ext4로 업그레이드하면 ext4의 다른 이점뿐만 아니라 그 문제를 해결할 수 있습니다.

단일 디렉토리에 더 많은 항목 (파일 및 디렉토리)이있을수록 액세스 속도가 느려집니다. 일부 파일 시스템은 다른 파일 시스템보다 나쁘지만 모든 파일 시스템에 적용됩니다.

더 나은 해결책은 다음과 같은 디렉토리 계층을 작성하는 것입니다.

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

여전히 더 나은 성능이 필요한 경우 여러 수준을 확장 할 수 있습니다.

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

대부분의 메일 시스템은 메일 큐 파일과 함께이 트릭을 사용합니다.

또한 일부 파일 시스템의 경우 디렉토리에 많은 항목이 있으면 디렉토리 액세스 속도가 느려집니다. 를 수행 ls -ld디렉토리 항목 자체의 크기를 볼 수있는 디렉토리에. 몇 MB 이상이고 디렉토리가 비교적 비어 있으면 성능이 저하 될 수 있습니다. 디렉토리 이름을 바꾸고 동일한 이름과 권한 및 소유권을 가진 새 디렉토리를 작성한 다음 이전 디렉토리의 컨텐츠를 새 디렉토리로 이동하십시오. 이 트릭을 여러 번 사용하여 파일 시스템에 의해 속도가 느려지는 메일 서버의 속도를 크게 향상 시켰습니다.

최근에 수천만 개의 파일과 수십만 개의 디렉토리를 만들어야하는 스토리지 서버를 개발했습니다. XFS를 ext4 및 reiserf와 비교했습니다. 필자의 경우 ext4가 XFS보다 약간 빠릅니다. Reiser는 흥미롭지 만 한계가 있었기 때문에 삭제되었습니다. 또한 ext4가 ext3보다 훨씬 빠릅니다.

디렉토리 당 많은 파일을 가져 오면 파일 열기 시간이 길어집니다. 파일 I / O는 그렇지 않습니다. 파일 삭제 시간도 겪습니다. 그러나 ext4에서는 너무 느리지 않습니다. ext3에서는 상당히 눈에.니다. XFS와 ext4는 이것에 매우 빠릅니다.

마지막으로 XFS를 살펴보고 ext4보다 XFS를 사용할 때의 장단점을 검토 할 때 XFS의 데이터 손실에 대한보고가있었습니다. 나는 이것이 여전히 문제인지 또는 확실하지 않다는 것을 확신하지 못하지만, 명확하게 조종 할만 큼 긴장했다. ext4는 우분투의 기본 fs이므로 XFS보다 쉽게 ​​뛰어납니다.

따라서 경영 관점에서 도움이되는 tylerl의 제안 외에도 ext4로 업그레이드 할 수 있습니다. 디렉토리 당 한도는 ext4 인 64000 개의 항목입니다.

또 다른 장점은 fsck 시간이 훨씬 빠르다는 것입니다. 부패와 관련된 문제는 없었습니다.

ext4의 좋은 점은 ext3 볼륨을 ext4에 마운트하여 사용해 볼 수 있다는 것입니다. 참조 : ext3에서 ext4 파일 시스템으로 라이브 시스템 마이그레이션

해당 링크의 인용문 :

ext3의 한계에 영향을받지 않고 위험을 감수하지 않으려는 경우 가치가 없을 수 있습니다. 반면, 마이그레이션 절차를 성공적으로 완료하면 시스템이 더 빨리 수행되고 파일 시스템 검사가 단축되며 악영향없이 안정성이 향상 될 수 있습니다.

계속 해보십시오. 먼저 백업을 제안하십시오.

확실히 그렇게하면 몇 가지 결과가 초래 될 것입니다. 기본은 IO 읽기 / 쓰기입니다. 그 외에도, 해당 유형의 데이터 (해당 규모로)를 처리하는 것은 매우 무서운 방법입니다.

과거에는 XFS를 사용하여 Ext3의 한계를 극복했습니다.

파일 시스템 내용의 첫 번째 목록은 시스템이 모든 디렉토리 / 파일 정보를 읽을 때까지 시간이 걸립니다. 커널에 정보가 캐시되므로 보충 작업이 더 빨라집니다.

관리자가 캐시를 활성 상태로 유지하기 위해 정기적으로 cron에서 'find / somepath 2> & 1> / dev / null'을 실행하여 성능을 향상시키는 것을 보았습니다.

몇 가지 질문과 가능한 병목 현상이 있습니다.

첫째, 이것이 CentOS 5 또는 6 시스템입니까? 6에는 blktrace라는 놀라운 도구가 있으므로 이러한 상황에서 영향을 측정하는 데 이상적입니다.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

그런 다음 btt로 출력을 구문 분석하고 병목 현상이 발생하는 위치, 응용 프로그램, 파일 시스템, 스케줄러, 스토리지-IO가 대부분의 시간을 소비하는 구성 요소를 얻을 수 있습니다.

이제 이론적으로 귀하의 질문에 이르면 분명히 inode 수가 증가하고 디렉토리 내에서 새 파일이나 기존 파일이나 디렉토리를 계속 작성하거나 액세스하면 액세스 시간이 증가합니다. 커널은보다 광범위한 파일 시스템 계층 구조를 통과해야하므로 의심의 여지없이 오버 헤드가 발생합니다.

주의해야 할 또 다른 사항은 디렉토리 수를 늘리면 inode 및 dentry 캐시 사용량이 증가하여 더 많은 RAM을 소비한다는 의미입니다. 이것은 슬랩 메모리 아래에 있으므로 서버의 메모리가 부족하면 또 다른 생각입니다.

실제 예를 들어 최근에 중첩 된 ext3 fs에서 처음으로 하위 디렉토리를 만드는 데 약 20 초가 걸리고 ext4에서는 약 4 초가 걸리는 것을 보았습니다. 블록 할당이 다른 파일 시스템으로 구성되는 방식 때문입니다. XFS 또는 ext4를 사용하는 경우 약간의 성능 향상을 가져올 것이라고 말할 필요는 없습니다.

따라서 파일 시스템의 올바른 선택을 요구하는 경우 ext3은 약간 구식입니다. 이것이 추가 데이터 및 벤치 마크없이 제공 할 수있는 전부입니다.

CentOS 5의 옵션이 아니며 CentOS 6의 옵션이 얼마인지 확실하지 않지만 B 트리 또는 B * 트리 기반 솔루션, 즉 BTRFS가 특정 성능을 크게 향상 시키지는 않지만 일관성을 제공 할 것이라고 생각합니다. 시나리오, 오직 하나만이 분명한 양심으로 자신의 소중한 데이터로 그것을 맡길 수 있다면 (아직 안 할 것입니다).

그러나 여유가 있다면 테스트 할 수 있습니다.