루트 디스크(SanDisk SSD PLUS 240GB(UF5000RL))에 높은 IO가 있을 때 Fedora 38(Wayland의 KDE)이 몇 초 동안 응답하지 않는 이유를 이해하려고 합니다.
루트 파티션은 LUKS의 Btrfs입니다(자세한 내용은 질문 끝에 제공됨).
이러한 경우 장치에 할당된 IO 스케줄러가 BFQ(Fedora의 SATA SSD에 대한 기본 스케줄러)임에도 불구하고 추가 IO 활동이 오랫동안 처리되지 않는 것으로 보입니다. 일부 애플리케이션(예: Firefox)은 IO를 시도하면 충돌이 발생합니다(일부 하위 프로세스가 응답하지 않는 경우 감시 기능이 있을 수 있음).
이 문제는 컴퓨터를 시작한 후 데스크탑에 로그인하고 패널, 위젯, 일부 시스템 트레이 응용 프로그램과 같은 컨텐츠 로드를 시작할 때 발생할 수 있습니다.
최악의 시나리오는 특히 Steam이 Diablo 4와 같은 대규모 게임(스토리지 측면에서)을 업데이트하려고 할 때입니다. 실제로 Steam은 변경된 델타만 다운로드하고 새 파일을 "다운로드" 디렉터리에 결합하는 것 같습니다.
이제 일반적으로 게임과 동일한 디스크에서 이 작업을 수행하지만 제 경우에는 디스크 공간이 충분하지 않아(~60GB가 더 필요함) Steam이 이 새 파일을 내 루트 디스크에 쓰기로 결정했습니다.
iostat 1
35MB/s에서 130MB/s까지의 쓰기 버스트 표시 중...
온라인으로 조사한 후 이 blktrace
도구를 발견하여 Steam에 또 다른 Diablo 4 패치가 도착했을 때 IO 활동을 몇 초 동안 추적할 수 있었습니다. 다음은 구문 분석된 추적입니다 blkparse
(개인 데이터가 포함되어서는 안 됨).https://gist.github.com/tesfabpel/eb7d0f0f6cf64aa666e3e387bb771a21
Queue2Device, Device2Completion 및 Queue2Completion(아래 및 요약)을 btt
나타내는 3개의 플롯을 생성하는 데 필요한 데이터를 성공적으로 수집 했습니다 .matplotlib
내 SSD에 문제가 있는지 알아내려고 노력 중입니다. (결함일까요? D2C 시간이 가장 높았지만 아마도 정상일 것입니다... 확장된 SMART 자체 테스트를 실행했지만 잘못된 점을 찾지 못했습니다. ) 또는 LUKS /btrfs의 일부 구성 오류...
blktrace
추적에서 더 많은 데이터를 추출 해야 합니까 ?
이 문제는 나를 미치게 만들고 있으며 Linux IO 하위 시스템에 대해 더 많이 알고 싶습니다(다른 사람들에게 유용할 수 있기를 바랍니다).
감사해요.
LUKS의 설정은 다음과 같습니다.
LUKS header information
Version: 2
Epoch: 6
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
Label: (no label)
Subsystem: (no subsystem)
Flags: allow-discards same-cpu-crypt submit-from-crypt-cpus no-read-workqueue no-write-workqueue
Data segments:
0: crypt
offset: 16777216 [bytes]
length: (whole device)
cipher: aes-xts-plain64
sector: 512 [bytes]
Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 4
Memory: 1048576
Threads: 4
AF stripes: 4000
AF hash: sha256
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha256
Iterations: 170223
보시다시피, allow-discards same-cpu-crypt submit-from-crypt-cpus no-read-workqueue no-write-workqueue
암호화 속도를 높이기 위해 일부 플래그( )를 사용했지만 문제가 해결되지 않았습니다.
결과는 다음과 같습니다 cryptsetup benchmark
.
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 1826787 iterations per second for 256-bit key
PBKDF2-sha256 3477864 iterations per second for 256-bit key
PBKDF2-sha512 1576806 iterations per second for 256-bit key
PBKDF2-ripemd160 805357 iterations per second for 256-bit key
PBKDF2-whirlpool 661145 iterations per second for 256-bit key
argon2i 9 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 9 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 1104.9 MiB/s 2227.6 MiB/s
serpent-cbc 128b 106.7 MiB/s 650.2 MiB/s
twofish-cbc 128b 213.5 MiB/s 377.8 MiB/s
aes-cbc 256b 860.5 MiB/s 2125.8 MiB/s
serpent-cbc 256b 112.1 MiB/s 645.8 MiB/s
twofish-cbc 256b 217.6 MiB/s 376.3 MiB/s
aes-xts 256b 2040.3 MiB/s 2059.2 MiB/s
serpent-xts 256b 564.5 MiB/s 559.3 MiB/s
twofish-xts 256b 345.9 MiB/s 349.2 MiB/s
aes-xts 512b 1962.4 MiB/s 1958.9 MiB/s
serpent-xts 512b 578.6 MiB/s 567.6 MiB/s
twofish-xts 512b 354.4 MiB/s 353.9 MiB/s
btt
결과:
==================== All Devices ====================
ALL MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------
Q2Q 0.000016862 0.174177680 9.661069906 220
Q2G 0.000002024 0.019928804 0.807080182 165
G2I 0.000001052 0.001048819 0.003998630 165
Q2M 0.000000370 0.000001245 0.000002966 42
I2D 0.000004078 0.006283935 0.168370736 109
M2D 0.001225914 0.008880338 0.074362742 28
D2C 0.000251386 1.055605439 7.040268517 135
Q2C 0.000268619 0.905934448 7.126410344 207