CPU 증가가 한동안 디스크 속도를 능가한 것으로 보입니다. 최신 듀얼 코어 Intel / AMD CPU 및 단일 평균 SATA 디스크가있는 데스크탑 또는 랩탑을 가정 할 때 대부분의 모든 디스크에서 압축을 수행하면 전반적인 성능이 향상됩니까? 기본적으로 감소 된 디스크 대역폭은 증가 된 CPU로드를 보충하는 것보다 많은가? 나는 실제 답변이 "당신이하고있는 것에 달려있다"고 확신합니다. 이 질문을함으로써, 나는이 파이프를 만든 누군가가 예제와 함정을주기를 바라고 있습니다.
답변:
예, 디스크 압축은 특정 상황에서 더 나은 성능을 제공 할 수 있습니다.
최근 그린 필드 디자인 인 ZFS와 Btrfs 모두 압축에 대한 조항을 포함하는 이유가 있습니다.
HPC 공간에서 응용 프로그램이 메모리에서 디스크로 검사 점을 지정할 때 CPU는 종종 전혀 유용한 작업을 수행하지 않습니다. 이 시간은 본질적으로 순수한 오버 헤드입니다. 이 시간을 줄이기 위해 CPU를 사용하는 것이 승리입니다.
디스크 압축은 더 나은 성능을 제공 하지 않습니다 .
그것은 당신에게 줄 수 없다 거의 처벌을 인해 빠른 현대 CPU를, 그러나 그것은 완전히 다른 것입니다.
디스크간에 데이터를 덜 전송하면 성능을 향상시킬 수 있다고 가정합니다. 그러나 빅 데이터 전송은 거의 I / O 병목 현상이 아닙니다. 실제 병목 현상은 시간과 대기 시간을 찾는 것입니다. 최신 하드 디스크는 대용량 파일을 사용한 지속적인 데이터 전송 속도 가 매우 빠르며, 속도가 느려지는 것은 디스크 전체에서 전송되는 전송 속도가 거의 없다는 것입니다.
일부 시나리오 :
비디오 압축과 같이 이미 응용 프로그램 별 수준에서이 작업을 수행하는 특정 상황이 있습니다. dsk에서 원시 HD 품질의 비디오를 충분히 빨리 읽을 수 없었던 시스템은 대신 압축 된 정보를 읽고 메모리와 CPU 성능을 사용하여 확장 할 수 있습니다 . 이것이 다른 특정 상황에서도 해당되지 않는 이유는 없지만 사용 된 압축 방법이 목적에 맞게 최적화되어 응용 프로그램 수준에서 가장 잘 처리 될 수 있습니다.
전체 처리량이 증가하면 압축 해제의 성능 오버 헤드가 가치가 있으므로 아이디어를 놓치지 않아야합니다. 그러나 압축을 높이는 범용 성능을 아직 준비하지는 않았지만 이론적으로는 가능합니다. 다른 곳에서 부스트하기 위해 (CPU 및 메모리)를 초과하는 리소스를 교환 (하드 드라이브에서 읽은 총 데이터)
당신은 당신의 자신의 질문에 대답했습니다! 그것은 실제로 답이다.
내가 할 수있는 가장 좋은 일반화는 다음과 같습니다.
디스크 읽기가 제한된 데이터베이스 응용 프로그램이 있으면 예! 성능이 더 좋습니다.
나는 이것이 데스크탑 / 랩톱에서 수행 할 대부분의 활동의 경우라고 생각하지 않습니다.
내 도메인 (SQL Server)에서 압축을 사용하면 읽기로드가 많은 보고서 데이터베이스의 성능이 향상 될 수 있음을 알고 있습니다. mysql에서도 마찬가지입니다.
Microsoft는 SQL Server 2008 의 압축 기능에 대한 백서를 보유하고 있습니다. DBA가 아니라면 읽기는 쉽지 않지만 일반화를 지원하는 차트는 다음과 같습니다.
CPU 속도는 항상 디스크 속도보다 빠릅니다. IMHO, 압축은 오버 헤드를 증가시켜 성능을 저하시킵니다.
나는 어제 OSX와 관련하여 이와 비슷한 것을 읽었으며 파일 시스템의 압축입니다. 기본적으로 답은 압축하려는 대상을 중심으로합니다.이 예에서는 "FAT"데이터에 대해 이야기하고 있습니다. 파일 구조, 속성, 메타 데이터 등을 함께 저장하면 압축하여 공간을 절약하고 CPU로 빠르게 읽을 수있어 각 파일의 데이터를 찾기 위해 모든 곳에서 헤드를 찾는 것보다 빠릅니다.
어쨌든, 그런 것들에 대해 생각하고 있다면 읽을 가치가 있습니다 :-p
그러나 압축은 디스크 공간을 절약하는 것만이 아닙니다. 또한 I / O 대기 시간 및 대역폭 감소를위한 CPU 사이클 거래의 전형적인 예입니다. 지난 수십 년 동안 디스크 성능이 향상되는 것보다 훨씬 빠른 속도로 CPU 성능이 향상되었습니다 (그리고 나중에 컴퓨팅 리소스가 더 풍부 해짐). 최신 하드 디스크 탐색 시간과 회전 지연은 여전히 밀리 초 단위로 측정됩니다. 1 밀리 초 안에 2GHz CPU는 2 백만주기를 거칩니다. 물론 실제로 고려해야 할 실제 데이터 전송 시간이 남아 있습니다.
물론 OS 및 하드웨어 전체에 걸쳐 여러 수준의 캐싱이 이러한 지연을 숨길 수 있도록 강력하게 작동합니다. 그러나 캐시를 채우려면 어느 시점에서 해당 비트가 디스크에서 나와야합니다. 압축은 더 적은 비트가 전송되어야 함을 의미합니다. 일반적인 멀티 코어 Mac에서 거의 코믹한 CPU 리소스가 정상적으로 사용되면 디스크에서 압축 된 페이로드를 전송하고 CPU를 사용하여 내용을 메모리로 압축 해제하는 데 필요한 총 시간은 여전히 시간보다 훨씬 짧습니다. 압축되지 않은 형식으로 데이터를 전송하는 데 소요됩니다.
적은 양의 데이터를 전송하면 잠재적 인 성능 이점을 설명 할 수 있지만 확장 된 속성을 사용하여 파일 내용을 저장하면 실제로 작업 속도가 빨라질 수 있습니다. 그것은 모두 데이터 지역 성과 관련이 있습니다.
많은 양의 데이터를 전송하는 것보다 하드 디스크 속도를 늦추는 것이 있다면 헤드를 디스크의 한 부분에서 다른 부분으로 옮기는 것입니다. 움직일 때마다 헤드가 움직이기 시작한 다음 정지 한 다음 원하는 위치에 올바르게 위치했는지 확인한 다음 회전 디스크가 원하는 비트를 그 아래에 놓을 때까지 기다립니다. 이것들은 모두 실제적이고 육체적이며 움직이는 부분이며, 그들이하는 것처럼 빠르고 효율적으로 춤을 추는 것은 놀라운 일이지만 물리학에는 한계가 있습니다. 이러한 동작은 하드 디스크와 같은 회전 스토리지의 실제 성능 저하 요인입니다.
HFS + 볼륨 형식은 파일에 대한 모든 정보 (메타 데이터)를 디스크의 두 가지 기본 위치 (파일 날짜, 권한, 소유권 및 기타 호스트를 저장하는 카탈로그 파일)와 "명명 된 포크를 저장하는 속성 파일"에 저장합니다. "
HFS +의 확장 된 속성은 속성 파일에서 명명 된 포크로 구현됩니다. 그러나 파일 시스템에서 지원하는 최대 파일 크기까지 매우 큰 리소스 포크와 달리 HFS +의 확장 된 특성은 특성 파일에 "인라인"으로 저장됩니다. 실제로 이것은 속성 당 약 128 바이트의 제한을 의미합니다. 그러나 이는 또한 디스크 헤드가 실제 데이터를 얻기 위해 디스크의 다른 부분으로 이동할 필요가 없음을 의미합니다.
상상할 수 있듯이 카탈로그 및 속성 파일을 구성하는 디스크 블록은 자주 액세스되므로 대부분 어딘가에 캐시에있을 가능성이 높습니다. 이 모든 것은 B- 트리 구조화 된 카탈로그 및 속성 파일 내에서 데이터의 메타 데이터를 포함하여 파일의 전체 스토리지를 전체 성능상 승리로 만들기 위해 노력하고 있습니다. 일반 데이터 스토리지의 할당 블록 크기보다 작고 속성 파일의 B- 트리 노드 내에있는 한 25 바이트로 확장되는 8 바이트 페이로드도 문제가되지 않습니다. OS는 어쨌든 전체를 읽어야합니다.
Snow Leopard의 디스크 설치 공간 감소 (예 : 불필요한 지역화 및 "designable.nib"파일 제거)에 대한 다른 중요한 기여가 있지만 HFS + 압축은 기술적으로 가장 흥미 롭습니다.
보낸 사람 : http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/3
Microsoft 디스크 압축이 오래되었습니다. 80 년대 ARJ 방법과 비교할 수없는 수준입니다. 그러나 Microsoft의 압축 CAN조차도 매우 느린 (노트북) 하드 드라이브에서 더 나은 성능을 제공합니다. 특히 쓰기 캐싱을위한 충분한 RAM이 있고 과도한 쓰기를 방지하는 경우.
쓰기 프로세스는 임의 액세스 가능 압축 방법의 약점입니다.
따라서 압축 드라이브를 원한다면 어떤 종류의 Linux로 옮기는 것이 좋습니다.
디스크 압축은 RAM 드라이브에도 매우 적합하므로 이유를 알 필요가 없습니다.
의심 할 여지없이. 압축 및 압축 해제에는 디스크와 CPU 이상의 것이 포함됩니다. 특히 페이지 폴트 측면에서 실제로 상처를 줄 수있는 메모리로 (및 압축하지 않은 표준 전송 오버 헤드와 함께) 데이터를 많이 전송합니다.