☰

메모리가 64GB인 시스템에서 Linux 버퍼는 dd를 사용하여 dev null로 복사하는 동안 전체 실행되고 io는 수동 drop_caches까지 중지됩니다.

tag-icon • tag-icon linux performance dd pagefile disk-cache
메모리가 64GB인 시스템에서 Linux 버퍼는 dd를 사용하여 dev null로 복사하는 동안 전체 실행되고 io는 수동 drop_caches까지 중지됩니다.

저는 Linux 소프트웨어 raid 10을 사용하여 서버를 실행하고 있습니다. 64GB Ram을 갖춘 듀얼 CPU 시스템입니다. 각 CPU와 관련된 2x16GB DIMM. dd를 사용하여 kvm 가상 머신을 백업하고 심각한 io 문제가 발생하고 싶습니다. 처음에는 레이드와 관련이 있는 줄 알았는데 리눅스 메모리 관리의 문제였습니다. 예는 다음과 같습니다.

  1. 기억력은 괜찮습니다: https://i.stack.imgur.com/NbL60.jpg
  2. 나는 dd를 시작합니다 : https://i.stack.imgur.com/kEPN2.jpg
  3. nmon이 디스크 액세스를 표시하는 것도 볼 수 있습니다. https://i.stack.imgur.com/Njcf5.jpg
  4. 잠시 후 "버퍼"가 커지고 복사 진행이 중지됩니다. https://i.stack.imgur.com/HCefI.jpg
  5. 여기 meminfo가 있습니다: https://i.stack.imgur.com/KR0CE.jpg
  6. dd 출력은 다음과 같습니다. https://i.stack.imgur.com/BHjnR.jpg
  7. 일시적인 문제를 수동으로 해결하고 캐시를 강제로 삭제할 수 있습니다: "sync; echo 3 > /proc/sys/vm/drop_caches"
  8. 통화에는 몇 초가 걸리며 그 직후 dd 속도가 정상 수준에 도달합니다. 물론 매 분마다 cronjob을 수행할 수 있지만 이는 실제 솔루션이 아닙니다. https://i.stack.imgur.com/zIDRz.jpg https://i.stack.imgur.com/fO8NV.jpg

누구든지 솔루션이나 구성 힌트가 있습니까? 여기에 내 sysctl도 있지만 모든 값은 centos 기본값입니다. https://i.stack.imgur.com/ZQBNG.jpg

편집1

나는 다른 테스트를 하고 /dev/null 대신 디스크에 dd를 만듭니다. 이번에도 pv 없이 하나의 명령으로. 따라서 프로세스는 하나뿐입니다.dd if=/dev/vg_main_vms/AppServer_System of=AppServer_System bs=4M

  1. 쓰기 없이 읽기부터 시작합니다(대상이 동일한 디스크에 있지 않음). https://i.stack.imgur.com/jJg5x.jpg
  2. 잠시 후 쓰기가 시작되고 읽기 속도가 느려집니다. https://i.stack.imgur.com/lcgW6.jpg
  3. 그 후에는 글쓰기 시간이 옵니다: https://i.stack.imgur.com/5FhG4.jpg
  4. 이제 주요 문제가 시작됩니다. 복사 프로세스가 1mbs 미만으로 느려지고 아무 일도 일어나지 않았습니다. https://i.stack.imgur.com/YfCXc.jpg
  5. 이제 dd 프로세스에는 100% CPU 시간(코어 1개)이 필요합니다. https://i.stack.imgur.com/IZn1N.jpg
  6. 그리고 다시 일시적인 문제를 수동으로 해결하고 캐시를 강제로 삭제할 수 있습니다 sync; echo 3 > /proc/sys/vm/drop_caches. 그 후 같은 게임이 다시 시작됩니다 ...

편집2

로컬 dd의 경우 iflag=direct 및 oflag=direct 매개변수를 사용하여 문제를 해결할 수 있습니다. 그러나 VM에서 로컬 삼바 공유로 파일을 복사하는 것과 같은 다른 파일 액세스도 있고 거기에서는 그러한 매개 변수를 사용할 수 없기 때문에 이것은 보편적인 솔루션이 아닙니다. 이러한 문제 없이 대용량 파일을 복사할 수 없는 것은 정상적인 일이 아니기 때문에 시스템 파일 캐시 규칙을 조정해야 합니다.

답변1

그냥 추측일 뿐입니다. 문제는 큰 더티 페이지 플러싱일 수 있습니다. 다음과 같이 /etc/sysctl.conf를 설정해 보십시오:

# vm.dirty_background_ratio contains 10, which is a percentage of total system memory, the 
# number of pages at which the pdflush background writeback daemon will start writing out 
# dirty data. However, for fast RAID based disk system this may cause large flushes of dirty
# memory pages. If you increase this value from 10 to 20 (a large value) will result into 
# less frequent flushes:
vm.dirty_background_ratio = 1

# The value 40 is a percentage of total system memory, the number of pages at which a process
# which is generating disk writes will itself start writing out dirty data. This is nothing
# but the ratio at which dirty pages created by application disk writes will be flushed out
# to disk. A value of 40 mean that data will be written into system memory until the file 
# system cache has a size of 40% of the server's RAM. So if you've 12GB ram, data will be
# written into system memory until the file system cache has a size of 4.8G. You change the
# dirty ratio as follows:
vm.dirty_ratio = 1

그런 다음 sysctl -p다시 로드하고 캐시를 다시 삭제하십시오( echo 3 > /proc/sys/vm/drop_caches).

관련 정보