☰

문제

tag-icon • tag-icon encryption luks
문제

문제

저는 최근 i7-6820HQ, 32GB RAM, 512GB Micron 1100 SSD를 갖춘 Lenovo T460p에 Ubuntu 16.04 LTS(커널 4.8.0-52)를 설치했습니다. 설치 중에 전체 디스크 암호화 상자를 선택하고 기본 파티셔닝 레이아웃을 사용했습니다. 전반적으로 성능은 훌륭합니다.

하지만, 시간이 지남에 따라 빌드 실행 시간이 약 두 배나 오래 걸리기 시작했습니다. 또한 대용량 파일을 작성하는 빌드 부분에서는 디스크 I/O가 필요한 모든(비빌드) 작업이 결국 많이 대기하게 됩니다. 여기에는 새 프로그램 실행, Firefox에서 페이지 로드 등이 포함됩니다. 예를 들어 Firefox에서는 UI를 탐색하고 탭을 전환할 수 있으며 모든 것이 정상입니다. 하지만 링크를 따라가면 상황이 조용해질 때까지 전체 UI가 잠깁니다.

요약하자면, 일정 기간이 지나면 빌드 시간이 갑자기 길어지고 빌드 중 특정 지점에서는 컴퓨터를 기본적으로 사용할 수 없게 됩니다.

이 문제를 진단하거나 해결하려면 어떻게 해야 합니까?

문제 해결 정보

  • 자주 재부팅하지 마십시오. 이 문제가 발생하기 전에 시스템이 며칠 동안 작동하는 경우가 많습니다. 일단 문제가 발생하면 문제를 파악하기 위해 잠시 고민한 다음 재부팅하여 계속 작업할 수 있습니다.

  • 문제를 해결하는 유일한 방법은 컴퓨터를 재부팅하는 것입니다. 모든 응용 프로그램을 종료하고, 로그아웃했다가 다시 로그인하고, 버퍼 캐시를 삭제해 보았지만(메모리 공간을 사용할 때 디스크 동기화가 더 자주 발생한다는 허위 이론) 재부팅만 작동합니다.

  • 장기적으로 나는 해결책을 시도했습니다.이 답변그러나 행동에는 변화가 없었습니다.

  • 실행하면 문제가 발생할 때마다 스레드가 99% I/O를 사용하는 것으로 iotop표시됩니다 . dmcrypt_write내가 ~ 할 때~ 아니다문제가 발생하면 dmcrypt_write상대적으로 높은 IO %로 맨 위로 팝업되는 것을 볼 수 있지만 오래 머물지는 않습니다.

  • dd if=/dev/urandom of=$HOME/bigfile bs=10k count=200k; sync정상적으로 작동할 때 실행하면 dmcrypt_write1~2초 동안 맨 위로 점프하지만 내 빌드 중 하나와 같은 지속 시간은 거의 없습니다.

  • 전체 빌드는 약 1.4GB의 데이터를 생성합니다. 여러 모듈이 포함된 Java 프로젝트입니다. 따라서 많은 작은 파일과 모든 작은 파일을 집계하는 더 큰 JAR 파일이 생성됩니다.

  • 사용 가능한 메모리는 항상 충분하며 스왑 파티션은 사용되지 않습니다.

  • 이 문제가 발생하지 않는 Ubuntu를 실행하는 유사한 컴퓨터(T460p)를 사용하는 동료가 있습니다. 그들 모두는 그런 것 같아요다른그러나 SSD 브랜드/모델.

업데이트

문제가 다시 나타났기 때문에 이 질문에 대한 답변을 바탕으로 몇 가지 테스트를 더 수행했습니다.

  • 파일 시스템이 여전히 옵션으로 마운트되지 않았 discard으므로 대신 옵션을 활성화 fstrim한 것과 다소 유사하다고 가정하여 실행했습니다.discard
  • 처음 문제가 발생했을 때 타이밍을 충분히 맞추지 못했는데, 실행 후 fstrim빌드 속도가 정상으로 돌아온 것 같았는데...하지만빌드가 완료된 후 dmcrypt_write스레드가 시작되어 일정 기간 동안 시스템을 사용할 수 없게 됩니다. 구축하고 시스템을 사용할 수 있게 되기까지의 총 시간은 모두 이전과 거의 같은 것 같습니다.
  • 나는 /proc/sys/vm/dirty_ratio2와 /proc/sys/vm/dirty_background_ratio1로 변경하고 일부 빌드를 실행했습니다. 빌드하는 데 평소보다 시간이 더 걸렸습니다. 지난 번 이 문제가 발생했을 때와 거의 같았지만 시스템이 많이 잠기지 않은 것 같습니다. 20과 10으로 다시 변경하면 위에서 언급한 동작으로 되돌아갑니다.
  • /proc/sys/vm/dirty_ratio클린부팅에서 2와 1로 설정을 해보았 /proc/sys/vm/dirty_background_ratio는데 시간은 20과 10으로 비슷했습니다.

답변1

Debian 10+11에서도 비슷한 문제가 있었습니다. LUKS 디스크에서 대규모 쓰기 작업을 수행하면 전체 시스템이 한동안 멈췄다가 다시 응답했다가 다시 멈췄습니다...

하지만 재부팅할 필요는 없었습니다. 쓰기 작업이 완료될 때까지 기다리기만 하면 됩니다.

ScumCoder가 쓴 것처럼 사용 가능한 수정 사항이 있습니다. 커널 5.9부터 수정 사항이 커널에 통합되었습니다.

다음 명령으로 문제가 해결되었습니다.

cryptsetup --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh nvme0n1p3_crypt

다음 명령을 사용하여 디스크 이름 "nvme0n1p3_crypt"를 추출했습니다.dmsetup table

에서 영감을 얻었어요https://wiki.archlinux.org/title/Dm-crypt/Specialties#Disable_workqueue_for_increased_solid_state_drive_(SSD)_performance

수정 후 쓰기 작업이 훨씬 빨라졌습니다.

답변2

나는 당신과 똑같은 문제를 가지고 있으며, 빠른 조사 결과 다음 게시물이 나타났습니다.

https://blog.cloudflare.com/speeding-up-linux-disk-encryption

CloudFlare 직원은 Linux 소스 코드를 꽤 많이 조사한 결과 현재 구현이 범인이라는 결론을 내렸습니다 dmcrypt. 그는 기본적으로 커널의 해당 부분을 다시 작성하여 문제를 해결했습니다.

따라서 AFAIK에서 속도 저하를 제거하는 유일한 두 가지 방법은 (1) 자신의 커널 버전을 컴파일하거나 (2) (말씀하신 대로) 가끔씩 재부팅하는 것입니다. 나는 후자를 선택했다.

답변3

특히 LUKS에 대해서는 모르지만 SSD의 일반적인 IO 문제의 경우 fs 마운트에 대해 폐기가 켜져 있는지 확인하십시오. 즉, grep 폐기 /proc/mounts도 (루트로) "echo 1 >> /proc/sys/를 시도할 수 있습니다. vm/dirty_ground_ratio; echo 2 >> /proc/sys/vm/dirty_ratio", 기록할 데이터의 백 로그가 적을 때 시스템이 IO를 더 빨리 시작하게 합니다.

관련 정보