사용자 수준 프로그램이 SSD에서 페이지 수준 또는 블록 수준 I/O를 수행할 수 있습니까?
디스크 장치를 살펴봤지만 파티션에 파일 시스템이 있는 경우에만 작동하므로 이 기능을 제공하는지 확실하지 않습니다.
업데이트 #1
SSD용 고성능 키-값 저장소를 작성하고 싶기 때문에 낮은 수준의 액세스(읽기, 쓰기, 지우기 포함)를 수행할 수 있는 방법이 필요합니다.
나는 내 방법이 커널 수준이어야 한다는 것을 알고 있지만 그 전에 (커널 수준 프로그래밍의 복잡성을 배우기 위해) 사용자 공간에서 테스트하고 싶습니다.
답변1
다음을 통해 모든 유형의 저장소에서 낮은 수준의 디스크 I/O를 수행할 수 있습니다.블록 장치, Linux의 /dev/sda
(전체 디스크의 경우) 또는 /dev/sda1
(파티션의 경우) 와 유사합니다. 이는 파일 시스템을 완전히 우회합니다.
자신만의 키-값 저장소를 구현하는 경우 전문가가 작성한 파일 시스템 및 데이터베이스보다 결과가 훨씬 느리고 버그가 많을 것이라고 확신합니다. 효율적인 저장 메커니즘은 캐싱, 동시 쓰기, 정전 복구 기능 등을 고려해야 합니다. 이는 매우 어렵습니다!
답변2
나는 사용자 프로그램이 이 수준의 I/O 최적화를 달성할 수 없다고 생각합니다(이를 수행하는 데 필요한 최적화 메커니즘은 말할 것도 없고). 따라서 내 접근 방식은 설정된 데이터 임계값이 초과되면 해당 내용을 원하는 출력으로 플러시하는 대기열과 같은 것을 구현하여 애플리케이션의 흐름을 최적화하는 것입니다. 의사 코드는 다음과 같습니다.
MAX_OBJS=100
M[100]=new M[100]
function saveObj(obj) {
if (M.size > MAX_OBJS-1) {
outputStream.appendArrayToBinary(M)
M = new M[100]
}
M.add(obj)
}
while (true) {
saveObj( new Obj )
}
보시다시피완충기개체 100개. 101번째 개체가 시도되면저장됨, 이는 또 다른 100개의 객체를 디스크에 쓰고 버퍼를 지워 또 다른 100개의 객체를 위한 공간을 만듭니다. 물론, 다른 스레드에서 쓰기를 수행하고 객체가 디스크에 기록되고 버퍼가 지워질 때까지 추가 객체가 추가되지 않도록 배열을 잠그는 등 더 복잡한 기술을 구현할 수도 있습니다. 또는 그런 것.
답변3
이미 나는지적다른 질문에서는 왜 커널 수준 접근 방식을 포기해야 합니까?
그러한 노력을 시작하기 전에 다음 사항을 명확히 해야 합니다.
"고성능"은 모든 경우에 적용되는 특성이 아닙니다.
최적화는 특정 상황에 대해 그리고 주요 병목 현상이 발견된 경우에만 수행되어야 합니다.
스스로에게 다음과 같은 질문을 던져야 합니다.
- 현재 주류 키-값 저장소 시스템 구현을 평가했습니까? 그렇지 않다면 왜 안 됩니까?
- 이렇게 하면 내 사용 사례에 맞지 않는 이유는 무엇입니까? 광범위한 벤치마킹과 테스트를 수행했습니까? 주요 병목 현상을 찾았나요? 현재의 최첨단 구현으로 이를 고칠 수 있습니까? 그렇지 않다면 왜 직접 구현하여 수정할 수 있다고 생각합니까?
- 구체적인 성능 요구 사항은 무엇입니까? "성과"를 정의하고 이를 측정하는 방법을 찾았습니까? 스토리지 작업 중 고성능을 원하시나요? 검색 작업 중 고성능을 원하십니까? 많은 수의 클라이언트 연결로 인해 높은 부하에서 고성능을 발휘합니까?
무엇인지 확실히 이해하고 나면정확히달성하려는 목표는 현재의 최첨단 소프트웨어를 거부한 후에만 잠재적인 구현 전략을 탐색하기 시작해야 합니다.
커널은 당신이 만지고 싶은 마지막 장소입니다. 특히 이전 커널 개발 경험이 없는 경우에는 더욱 그렇습니다. 대부분의 커널 하위 시스템은 고도로 숙련된 엔지니어의 수년간의 테스트 및 개발 과정을 통해 고도로 최적화되었습니다.
제가 제안하는 것은 프리포크, 스마트 캐싱, 지연된 쓰기의 조합을 통해 최적화하는 것을 고려하는 것입니다. 널리 사용되는 캐싱 알고리즘, 로드 밸런싱 방법에 대한 지식 및 최신 파일 시스템에 대한 이해(예:미리 읽어보기,정책 개발,LRU) - 이는 귀하의 문제와 직접적인 관련이 없을 수도 있지만 유사한 영역에서 사람들이 성능 문제를 해결하는 방법을 이해하는 데 도움이 됩니다. 물론, 이는 파일 시스템 자체가 이미 이러한 기능을 더 잘 구현하고 있으므로 애플리케이션에서 이러한 기능을 다시 구현하는 것이 권장된다는 의미는 아닙니다. 대부분의 경우 이는 애플리케이션 성능을 향상시키기보다는 오히려 해를 끼칠 것입니다.