홈페이지 » 어떻게 » 더 나은 성능을 위해 Ubuntu에서 SSD를 조정하는 방법

    더 나은 성능을 위해 Ubuntu에서 SSD를 조정하는 방법

    Linux에서 SSD를 조정할 수있는 많은 팁과 작동 및 작동하지 않는 것에 대한 일화적인 보고서가 많이 있습니다. 실제 차이점을 보여주기 위해 몇 가지 구체적인 조정을 통해 자체 벤치 마크를 실행했습니다..

    벤치 마크

    디스크를 벤치마킹하기 위해 Phoronix Test Suite를 사용했습니다. 무료이며 우분투 용 저장소가 있으므로 빠른 테스트를 실행하기 위해 처음부터 컴파일 할 필요가 없습니다. ext4 파일 시스템의 기본 매개 변수를 사용하여 Ubuntu Natty 64 비트를 새로 설치 한 직후에 시스템을 테스트했습니다.

    우리의 시스템 사양은 다음과 같습니다.

    • AMD Phenom II 쿼드 코어 @ 3.2GHz
    • MSI 760GM E51 마더 보드
    • 3.5GB RAM
    • AMD Radeon 3000 통합형 512MB RAM
    • 우분투 낫티

    물론 테스트에 사용 된 SSD는 64GB OCZ Onyx 드라이브 (작성 당시 Amazon.com의 117 달러)였습니다..

    눈에 띄는 개조

    SSD로 업그레이드 할 때 사람들이 권장하는 몇 가지 변경 사항이 있습니다. 일부 오래된 항목을 걸러 낸 후 Linux 배포판이 SSD의 기본값으로 포함시키지 않은 간단한 조정 목록을 만들었습니다. 그 중 세 가지는 fstab 파일을 편집하는 것이므로 다음 명령을 계속하기 전에 다시 작성하십시오.

    sudo cp / etc / fstab /etc/fstab.bak

    문제가 발생하면 새 fstab 파일을 삭제하고 백업 복사본으로 대체 할 수 있습니다. 그것이 무엇인지 알지 못하거나 어떻게 작동 하는지를 모르는 경우 HTG Explains : Linux fstab이란 무엇이며 어떻게 작동합니까??

    액세스 시간 철회

    OS가 디스크에 기록하는 양을 줄임으로써 SSD의 수명을 늘릴 수 있습니다. 각 파일이나 디렉토리가 마지막으로 액세스 된시기를 알아야 할 경우 / etc / fstab 파일에 다음 두 옵션을 추가 할 수 있습니다.

    노아 타임, 노디 라임

    다른 옵션과 함께 추가하고 쉼표로 구분하고 공백없이 구분하십시오..

    트림 사용

    TRIM을 사용하여 장기적으로 디스크 성능을 관리 할 수 ​​있습니다. fstab 파일에 다음 옵션을 추가하십시오.

    포기

    이것은 표준 하드 드라이브에서도 ext4 파일 시스템에서 잘 작동합니다. 2.6.33 이상의 커널 버전이 있어야합니다. Maverick 또는 Natty를 사용 중이거나 Lucid에서 백 포트가 활성화 된 경우에는 보상이 적용됩니다. 이것이 초기 벤치마킹을 특별히 개선하지는 않지만 장기 실행면에서 시스템 성능을 향상시켜야하므로 우리의 목록을 만들었습니다.

    Tmpfs

    시스템 캐시는 / tmp에 저장됩니다. fstab에 RAM에 임시 파일 시스템으로 마운트하여 시스템이 하드 드라이브를 덜 만지도록 지시 할 수 있습니다. / etc / fstab 파일 맨 아래에 다음 행을 새 행에 추가하십시오.

    tmpfs / tmp tmpfs 기본값, noatime, 모드 = 1777 0 0

    이 변경 사항을 적용하려면 fstab 파일을 저장하십시오..

    IO 스케줄러 전환

    시스템은 모든 변경 사항을 즉시 디스크에 기록하지 않으며 여러 요청이 대기열에 들어갑니다. 기본 입출력 스케줄러 - cfq -이 작업을 처리하지만 하드웨어에서 더 잘 작동하는 것으로 변경할 수 있습니다.

    먼저 "X"를 루트 드라이브의 문자로 바꾸고 다음 명령으로 어떤 옵션을 사용할 수 있는지 나열하십시오.

    cat / sys / block / sdX / queue / scheduler

    제 설치가 sda에 있습니다. 몇 가지 옵션이 표시됩니다..

    마감 시간이있는 경우이를 사용해야합니다. 추가 줄을 추가로 조정할 수 있습니다. 그렇지 않다면 아무 문제없이 문제없이 사용할 수 있어야합니다. 부팅 할 때마다이 옵션을 사용하도록 운영 체제에 알려야하므로 rc.local 파일을 편집해야합니다..

    우리는 명령 행에 익숙하기 때문에 nano를 사용할 것이지만 원하는 다른 텍스트 편집기 (gedit, vim 등)를 사용할 수 있습니다..

    sudo nano /etc/rc.local

    마감 시간을 사용하는 경우 '이탈 0'행 위에 다음 두 줄을 추가하십시오.

    echo deadline> / sys / block / sdX / queue / scheduler

    echo 1> / sys / block / sdX / queue / iosched / fifo_batch

    noop을 사용하는 경우 다음 행을 추가하십시오.

    echo noop> / sys / block / sdX / queue / scheduler

    다시 한 번 "X"를 설치에 적합한 드라이브 문자로 바꿉니다. 보기에 모든 것이 잘 보이는지 확인하십시오..

    그런 다음 CTRL + O를 눌러 저장하고 CTRL + X를 눌러 종료하십시오..

    재시작

    이러한 모든 변경 사항이 적용 되려면 다시 시작해야합니다. 그 후, 당신은 모든 설정을해야합니다. 무언가 잘못되어 부팅 할 수없는 경우, 다시 부팅 할 때까지 위의 각 단계를 체계적으로 실행 취소 할 수 있습니다. 원하는 경우 LiveCD 또는 LiveUSB를 사용하여 복구 할 수도 있습니다..

    fstab 변경은 업그레이드를 견지하더라도 설치 수명이 다할 수 있지만 rc.local 변경은 모든 업그레이드 (버전 간) 후에 다시 시작되어야합니다..

    벤치마킹 결과

    벤치 마크를 수행하기 위해 테스트 세트를 실행했습니다. 각 테스트의 상단 이미지는 ext4 구성을 조정하기 전의 이미지이며 하단 이미지는 비틀기 및 재부팅 후의 것입니다. 테스트가 측정 한 내용과 결과 해석에 대한 간략한 설명을 볼 수 있습니다..

    대용량 파일 작업

    이 테스트는 임의의 데이터로 2GB 파일을 압축하여 디스크에 씁니다. 여기서 SSD를 조정하면 약 40 % 향상됩니다..

    IOzone은 파일 시스템 성능을 시뮬레이트합니다.이 경우 8GB 파일을 작성합니다. 다시 말하지만 거의 50 % 증가했습니다..

    여기서 8GB 파일을 읽습니다. ext4를 조정하지 않고도 결과는 거의 동일합니다..

    AIO-Stress는 2GB 테스트 파일과 64KB 레코드 크기를 사용하여 입력 및 출력을 비동기 적으로 테스트합니다. 여기, 바닐라 ext4에 비해 성능이 거의 200 % 향상되었습니다.!

    작은 파일 작업

    SQLite 데이터베이스가 생성되고 PTS가 12,500 개의 레코드를 추가합니다. 여기서 SSD를 조정하면 실제로 성능이 약 10 %.

    Apache Benchmark는 작은 파일의 무작위 읽기를 테스트합니다. SSD 최적화 후 약 25 %의 성능 향상이있었습니다..

    PostMark는 25,000 건의 파일 트랜잭션을 시뮬레이트합니다. 파일 크기는 5 ~ 512KB입니다. 웹 서버와 메일 서버를 거의 비슷하게 시뮬레이트하면 조정 후 16 %의 성능 향상을 볼 수 있습니다..

    FS-Mark는 총 크기가 1MB 인 1000 개의 파일을보고 미리 지정된 시간 내에 얼마나 많은 파일을 읽고 쓸 수 있는지 측정합니다. 우리의 비틀기는 파일 크기가 작아짐에 따라 증가합니다. ext4 조정으로 약 45 % 증가.

    파일 시스템 액세스

    Dbench 벤치 마크는 클라이언트가 파일 시스템 호출을 테스트합니다. Samba가 일을 수행하는 것과 같습니다. 바닐라 ext4의 성능이 75 % 나 낮아졌습니다. 우리가 만든 변경 사항에서 큰 걸림돌입니다..

    클라이언트의 수가 증가하면 성능 불일치가 증가한다는 것을 알 수 있습니다..

    48 명의 고객이 있었기 때문에 그 차이는 다소 두 가지로 좁혀졌지만, 우리의 개조로 인해 여전히 명백한 성능 손실이있었습니다.

    128 클라이언트의 성능은 거의 동일합니다. 이러한 조정 작업을 통해 가정에서 사용하기에 이상적 일 수는 없지만 고객 수가 대폭 증가한 경우 비교할 수있는 성능을 제공합니다..

    이 테스트는 커널의 AIO 액세스 라이브러리에 따라 다릅니다. 우리는 여기서 20 %의 개선점을 얻었습니다..

    여기에 64MB의 멀티 스레드 랜덤 읽기가 있으며 여기에 성능이 200 % 향상되었습니다! 와우!

    32 스레드의 64MB 데이터를 작성하는 동안 성능은 여전히 ​​75 % 향상되었습니다..

    Compile Bench는 커널 트리 조작 (생성, 컴파일, 패칭 등)으로 표현되는 파일 시스템에서의 나이 효과를 시뮬레이션합니다. 여기서 시뮬레이션 된 커널의 초기 생성을 통해 상당한 이점을 볼 수 있습니다. 약 40 %.

    이 벤치 마크는 Linux 커널을 추출하는 데 걸리는 시간을 단순히 측정합니다. 성능 향상이 그리 크지는 않습니다..

    개요

    우분투의 out-of-the-box ext4 설정에 대한 우리의 조정은 상당한 영향을 미쳤습니다. 가장 큰 성능 향상은 멀티 스레드 쓰기 및 읽기, 작은 파일 읽기 및 연속적인 파일 읽기 및 쓰기의 영역에서 발생했습니다. 사실, 우리가 성능에서 큰 타격을 입은 유일한 장소는 단순한 파일 시스템 호출이었습니다. 삼바 사용자가주의해야 할 것이 있습니다. 전반적으로 웹 페이지 호스팅 및 큰 동영상 시청 / 스트리밍과 같은 작업의 실적이 상당히 견고한 것으로 보입니다..

    이것은 Ubuntu Natty 64 비트와 특별히 관련이 있음을 명심하십시오. 시스템 또는 SSD가 다른 경우 마일리지가 다를 수 있습니다. 전반적으로, 우리가 만든 fstab 및 IO 스케줄러 조정은 더 나은 성능을 내기 위해 먼 길을가는 것처럼 보이므로, 자신의 장비에서 시도해 볼만한 가치가있을 것입니다.

    자신의 벤치 마크를 가지고 결과를 공유하고 싶습니까? 우리가 모르는 또 하나의 비틀기가 있습니까? 의견에서 소리가납니다.!