한 디렉토리에 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.