인사말,
다양한 사진 웹 사이트의 이미지를 처리하는 스크립트를 작성 중입니다. 지금은이 모든 데이터를 동일한 디렉토리의 개별 텍스트 파일에 저장합니다.
디렉토리는 웹에 액세스 할 수 있습니다. 최종 사용자는 웹 서비스를 호출하여 사용자에게 필요한 파일 경로를 반환합니다.
이 모든 파일을 같은 디렉토리에두면 어떤 단계에서 성능에 영향을 줄지 궁금합니다. (만약에 어떠한)
답변:
사용중인 파일 시스템에 따라 성능이 다릅니다.
EXT3 : 물리적 한계는 32,000 파일이지만 perf는 수천 파일 후에도 고통을받습니다.
EXT4 : 이론적으로 무한
ReiserFS, XFS, JFS, BTRFS : 디렉토리에있는 많은 파일에 대해 더 현대적이고 많은 파일을 처리하도록 설계되어 있습니다. . 원하는 파일을 얻기 위해 이진 검색 유형 알고리즘을 사용하므로 다른 파일은 더 선형적인 파일을 사용하므로 많은 파일 (ext4와 함께)의 성능이 훨씬 우수합니다.
웹 서버에서 제공 할 이미지를 저장하고 EXT3의 한 디렉토리에 300,000 개가 넘는 이미지가 있습니다. 성능 문제가 없습니다. 이것을 설정하기 전에 디렉토리에서 500k 이미지로 테스트하고 이름으로 파일에 무작위로 액세스했으며 디렉토리에서 10k 이미지가 500k 이상인 경우 속도가 크게 느려지지 않았습니다.
내가 볼 수있는 유일한 단점은 새 서버를 두 번째 서버와 동기화하기 위해 rsync전체 디렉토리 를 실행해야 하며 가장 최근의 약 1000 정도가 포함 된 하위 디렉토리를 동기화하도록 지시 할 수 없다는 것입니다.
폴더에있는 파일의 양은 이론적으로 무한 할 수 있습니다. 그러나 OS가 파일을 찾기 위해 특정 폴더에 액세스 할 때마다 폴더의 모든 파일을 처리해야합니다. 파일이 500 개 미만이면 지연이 발생하지 않을 수 있습니다. 그러나 단일 폴더에 수만 개의 파일이 있으면 간단한 폴더 목록 명령 (ls 또는 dir)이 너무 오래 걸릴 수 있습니다. FTP를 통해 이러한 폴더에 액세스 할 수 있으면 실제로 너무 느려집니다.
성능 문제는 실제로 OS가 아니라 시스템 프로세서 속도, 디스크 용량 및 메모리에 달려 있습니다. 파일이 많은 경우 파일을 단일 아카이브로 결합하고 많은 데이터를 보유하도록 최적화 된 아카이브 시스템을 사용할 수 있습니다. 이것은 ZIP 파일 일 수 있지만 파일 이름이 기본 키인 데이터베이스에 Blob으로 저장하는 것이 좋습니다.
ls문제 를 일으키는 것은 문제입니다.
@skaffman이 지적했듯이 한계는 운영 체제에 따라 다릅니다. 구형 OS의 한계에 영향을받을 수 있습니다. 이전 버전의 Solaris는 디렉토리 당 32768 개의 파일로 제한되어있었습니다.
일반적인 해결책은 일종의 해싱을 사용하는 것입니다. 즉, Cyrus imap 서버는 사용자를 알파벳 해시로 나눕니다.
/var/spool/imap/a/user/anna/
/var/spool/imap/a/user/albert/
/var/spool/imap/d/user/dan/
/var/spool/imap/e/user/ewan/
파일에 직접 액세스하는 경우 디렉토리의 파일 수는 속도 문제가 아닙니다.
단일 디렉토리에서 작성할 수있는 파일 수는 사용중인 파일 시스템에 따라 다릅니다. 디렉토리의 모든 파일을 나열하거나 검색, 정렬 등 많은 파일을 가지고 있으면 해당 작업이 느려집니다.
gbjbaanb는 ext3의 최대 파일 크기에 대한 그의 답변이 잘못되었습니다. 일반적으로 ext는 일반적으로 디스크의 파일 수를 제한합니다. 더 많은 파일을 만들 수 없으면 inode 테이블에 inode가 있습니다. 그는 많은 파일에서 더 많은 성능을 위해 reiserfs를 제안하는 것이 정확