/dev/mydisk
기능 스택을 기반으로 하는 장치인 LUKS 암호화 소프트웨어 RAID-1이 있습니다 .
저는 가끔 /dev/mydisk
외부 USB 디스크에 콘텐츠를 백업하는데, 이 디스크 자체는 LUKS를 사용하여 암호화됩니다. 몇 개의 100GiB를 전송해야 합니다. 이 작업은 단순하지 dd
않고 재귀적 입니다 cp
. (아직도 use로 변경해야 합니다 rsync
.)
백업이 시작된 지 얼마 후 전체 시스템의 상호 작용이 크게 떨어졌습니다. KDE 인터페이스는 분명히 메모리 요청이 승인되기를 기다리고 있습니다. 프롬프트가 나올 때까지 2분을 기다리는 것은 드문 일이 아닙니다. 네트워크 I/O를 기다리는 데도 많은 인내가 필요합니다. 이는 부팅한 후 알 수 없는 목적으로 각 zip의 압축을 풀고 각 파일의 내용을 색인화하기로 결정했을 때 발생하는 상황과 유사합니다 baloo
. 즉, 시스템이 늪지 카누가 됩니다.
커널은 모든 RAM을 복사 프로세스에 제공하는 것으로 보이며 기회가 주어지면 이를 상호 작용 프로세스에 다시 제공하지 않으려고 합니다. RAM도 나쁘지 않습니다: 23GiB. 만일을 대비해 11GiB의 스왑 공간도 있지만 항상 몇 MiB가 차지합니다.
복사 프로세스 전에 대화형 프로세스가 RAM을 확보하도록 할 수 있습니까? 그렇다면 어떻게 해야 할까요?
버전 정보:
- 이것은 Fedora 29(4.19.15-300.fc29.x86_64) 시스템이지만 이전 Fedora 시스템에서도 이 문제가 있었던 것으로 알고 있습니다.
- KDE 버전은 "KDE 프레임워크: 5.53.0"을 기반으로 합니다.
고쳐 쓰다
지금까지 모든 사람의 답변에 감사드립니다!
무엇을 검색해야 할지 알면 뭔가가 발견될 것입니다.
내가 뽑은 것 :
- 2018-10: U&LSE 항목은 분명히 내 문제에 관한 것 같습니다.외부 디스크에서 과도한 읽기/쓰기 작업을 수행할 때 시스템이 지연됩니다.. 질문자가 사용한
dd
해결책은 플래그를 사용하여oflag=direct
페이지 캐싱을 우회하는 것입니다. - 2018-11: U&LSE 쓰기 속도 저하라는 비교적 일반적인 문제에 대해2013년에 "USB 플래시 드라이브 정지" 문제가 발생한 이유는 무엇입니까? 기존의 "I/O 더티 스로틀링 없음" 코드가 이 문제를 해결하지 못하는 이유는 무엇입니까?. 이것은 매우 혼란스러운 일이며 우리는 소문과 현상에 맞서 싸워야 합니다.
- 2013-11: LWM.net의 Jonathan Corbet:유해한 USB 스틱이 걸리는 문제. "2013년 보고 이슈" 기사입니다. 그러나 2018-11년 질문에 대한 응답에서는 해당 기사가 거짓이며 잘못된 전제에 기초한 것으로 나타났습니다.
- 2011-08: 강제 제거 방법에 대한 U&LSE 항목페이지 캐시, 응답성을 복원할 수 있습니다.캐시를 지우려면 /proc/sys/vm/drop_caches를 설정하세요.
- 2016년 1월: 크기 제한 방법에 대한 U&LSE 항목버퍼 캐시:Linux에서 버퍼 캐시 크기 제한
- I/O 스케줄러 및 쓰기 저장 제한에 대해 논의합니다.
- 2018-10: 이 문제에 대한 U&LSE:"쓰기 저장 제한"은 "USB 디스크 고착 문제"에 대한 솔루션입니까?
- 2016-04: LWM.net의 조나단 코베트(Jonathan Corbett):성가신 백그라운드 쓰기 저장을 줄입니다..
- 나는 또한 고려 중입니다: 2017-05:I/O 스케줄러 튜닝을 통한 Linux 시스템 성능 향상, 2009년 6월:Linux I/O 스케줄러 선택
I/O 튜닝을 처리할 수 있는 전문 시스템이 아직 없는 이유는 무엇입니까..?
답변1
nice -n 19
프로세스(CPU에 낮은 우선순위를 부여함)와 아마도 ionice -c 3
(유휴 시 I/O)를 백업 할 것입니다 .
rsync도 크게 개선될 것입니다(매번 100Gb를 복사하지는 않습니다). 예를 들어 내 백업 스크립트는 다음과 같습니다.
SOURCE=/whatever/precious/directory
DESTINATION=/media/some_usb_drive/backup
nice -n 19 rsync --verbose --archive --compress --delete --force --recursive --links --safe-links --rsh ssh --exclude-from=$EXCLUDEFILE $SOURCE $DESTINATION
# or
nice -n 19 ionice -c 3 rsync --verbose --archive --compress --delete --force --recursive --links --safe-links --rsh ssh --exclude-from=$EXCLUDEFILE $SOURCE $DESTINATION
(exclude-from은 .cache 디렉터리, .o 파일 등을 방지하는 데 사용됩니다.)
답변2
확인해보니 문서에는 언급되어 있지 않지만nocache
정상적으로 쓸 수 있어야 함. 작은 파일을 복사할 때는 fdatasync()
각 파일을 호출 해야 하기 때문에 실행 속도가 느려집니다 .
fdatasync()
( 대량/호출의 영향을 줄이려면 Linux 관련 기능을 사용하십시오 .fsync()
dpkg
IO 및 캐싱 효과에 대한 관련 답변에서 이것이 어떻게 작동하는지에 대한 설명 "[1]"을 참조하십시오.. 그러나 이를 nocache
defer 로 변경해야 하며 close()
경우에 따라 원치 않는 부작용이 있을 수 있습니다. :-(.)
또 다른 아이디어는 를 사용하여 cgroup에서 복제 프로세스를 실행 systemd-run
하고 메모리 소비 제한을 설정하는 것입니다. cgroup 메모리 컨트롤러는 캐시와 프로세스 메모리를 제어합니다. systemd-run
이 명령의 좋은 예를 찾을 수 없습니다 (누군가가 하나를 제공할 수도 있습니다 :-).