LVM이 성능에 영향을 미치나요?

LVM은 실제로 큰 혼란을 일으키지 않도록 설계되었습니다. 사용자 공간 관점에서 이는 디스크 상단에 있는 또 다른 "가상 항목" 레이어처럼 보이며 이제 모든 I/O가 실제 I/O 하드웨어에 도달하거나 실제 I/O 하드웨어에서 나오려면 이를 통과해야 한다고 상상하는 것이 당연합니다.

그러나 그것은 진실이 아니다. 핵심이미상위 수준 작업(예: "파일에 쓰기")을 장치 드라이버에 연결하고, 다시 디스크의 실제 블록에 연결하는 매핑(또는 실제로 여러 계층의 매핑)이 필요합니다.

이 조회는 LVM을 사용할 때 변경되지만 그게 전부입니다. (어쨌든 일어나야 하는 일이기 때문에 조금만 변경해도 성능에는 미미한 영향을 미칩니다.)파일이 실제로 작성되면 이러한 비트는 다른 경우와 마찬가지로 실제 미디어에 대한 경로를 직접 사용합니다.

어떤 경우에는 LVM이 성능 문제를 일으킬 수 있습니다. LVM 블록이 기본 시스템과 올바르게 정렬되어 있는지 확인해야 합니다. 이는 최신 배포판에서 자동으로 발생합니다. 다음 버그가 있는 이전 커널을 사용하고 있지 않은지 확인하세요.이것. 아, 그리고 LVM 스냅샷을 사용하면 성능이 저하됩니다(각 활성 스냅샷마다 성능이 점점 더 나빠집니다). 그러나 대부분의 경우 영향은 최소화되어야 합니다.

마지막 질문은 어떻게 테스트하나요? 표준 디스크 벤치마크 도구는 다음과 같습니다.보니++. LVM을 사용하여 파티션을 생성하고 테스트하고 삭제한 다음 (다른 요소를 동일하게 유지하면서 동일한 위치에서) 일반 파일 시스템을 생성하고 다시 벤치마킹합니다. 그것들은 거의 동일해야 합니다.

LVM은 다른 것과 마찬가지로 좋은 면과 나쁜 면이 있습니다.

LVM은 비트 적중(또는 디스크에서 읽을 수 있음) 전에 해결해야 하는 또 다른 추상화 계층이기 때문에 성능 측면에서 약간 방해가 됩니다. 대부분의 경우 이러한 성능 영향은 사실상 측정할 수 없습니다.

LVM의 장점은 데이터를 이동하지 않고도 기존 파일 시스템에 더 많은 스토리지를 추가할 수 있다는 것입니다. 대부분의 사람들은 이러한 장점 때문에 그것을 좋아합니다.

이러한 방식으로 LVM을 사용할 때의 한 가지 단점은 추가 저장소가 디스크에 걸쳐 있는 경우(즉, 여러 디스크가 포함된 경우) 디스크 오류로 인해 데이터가 손실될 가능성이 높다는 것입니다. 파일 시스템이 두 개의 디스크에 걸쳐 있고 둘 중 하나가 실패하면 손실될 수 있습니다. 대부분의 사람들에게 이는 공간 대 비용상의 이유로 허용 가능한 위험입니다(즉, 정말 중요한 경우 이를 제대로 수행할 예산이 있음). 그리고 그들이 말했듯이 백업예좋아요, 그렇죠?

제가 보기에 LVM을 사용하지 않는 유일한 이유는 재해 복구가 명확하게 정의되지 않았거나 적어도 정의되지 않았기 때문입니다. LVM 볼륨이 있고 복잡한 운영 체제가 있는 디스크는 다른 컴퓨터에 쉽게 연결하고 복구할 수 없습니다. LVM 볼륨을 복구하기 위한 많은 지침에는 다음 단계가 포함됩니다.과거로 돌아가서 vgcfgbackup을 실행한 다음 결과 /etc/lvmconf 파일을 호스 볼륨을 호스팅하는 시스템에 복사합니다.. 이 질문을 마지막으로 검토한 이후 3~4년 동안 상황이 바뀌었기를 바라지만 개인적으로는 이러한 이유로 LVM을 사용한 적이 없습니다.

그것이 말하는 것입니다.

귀하의 경우 가상 머신은 호스트 시스템에 비해 상대적으로 작은 것 같습니다. 나에게 이것은 나중에 VM에서 스토리지를 확장하고 싶을 가능성이 더 높다는 것을 의미합니다. 가장 좋은 방법은 VM에 다른 가상 디스크를 추가한 다음 영향을 받는 VM 파일 시스템을 확장하는 것입니다. 가상 디스크는 호스트 시스템의 동일한 물리적 장치에 있을 가능성이 높기 때문에 여러 디스크에 걸쳐 있는 취약점이 없습니다.

가상 머신이 중요한 경우 어떤 방식으로든 호스트 시스템을 RAID로 설정하므로 나중에 스토리지를 추가할 수 있는 유연성이 줄어듭니다. 따라서 LVM의 유연성이 필요하지 않을 수 있습니다.

따라서 호스트 시스템에서 LVM을 사용하지 않고 LVM을 사용하기 위해 VM을 설치할 것이라고 가정합니다.

일반적으로 새로운 복잡성 계층을 추가하면(일명 "할 일이 더 많아짐") 속도가 빨라지지 않습니다. 참고: 작업을 추가하는 것만 가능하며 작업 수행 방법을 "변경"할 수는 없습니다.

어떻게 측정하나요? LVM이 있는 파티션과 LVM이 없는 파티션을 만든 다음 일반 벤치마크를 사용하여 실행합니다. 사람들이 그렇듯

http://www.umiacs.umd.edu/~toaster/lvm-testing/

속도에는 약간의 영향만 미치는 것으로 보입니다. 이는 벤치마크를 실행하는 다른 사람들의 결과와 일치하는 것으로 보입니다.

"Ext4는 LVM이 없을 때보다 LVM이 있을 때 더 빠르며 다른 파일 시스템 벤치마크에서도 더 빠릅니다." Linux 커널 메일링 목록 스레드

그러나 사용하려는 하드웨어와 운영 체제가 동일하게 작동하는지 확인하고 탄력적인 스토리지를 제공하는 추가 복잡성 계층의 영향을 (아마도 약간) 무시할 수 있는지 확인하려면 직접 벤치마킹해야 합니다.

게스트 OS에 LVM을 추가해야 할까요? 이는 게스트 OS에도 탄력적인 스토리지가 필요한지 여부에 따라 다릅니다. 그렇지 않습니까? 요구 사항에 따라 배포해야 할 항목이 결정됩니다.

lvm2가 읽기 및 쓰기 속도를 두 배로 늘릴 수 있다고 언급한 사람은 아무도 없습니다(raid0과 유사). 저는 개인적으로 스트립 모드에서 lvm2를 사용하여 3개의 동일한 디스크를 사용합니다. 읽기 및 쓰기 작업에 1/3의 시간이 걸리므로 영향이 엄청나고 파일 시스템이 3배 더 빠릅니다. 나는 알고 있습니다. 디스크에 오류가 발생하면 그 안에 있는 모든 데이터에 액세스할 수 없습니다. 하지만 그렇다고 해서 아무것도 손실되지는 않습니다. 왜냐하면 백업이 필수이고 Raid, LVM2, ZFS와 같은 것들은 백업을 피하지 않기 때문입니다. 미러링, raid5 등을 사용하는 경우에는 항상 스트리핑(최고의 성능을 위해) 및 동기화 백업을 사용합니다. ZFS는 즉석 압축에 적합하고 미러링과 마찬가지로 1보다 큰 복사 매개변수를 사용하지만 ZFS에는 있지만 다른 ZFS에는 없는 한 가지 기능은 비트 부패(변경되는 비트)의 즉석 자동 복구입니다. 디스크가 다운된 동안 자발적으로 발생), ZFS i는 매우 큰 영향(체크섬 계산, 유효성 검사)과 주요 문제(더 많은 물리적 디스크 추가)를 가졌습니다.

복구: 저는 외부 디스크 백업, 여러 개의(2~3개) SSD 및 OS용 lvm2 스트라이핑에만 ZFS를 사용합니다. (업그레이드 후 OS 복제를 다시 실행합니다.) 불변 OS를 사용하는 경향이 있습니다. 가상 머신과 같이 lvm2에서 데이터가 제거된 여러 개의 회전 디스크가 있고 변경 후 백업을 다시 실행하므로 디스크 오류가 발생한 후에는 교체하면 됩니다. 이제 마지막 백업을 복원합니다. 이제 쓰기 속도가 가까워졌습니다. 최대 1.8GiB/s로 백업에서 VM을 복원하는 데 30초 미만이 소요됩니다(VM 디스크당 32GiB).

따라서 내 대답은 다음과 같습니다. 한 가지만 사용하지 말고 현명하게 모든 부분을 최대한 활용하십시오. lvm2 스트립은 mdraid 레벨 0보다 빠르며 6개의 회전 디스크를 사용할 때 더 빠릅니다. SSD를 스트리핑할 때 한 가지 주의 사항은 두 개와 세 개입니다. 좋아, 4개의 SSD는 성능을 저하시킬 것입니다(내 테스트에서는 lvm, mdraid0 등의 동일한 SSD 4개를 스트립 모드에서 사용할 때 쓰기 속도가 더 느려졌습니다). SSD TRIM과 같은 쓰기 증폭이 아마도 성능 저하의 주된 이유인 것 같습니다. 제거된 볼륨에 더 많은 SSD를 추가하면 쓰기 속도가 느려집니다.

SSD 및 raid0(제거된 볼륨)에 대한 경고, 완벽하게 정렬, 클러스터 크기, stip 크기 등을 파일 시스템에 올바르게 할당하여 예를 들어 성능 저하를 일으키지 않도록 합니다. 디스크 섹터는 2048이므로 읽기/쓰기가 가능합니다. 최소값은 2K이며, 512바이트를 사용하는 파일 시스템을 사용하지 마십시오. 2K 또는 4K 클러스터 크기를 사용하는 것이 더 좋습니다. 이제 3xHDD, 2K 섹터를 각각 사용한다고 가정하므로 읽기/쓰기 최적화된 파일 시스템에서 클러스터는 다음과 같습니다. 3x2K=6K이지만 이는 많은 파일 시스템에서 가능하지 않습니다. 그런 다음 64K 클러스터 크기, 64K/6K=32/3을 사용하면 어떤 일이 발생하는지 생각해 보십시오. 이로 인해 불균형이 발생하여 최적이 아닙니다. 최적의 클러스터 크기를 얻으려면 수학을 수행하십시오.

가장 좋은 결과는 다음과 같습니다. 클러스터 크기 = 스트라이프 크기 * 스트라이프의 디스크 수 이렇게 하면 각 읽기/쓰기의 크기가 모든 디스크가 작동할 수 있을 만큼 충분하므로 속도가 크게 향상됩니다. 3개 디스크에 대한 192K 클러스터 크기 및 64K 스트라이프 크기의 예. 6개 디스크에 대한 192K 클러스터 크기 및 32K 스트라이프 크기의 또 다른 예입니다.

그리고 항상 4K, 8K, 16K, 32K, 64K 블록에서 개별 디스크를 테스트해야 한다는 것을 기억하십시오. 많은 디스크는 4K와 같은 낮은 숫자에서는 매우 열악하지만 64K, 128K 이상에서는 10배 이상 빠릅니다.

예, 큰 클러스터 크기를 사용하면 각 파일에 대한 las 클러스터 공간이 낭비될 수 있습니다(수백만 개의 파일을 사용하는 경우 파일당 1바이트만). 파일 시스템 동적 시스템에서 컴팩트/패키지를 사용하는 것이 좋습니다. 예를 들어, 4K 클러스터 크기의 4TiB 디스크는 각각 1Byte의 4TiB/4K=1073741824개 미만의 파일만 포함할 수 있습니다. 이는 모든 파일 크기가 1Byte(클러스터 크기 4K)인 경우 1GiB에 불과하며, 더 크면 클러스터 크기에 대한 최악의 비율입니다. 파일이 가상 머신(예: 32GiB에 가까우거나 몇 메가바이트에 불과)처럼 크면 이러한 큰 파일의 경우 마지막 클러스터에서만 손실이 발생하므로 큰 클러스터 크기가 성능 측면에서 훨씬 좋습니다. 하지만 VM이 이를 어떻게 사용하는지 알고 있어야 합니다.

아무도 이 비밀을 알려주지 않습니다. 게스트 내부에서 4K 클러스터 크기를 사용하지 말고, 가상 디스크가 있는 클러스터 크기와 동일하거나 그 배수인 클러스터 크기를 사용하십시오.

예, 저는 게스트 디스크에서 최대 속도를 얻고 싶습니다. 6개의 회전 디스크를 사용하면 1.7GiB/s에 가까워지고 있다고 말했듯이 SATA III 버스 속도는 디스크 자체가 아니라 병목 현상입니다. 저는 저렴하지 않은 고급 디스크, 128MiB 캐시를 사용하고 있으며 각 쓰기 속도는 283MiB/s입니다.

귀하와 모든 사람을 위해: 속도 테스트를 수행하기 전에 클러스터 크기, 스트라이프 크기 및 블록 크기 간의 관계를 이해하는 것이 좋습니다. 그렇지 않으면 LVM2 또는 다른 RAID(또는 ZFS) 테스트가 잘못된 결론을 내릴 수 있습니다.

예를 들면 다음과 같습니다. Sata II 포트 마더보드에서 2x60MiB/s 2.5인치 5400rpm Sata 디스크를 사용한 다음 2xSSD Sata III(Sata III에 연결된 경우 각각 250MiB/s 이상 쓰기 가능) 포트를 사용하여 Linux 부팅 시간을 테스트했습니다. 시동 시간은 단 2초 단축되었으며, 5분 시동 시간은 단 2초밖에 걸리지 않습니다. 대부분의 부팅 중에는 디스크가 사용되지 않기 때문에 I/O가 아닌 RAM 및 CPU에 대한 작업을 수행합니다.

대략적인 속도(즉, 최대 속도)뿐만 아니라 항상 수행하려는 실제 작업을 테스트하십시오.

최대 속도는 좋습니다. 대표적인 것이 아니라는 점을 알아두세요. 디스크를 항상 최대 속도로 사용할 수는 없으며 OS와 애플리케이션은 I/O 없이 RAM 및 CPU에서 작업을 수행해야 하므로 디스크 속도가 그렇지 않을 때 전혀 상관없어요.

모두가 SSD가 Windows 부팅 속도를 크게 향상시킨다고 말하는데, 제가 테스트한 결과 이 ​​역시 잘못된 것으로 나타났습니다. 부팅 시간은 거의 8분에 불과하고 28초에 불과한 것으로 나타났습니다.

따라서 당신이 정말로 나와 같다면: Linux는 부팅 시 RAM에 복사하고 SSD는 회전하는 HDD보다 나을 것이 없습니다. 또한 USB 3.1 Gen2 스틱(139MiB/s 읽기)을 테스트했는데 부팅 시간은 몇 초만 영향을 받았습니다. 부팅하는 데 5분 정도 걸립니다. 왜 그럴까요? 간단합니다. RAM에 복사하는 동안 읽기가 수행됩니다. 그 후 볼트의 나머지 부분은 더 이상 디스크/SSD/USB 스틱을 사용하지 않으며 데이터는 RAM 드라이브처럼 RAM에 있습니다.

이제 나는 내가 소유한 모든 SSD를 판매하고 있으며 부팅 시 Linux의 RAM 복사를 개선하지 않지만 벤치마킹을 통해 5배 더 빠른 것으로 나타났습니다... 참조, 벤치마크는 잘못된 결론을 제공합니다.. 예, 테스트하고 실제 테스트합니다. 일용직 노동자.

이를 통해 상황이 명확해지기를 바랍니다. 클러스터 및 스트라이프 크기가 ​​잘못된 LVM의 영향은 계층의 오버헤드보다 훨씬 큽니다.