커널이 새로운 파일 생성을 처리하는 방법

Question

사용자/응용 프로그램이 직접 작업으로 파일을 만들려고 할 때 커널이 작동하는 방식을 이해하고 싶습니다.

배경 - JMS를 통해 메시지를 소비하고 처리 한 다음 아웃 바운드 대기열 + 로컬 디렉토리에 XML을 쓰는 Java 응용 프로그램이 있습니다. 어제 우리는 디렉토리에 서면으로 비공식적 인 지연을 포기했다. 'ls | wc -l'에 300,000 개가 넘는 파일이 있습니다. 이 과정에서 빠른 strace를 수행하여 mutex 호출로 가득 찬 것으로 나타났습니다 (strace에서 3/4 이상의 호출은 뮤텍스였습니다).

그래서 나는 시스템이 매번 300,000 개의 파일 중에서 특정 항목 (예 : 특정 이름의 새 파일을 만들 수 있는지 확인하기위한 파일 이름)을 검사해야하므로 새 파일 작성에 시간이 걸린다 고 생각했습니다. 파일.

디렉토리를 지우고 응용 프로그램이 일반 서비스 수준으로 재개되었습니다.

내 질문에

1. 내 분석 (그것은 명확한 후 벌금을 아래로 일하기 시작 응용 프로그램 사촌 것) 올바른 되었습니까?
2. 더 많은 imporatant, 디렉토리에 새 파일을 만들려고 할 때 커널이 어떻게 작동합니까?
3. 비정상적인 수의 뮤텍스 호출이 디렉토리의 많은 수의 파일에 귀속 될 수 있습니까?

많은 덕분에 많은 수의 항목에 J

Answer 1

리눅스 파일 시스템, i- 노드 및 d- 노드에 대해 읽어보십시오.

http://en.wikipedia.org/wiki/Inode_pointer_structure

파일 시스템

은 고정 된 크기의 블록으로 구성되어 있습니다. 디렉토리가 상대적으로 작 으면 직접 블록에 적합하며 모든 것이 빠릅니다. 디렉토리가 너무 크지 않으면 직접 블록과 일부 간접 블록에 적합하며 여전히 상당히 빠릅니다. 디렉토리가 너무 커지면 두 개의 간접 블록으로 유출되고 느려집니다.

실제 크기는 파일 시스템 및 커널 구성에 따라 다릅니다.

규칙은 사용자의 블록 크기에 따라 디렉토리를 12 블록 아래로 유지하는 것입니다. 많은 시스템이 8K 블록을 사용합니다. 빠른 디렉토리는 98,304 바이트 미만입니다.

파일 항목은 16 * 4 바이트 크기 (IIRC)와 비슷하므로 디렉토리 당 최대 1500 개의 파일을 실제 상한으로 계획하십시오.

Answer 2

디렉토리 느린 종종 - 기본이되는 파일 시스템에 따라 달라 천천히.

일반적인 해결책은 디렉토리의 계층 구조를 만드는 것이므로 각 디렉토리에는 몇 백 개의 항목 만 있습니다.

Answer 3

뮤텍스 시스템 호출은 mutex 호출을 만드는 응용 프로그램 (아마도 JVM 또는 Java 라이브러리의 무언가)의 결과입니다.

커널 내부의 동기화는 시스템 호출 만 검사하므로 strace를 통해 볼 수 없습니다.

디렉토리 색인을 사용하는 파일 시스템을 사용하는 경우 많은 파일이있는 디렉토리가 비효율적이어서는 안됩니다. 대부분의 경우 (ext3은 선택적이지만 현재는 일반적으로 사용 가능합니다).

색인이없는 디렉토리 (예 : 잘못된 오래된 파일 시스템 (ext2, vfat 등)에서 사용 된 것과 같은)는 많은 파일을 가지고 정말 나 빠지고 더 오래 걸리는 "열린"시스템 호출을 보게됩니다.