한 디렉토리에 50,000 개의 파일이 있는데, 가장 좋은 방법은 무엇입니까?


2

이 디렉토리 구조를 / var / www / $ WEBSITE / $ DIR1 / $ DIR2 / $ FILES로 만들어야합니다.

각 $ FILES에 대해 약 50,000 개의 XHTML 페이지가 있습니다.

새로운 프론트 엔드 캐싱을 지원하는 Cherokee를 실행하고 있습니다. 그러나 나는 메모리가 다소 제한되어 있으므로 전체를 캐시 할 수 없습니다. 나는 목록을 캐시 할 수 있다고 믿습니다. 이는 최악의 부분입니다.

파일 시스템 측면에서 무엇을 할 수 있습니까? 나는 일반적으로 ext4 (내 서버는 ext3을 사용하고 있음)를 사용하지만 이러한 유형의 상황에는 ReiserFS가 선호된다는 것을 알고 있습니다. ReiserFS에 $ WEBSITE를 마운트 할 수 있습니다. 나는 정말로 파티션을 다시 나누기를 기대하지 않으며, 이것을 해결하고 싶습니다.

파일 시스템 어딘가에서 엇갈린 하위 디렉토리를 수행하고 이들을 모두 $ DIR2에 심볼릭 링크 할 수 있습니까? ext3의 고통을 덜어 주면서이 불쾌한 상황을 더 잘 수행하는 데 도움이 되겠습니까?

나는 정말로 RDB를 원하지 않고 NOSQL 옵션을 고려할 것입니다. 어떻게 든 가짜 파일 시스템을 만들 수 있다면. 그것은 멋진 옵션이 될 수도 있습니다. 아마도 퓨즈와 관련이 있습니까?

전체 사이트가 이미 존재하며 기본적으로 멋진 디렉토리 목록입니다. 파일은 한 번 작성된 다음 거기서 읽습니다. 이 시점부터 디렉토리 당 파일 수가 증가 할 가능성은 없습니다.


방금 dir_index를 활성화했는데 문제가 도움이 될 수 있습니다.
— JM 베커

답변:


2

50,000 개의 파일로는 Linux에서 심각한 속도 문제가 발생할 수 없습니다. 목록 캐싱에 대해 언급 했으므로 일반 서비스 대신 파일에서 약간의 처리를 수행하고 있다고 생각합니다. 파일을 처리하는 방법에 대한 문제를 찾습니다.


1
방금 서버를 확인했는데 ext3을 사용하고 있습니다. 불행히도 dir_index를 활성화하지 않았습니다. 성능 문제가 50,000보다 훨씬 낮습니다. 나는 이것을 설명하지 못했기 때문에 이것에 대한 당신의 대답을 잘못하지 않습니다. 또한 "Linux"라고 말한 방식이 올바르지 않습니다. 커널이 많은 파일을 처리 할 수 ​​있다는 것은 의심 할 여지가 없습니다. 파일 시스템이 작업에 맞지 않을 수도 있습니다. 그러나 해당 폴더에서 파일을 처리하지 않습니다. 정적 XHTML 파일입니다. 캐시하도록 디렉토리 목록으로 유일하게 동적 페이지입니다.
— JM 베커

여전히 다른 문제가 있다고 생각합니다. ext3 루프백 파일 시스템에 50,000 개의 1k 파일을 생성했으며 "ls >> / dev / null"에 .2 초가 걸립니다.
— mfarver

예. 추가 주요 문제는 이것이 xen VM이라는 것입니다. 호스팅 회사에서이 아기를 임대합니다. 개인 VPS입니다 (작업과 관련이 없으므로 VM을 임대 한 이유입니다). BTW, 테스트 할 때 dir_index가 활성화되어 있지 않은지 확인 했습니까?
— JM 베커

2

가능한 한 가지 예외를 제외하고 XFS를 권장합니다. 해당 디렉토리 트리에서 많은 파일을 제거해야하는 경우 XFS에서 삭제 성능이 별다른 문제가 아닙니다. 그러나 이것은 새로운 delaylog 마운트 매개 변수 로 조금 개선되었습니다 .

그 외에는 XFS는 디렉토리에 50 000 개의 파일을 기침조차하지 않습니다.


1

XFS를 시도 할 수 있습니다. XFS 파일 시스템에서 큰 디렉토리를 실행하여 좋은 결과를 얻었습니다. ls, du다른 파일 작업 및 ext3을보다 눈에 띄게 더 낫다. 어느 쪽이든, 확장 성을 위해 더 깨끗한 디렉토리 구조를 개발하는 것이 합리적 일 수 있습니다.

[root@bootylicious /data/print]# ls -1 | wc -l
431801

이 시점부터 사이트를 확장 할 필요가 없습니다. 정상적인 사용법에는 아무것도 기록되지 않습니다.
— JM 베커

1

내 문제에 대한 해결책을 찾았습니다

내 FS 성능으로 인해 ~ 5000 파일만으로 불편 해 졌기 때문에이 질문을 게시했습니다. 나는 보통 Ext4를 사용하고 XFS를 사용했다. 항상 확고한 수행자였습니다. 하지만 이미 Ext3에 모든 것이 설치되어 있습니다.

Ext4는 기본적으로 Htree 인덱스를 활성화하여 문제가되지 않습니다. Ext3은 Htree 인덱스, dir_index를 지원합니다; 그러나 내 FS에서 활성화되지 않았습니다.

# I Checked Ext features, no dir_index
$ tune2fs -l /dev/xvda | grep features

# Enabled dir_index
$ tune2fs -O dir_index /dev/xvda

재부팅 후 fsck를 실행해야했지만 그렇지 않으면 성공적으로 활성화되었습니다. 해당 디렉토리에 파일을 나열하면 성능 문제가 사라졌습니다. NoSQL 기반 VFS, gridfs-fuse를 구현하지 않아도됩니다. 완전히 할당 된 HD에서 크기 조정 / 복구를 피할 수있었습니다.

FS를 변경하는 경우, 가능하다면 이런 종류의 디스크 작동을 피하고 싶었습니다.


1
그것이 Xen에 있다고 언급하면 ​​도움이 될 것입니다. 디스크 엘리베이터 큐를 noop로 설정하려고 시도 할 수 있습니다. 커널 매개 변수에 elevator = noop를 추가하십시오.
— mfarver
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.