디스크 I/O 알고리즘 실행 시간

Question

메모리 기반 컴퓨팅 모델에서 수행해야하는 실행 시간 계산은 데이터 구조를 고려하여 추상적으로 수행 할 수 있습니다.

그러나 고성능 디스크 I/O 알고리즘에는 많은 문서가 없습니다. 따라서 다음과 같은 질문을합니다.

1) 디스크 I/O 작업의 실행 시간은 어떻게 추정 할 수 있습니까? 메모리 상보다는 디스크 상에있는 값을 찾기 위해 추가 할 수있는 간단한 상수 세트가 있다고 가정합니다 ...

2) 그리고 더 구체적으로, 특정 인덱스에 액세스하기위한 성능 간의 차이점은 무엇입니까? 파일? 이것은 일정한 시간 작동입니까? 아니면 인덱스가 얼마나 멀리 떨어져 있는가에 달려 있습니까?

3) 마지막으로 JVM은 파일의 색인 된 부분에 대한 액세스를 어떻게 최적화합니까?

... 리소스까지 - 일반적으로 ... 디스크 데이터 구조 구현을위한 훌륭한 숙어 또는 라이브러리가 있습니까?

Answer 1

1) 디스크 입출력 작업의 실행 시간을 어떻게 예측할 수 있습니까? 나는 Computer Systems: A Programmer's Perspective의 제 6 장에서

이

그들이 얼마 동안 매우 실제적인 수학적 모델을 제공합니다 ... 우리는 오히려 메모리보다 디스크에 값을 찾기위한 추가 할 수 있습니다 상수의 간단한 세트가있는 가정이 일반적인 마그네틱 디스크에서 일부 데이터를 읽는 데 소요됩니다.

링크 된 PDF의 마지막 페이지를 인용 : 데이터가 최근 한 액세스하는 경우

Putting it all together, the total estimated access time is 
Taccess = Tavg seek + Tavg rotation + Tavg transfer 
     = 9 ms  + 4 ms   + 0.02 ms 
     = 13.02 ms 

This example illustrates some important points: 
• The time to access the 512 bytes in a disk sector is dominated by the seek time and the rotational 
latency. Accessing the first byte in the sector takes a long time, but the remaining bytes are essentially 
free. 
• Since the seek time and rotational latency are roughly the same, twice the seek time is a simple and 
reasonable rule for estimating disk access time. 

* 노트, 링크 된 PDF는, 저자 웹 사이트 ==없이 불법 복제 물론

에서입니다 액세스 할 때 메모리 heiarchy의 어딘가에 캐시 될 수있는 적절한 기회가 있습니다.이 경우 액세스 시간은 극히 적습니다 (실제적으로 디스크 액세스 시간과 비교할 때 "거의 즉시"입니다).

2) 더 구체적으로 파일의 특정 색인에 액세스하는 성능의 차이점은 무엇입니까? 이것은 일정한 시간 작동입니까? 아니면 인덱스가 얼마나 멀리 떨어져 있는가에 달려 있습니까?

탐색 된 위치가 순차적으로 근처에 순차적으로 저장되지 않으면 다른 seek + rotation 시간이 발생할 수 있습니다. 그것은 당신이 찾고있는 파일의 어디에 그리고 그 데이터가 물리적으로 디스크에 저장되어 있는지에 달려 있습니다. 예를 들어, 조각난 파일은 디스크 탐색이 전체 파일을 읽도록합니다.

몇 가지 바이트 만 읽도록 요청할 수도 있지만 물리적 읽기는 캐시에서 끝나는 고정 크기 청크 (섹터 크기)의 배수에서 발생하는 경향이 있다는 점을 명심해야합니다. 따라서 나중에 파일의 인근 위치를 찾아 캐시에 이미 저장되어있는 행운의 행운을 얻을 수 있습니다.

Btw- 주제에 관심이있는 경우 메모리 계층 구조에있는 책의 전체 장이 순수 금입니다.

Answer 2

1) 디스크 입출력 작업의 실행 시간을 어떻게 예측할 수 있습니까? 나는 메모리 대신에 디스크에 값을 찾는 것에 추가 할 수있는 간단한 상수 집합이 있다고 가정합니다 ...

그런 범용 상수는 없습니다. 실제로 물리적 디스크 I/O, 파일 시스템 및 운영 체제의 성능 모델은 너무 복잡하여 특정 작업에 대한 정확한 예측을 수행 할 수 없습니다.

2) 더 구체적으로 파일의 특정 색인에 액세스하는 성능의 차이점은 무엇입니까? 이것은 일정한 시간 작동입니까? 아니면 인덱스가 얼마나 멀리 떨어져 있는가에 달려 있습니까?

예상하기가 너무 복잡합니다. 예를 들어, OS가 수행하는 파일의 양, 물리적 디스크 매개 변수 (예 : 검색 시간) 및 OS가 모든 응용 프로그램에서 디스크 활동을 얼마나 효율적으로 예약 할 수 있는지에 따라 다릅니다.

3) 마지막으로 JVM은 파일의 색인 된 부분에 대한 액세스를 어떻게 최적화합니까?

아니요. 이것은 운영 체제 수준의 것입니다.

4) 디스크 데이터 구조 구현을위한 훌륭한 숙어 또는 라이브러리가 있습니까?

실제 요구 사항에 대한 자세한 내용 없이는 대답하기가 어렵습니다. 그러나 최선의 아이디어는 이런 종류의 일을 스스로 시도하고 실행하는 것이 아닙니다. 요구 사항에 적합한 기존 라이브러리를 찾으십시오.

Answer 3

1) 다양한 IO 기능의 속도를 비교해야하는 경우 천 시간을 실행하고 소요 시간을 기록해야합니다.

2)이 색인을 얻는 방법에 따라 달라집니다. 파일의 시작 부분에 대한 색인은 파일의 중간에있는 색인과 완전히 동일합니다. 단지 디스크의 메모리 섹션을 가리키고 있습니다.처음에 시작하여 거기에서 진행하여이 색인에 도달하면 그렇습니다. 시간이 오래 걸릴 것입니다.

3/4) 아니요 운영 체제 자체에서 관리하지 않습니다. Java는 이러한 종류의 조작을 처리 할만큼 낮은 수준이 아닙니다.

Answer 4

고성능 디스크 I/O 알고리즘.

하드웨어의 성능은 일반적으로 소프트웨어에서 수행하는 작업이 그다지 중요하지 않으므로 중요합니다. 먼저 작업에 적합한 하드웨어를 구입하는 것이 좋습니다.

디스크 입출력 작업의 실행 시간을 어떻게 예측할 수 있습니까? 나는 메모리 대신에 디스크에 값을 찾는 것에 추가 할 수있는 간단한 상수 세트가 있다고 가정합니다 ...

언제나 많은 마이크로 초 마다. 예를 들어, HDD는 80-120 IOP를 수행 할 수 있고 SSD는 80K - 230K IOP를 수행 할 수 있습니다. 일반적으로 제조업체가 쉽게 지정하는 것의 1/2 내에서 얻을 수 있으며 소프트웨어에서 트릭을 할 수있는 곳은 100 %입니다. 많은 양의 메모리가 있고 OS가 모든 작업을 수행하는 경우에만 데이터를 읽지 않는 한 HDD를 SSD처럼 수행하지 않아도됩니다.

hybrid drives은 HDD의 용량은 있지만 성능은 SSD에 가깝습니다. 상업적 생산을 위해서는 디스크 서브 시스템의 돈을 여러 드라이브와 함께 쓰는 것이 좋습니다. 이렇게하면 500 IOPS로 성능이 향상 될 수 있지만 비용이 크게 증가 할 수 있습니다. 일반적으로 용량과 중복성이 필요하기 때문에 디스크 하위 시스템을 구입하지만 대개 성능 향상을 얻을 수 있지만 함께 작동하는 디스크 회전이 더 많습니다. disk subsystem performance의이 링크는 오래되었지만 (2004) 그 이후로 많이 변경되지 않았습니다.

더 구체적으로 파일의 특정 색인에 액세스하는 성능 간의 차이점은 무엇입니까? 이것은 일정한 시간 작동입니까? 아니면 인덱스가 얼마나 멀리 떨어져 있는가에 달려 있습니까?

메모리에 있는지 여부에 따라 달라집니다. 최근에 읽은 데이터에 매우 가깝다면 아주 멀리있는 경우 과거에 수행 한 액세스와 디스크 액세스를 캐시 할 수있는 메모리 양에 따라 다릅니다.

일반적인 대기 시간은 각각 ~ 8ms입니다. 즉, 대기열에 10 개의 임의 읽기가있는 경우 80ms가 될 수 있습니다. SSD의 일반적인 대기 시간은 25 ~ 100 us입니다. 읽기 시작은 이미 대기열에있을 가능성이 훨씬 적습니다. 시작하기가 훨씬 빠르기 때문입니다.

어떻게 JVM이 파일의 색인 된 부분에 대한 액세스를 최적화합니까?

현명한 버퍼 크기를 사용한다고 가정하면 소프트웨어에서 일반적으로 할 수있는 일은 거의 없습니다. 당신이 할 수있는 일은 OS에 의해 수행됩니다.

디스크 데이터 구조 구현을위한 훌륭한 숙어 또는 라이브러리가 있습니까?

512 바이트에서 64KB 사이의 적절한 버퍼 크기를 사용하십시오.

더욱 중요한 것은 요구 사항에 적합한 하드웨어를 구입하는 것입니다.

Answer 5

Linux 시스템은 적어도 다른 파일 시스템을 허용합니다. 응용 프로그램에 따라 다른 응용 프로그램보다 적합 할 수 있습니다. http://en.wikipedia.org/wiki/File_system#Linux