Linux : 파일을 읽는 데 얼마나 많은 디스크 I / O가 필요합니까? 그것을 최소화하는 방법? [복제]


10

페이스 북의 건초 더미에 관한 이 논문 에 따르면 :

" NAS 어플라이언스가 디렉토리 메타 데이터를 관리하는 방법 때문에 디렉토리의 블록 맵이 너무 커서 어플라이언스가 효과적으로 캐시 할 수 없기 때문에 디렉토리에 수천 개의 파일을 배치하는 것은 매우 비효율적입니다. 결과적으로 10 번 이상의 디스크 작업이 발생하여 단일 이미지 디렉토리 당 디렉토리 크기를 수백 개의 이미지로 줄인 후에도 결과 시스템은 일반적으로 3 개의 디스크 작업을 수행하여 이미지를 가져옵니다. 하나는 디렉토리 메타 데이터를 메모리로 읽고 다른 하나는 inode를 메모리에로드하고 다른 하나는 메모리에로드합니다. 파일 내용을 읽습니다. "

파일 시스템 디렉토리 메타 데이터 및 inode는 항상 OS에 의해 RAM에 캐시되며 파일 읽기에는 일반적으로 1 개의 디스크 IO 만 필요하다고 가정했습니다.

이 백서에 요약 된이 "다중 디스크 IO가 단일 파일을 읽습니다"문제가 NAS 어플라이언스 고유의 문제입니까, 아니면 Linux에도 동일한 문제가 있습니까?

이미지를 제공하기 위해 Linux 서버를 실행할 계획입니다. 디스크 IO 수를 최소화 할 수있는 방법은 무엇입니까? 이상적으로 OS가 모든 디렉토리 및 inode 데이터를 RAM에 캐시하고 각 파일을 읽을 때 1 개의 디스크 IO 만 필요합니까?


1
질문에 대한 대답은 아니지만 메모리에 파일을 유지 관리하는 Varnish (Facebook에서 사용)를 항상 사용할 수 있습니다. 이런 식으로 하나의 이미지가 뜨거워지면 (동일한 파일에 대한 많은 요청) 디스크 IO는 전혀 사용되지 않습니다

Darhazer-Varnish는 Varnish가 의존하는 Linux 파일 캐시가 이미 핫 파일을 메모리에 캐시하므로 도움이되지 않습니다. 정적 파일 제공을 위해 Nginx 앞에 Varnish를 추가해도 실제로 아무것도 추가되지 않습니다. 내 질문은 파일이 너무 커서 너무 많아서 메모리에 캐시되지 않는 경우에 관한 것입니다. 디스크 IO를 읽기 당 1로 줄이기 위해 적어도 디렉토리 데이터 및 inode가 캐시되도록하고 싶습니다.

많은 파일 시스템은 inode를 디렉토리에 저장하여 요청 수를 1만큼 줄이고 캐시 적중 가능성을 크게 높입니다. 그러나 이것은 프로그래밍 문제가 아닙니다.
Ben Voigt

파일 시스템을 만들 때 파일 시스템의 블록 크기를 변경할 수 있습니다 (예 : mke2fs -b 3276832k로). 그러나 이는 해당 파일 시스템에 작은 파일이없는 경우에만 유용합니다.

답변:


5

리눅스는 같은 "문제"를 가지고 있습니다. 다음 은 2 년 전에 저의 학생이 출판 한 논문으로, 그 효과가 Linux에 표시되어 있습니다. 여러 IO는 여러 소스에서 제공 될 수 있습니다.

  • 파일 경로의 각 디렉토리 레벨에서 디렉토리 검색. 디렉토리 inode와 하나 이상의 디렉토리 엔트리 블록을 읽어야 할 수도 있습니다.
  • 파일의 아이 노드

일반적인 IO 패턴에서 캐싱은 실제로 효과적이며 검색을 줄이는 방식으로 inode, 디렉토리 및 데이터 블록이 할당됩니다. 그러나 실제로 모든 파일 시스템에서 공유하는 일반 조회 방법은 트래픽이 많이 할당되는 경우에 나쁩니다.

몇 가지 아이디어가 있습니다.

1) 파일 시스템 관련 캐시가 도움이됩니다. 큰 캐시는 대부분의 읽기를 흡수합니다. 그러나 컴퓨터에 여러 디스크를 배치하려는 경우 디스크 대 RAM 비율은 캐시되는 양을 제한합니다.

2) 수백만 개의 작은 파일을 사용하지 마십시오. 파일을 더 큰 파일로 집계하고 파일 내에 파일 이름과 오프셋을 저장하십시오.

3) SSD에 메타 데이터를 배치하거나 캐시하십시오.

4) 물론 완전히 온 디스크 디렉토리 형식을 갖지 않는 파일 시스템을 사용하십시오. readdir은 선형 시간 이상을 가져서는 안되며 직접 파일 액세스는 로그 시간에 이상적입니다.

캐시해야 할 디렉토리가 더 필요하므로 디렉토리를 작게 (1000 이하) 유지하는 것은 큰 도움이되지 않습니다.


물론 완전히 온 디스크 디렉토리 형식이없는 파일 시스템을 사용하십시오. readdir은 선형 시간 이상을 가져서는 안되며 직접 파일 액세스는 로그 시간에 이상적입니다.
jørgensen

나는 대답을 4 포인트로 추가했다
dmeister

@dmeister 좋은 물건. +1
Magellan

@dmeister 연결이 끊어졌습니다.
Don Scott

1

이것은 사용하려는 파일 시스템에 따라 다릅니다. 파일 데이터 시스템을 읽기 전에 :

  • 디렉토리 파일을 읽으십시오.
  • 파일의 inode 읽기
  • 파일의 섹터를 읽습니다

폴더에 많은 수의 파일이 포함 된 경우 이는 캐시에 대한 큰 보장입니다.


I / O 액세스를 나열하는 경우 수행 한 작업 open()과 수행 한 작업을 분리하는 것이 더 흥미로울 수 있습니다 read(). win.tue.nl/~aeb/linux/vfs/trail.html 페이지 는 관련된 다양한 커널 개념을 잘 보여줍니다. (아마 구식 일지 모르겠다. 말할 수 없을 것이다.)
adl

0

RAM보다 디렉토리 및 inode 데이터가 더 많기 때문에 모든 디렉토리 및 inode 데이터를 RAM에 보관할 수 없습니다. RAM이 다른 목적으로 더 잘 사용될 수 있으므로 원하지 않을 수도 있습니다. 이미지 예제에서 자주 액세스하지 않는 이미지의 데이터를 자주 액세스하지 않는 이미지의 디렉토리 항목보다 RAM에 캐시하지 않으시겠습니까?

즉, vfs_cache_pressure 노브를 사용하여이를 제어 한다고 생각합니다 . "vfs_cache_pressure = 0 일 때 커널은 메모리 부족으로 인해 덴 트리와 아이 노드를 회수하지 않으며 메모리 부족 상태로 쉽게 이어질 수 있습니다."

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.