가상 머신 이미지를 복제할 때마다 시스템의 응답 속도가 매우 느려집니다. 나는 이것을 사용하고 virt-manager있으며 IO가 qemu-img convert여러 스레드에 의해 수행되고 있음을 볼 수 있습니다.
정보를 좀 모아보려고 했는데 그런 것 같아요가능한스와핑(스왑 파티션의 I/O)이 많습니다. 8GB RAM과 2GB 스왑 공간이 있습니다. 복제 중과 복제 후에는 free -h스왑 공간이 100% 사용된 것으로 표시됩니다. 그러나 이는 당시 시스템이 얼마나 많이 교체되었는지 알려주지 않습니다. VM을 복제하기 전에 스왑 영역이 무언가로 채워졌을 수 있습니다.
저는 기계식 하드디스크를 사용하고 있습니다. 현재 운영 체제는 Fedora Linux 28입니다.
이런 일이 발생하면 어떻게 준비하고, 관련 정보를 수집하고, 대규모 거래소가 있는지 확인하려면 어떻게 해야 합니까?
다양한 정보를 되돌아보고 정리할 수 있는 일종의 기록을 원했습니다. 즉, 간단한 topOR iotop명령을 실행하면 이전 출력을 덮어쓰게 되므로 이를 원하지 않습니다.
고쳐 쓰다
나는 원래 답변에서 제안한 것처럼 그러한 정보를 수집하는 것이 여전히 유용하다고 생각합니다. 하지만:
내 시스템이 거의 완전히 응답하지 않는 가장 큰 두 가지 이유를 발견했습니다. 그 중 어느 것도 범핑(스와핑 또는 비스와핑)과 관련이 없습니다.
첫째, 버그가 있습니다 gnome-shell. 메인 스레드에서 fsync()를 기다립니다. (Wayland) 그래픽 서버의 메인 스레드입니다. 기다리는 동안 디스플레이는 업데이트되지 않습니다. 이 오류는 gnome-shell 3.30.2에서 관찰되었으며 다음과 같아야 합니다.안정적인버전 3.32에서.
(이 문제는 GNOME Wayland 세션과 Xorg 세션을 비교하여 진단할 수 있습니다. Xorg 세션에서는 마우스 커서가 여전히 움직일 수 있어야 합니다.)
두 번째 문제는 ext4의 알려진 문제입니다. 파일에 쓸 때 fsync()가 켜집니다.다른파일은 "무한히 대기하게 될" 수 있습니다. 따라서 이는 gnome-shell 오류에 영향을 미칩니다.
gnome-shell이 수정되더라도 ext4의 긴 지연은 Firefox에 영향을 미치는 것 같습니다. 위의 ext4 문제에 대한 수정 사항이 Linux 커널 버전 5.3에 병합되었습니다.[1][2].
피투성이의 세부 사항은 여기에 기록됩니다.Linux 파일 시스템에서 간단한 파일 복사(또는 쓰기)로 인해 10초 이상의 대기 시간이 발생함
답변1
vmstat메모리, 스왑 및 IO를 추적하는 데 사용되는 전통적인 Linux 명령입니다. 예를 들어 vmstat 5, 5초마다 한 줄의 통계를 인쇄합니다.
atop이는 새로운 도구이며 매우 강력합니다. 실행은 atop와 비슷 top하지만 더 많은 정보가 있습니다. 로그를 원할 경우 atop -w <file>대신 바이너리 로그에 기록되어 사용할 수 있습니다 atop -r <file>. atop패키지에는 기본적으로 10분 간격으로 자동으로 로그를 기록하는 서비스도 포함되어 있습니다.
업데이트: atop2.4.0에는 Linux에 대한 지원이 추가되었습니다.압력 실속 정보. 이것이 메모리 부족으로 인한 지연을 감지하는 데 도움이 되기를 바랍니다. 메모리 부족 통계( ms또는 mf에 표시 atop)는 스왑 및 비스왑 스래싱을 감지할 수 있습니다. 기술적으로 이는 스왑된 지터와 스왑되지 않은 지터를 구별하는 데 도움이 되지 않음을 의미합니다. :-). 하지만 저는 이 정보를 알고 싶습니다. 저더가 내 문제라는 확신이 많지 않습니다. 업데이트에서 알 수 있듯이 저더가 실제로 주요 문제는 아닙니다.
제가 가지고 있는 주요 문제에 관해서는: 이에 대한 정보를 수집하는 것이 어렵다고 생각합니다. 도움이 될 수 있는 일반적인 추적 방법이 있습니다.offcputime --state 2. 이 도구를 설치하는 데는 약간의 노력이 필요했습니다.
이전 답변
atop노트북을 밤새 매달아 놔도 작동하도록 하는 해결 방법을 설치했습니다 ..
atop만성적인 메모리 소비 문제가 있는 경우 서비스의 로그는 매우 유익할 수 있습니다. 기본 10분 로깅 간격으로 인해 더 짧은 질문이 누락될 수 있습니다.
- 내 문제는 10~20분 동안 지속되는 것 같습니다.
- 스왑 사용량은 이전 예의 1.4G에서 2G(100%)로 증가합니다.
- RAM의 스레드
qemu-img자체 크기는 크지 않습니다. 프로세스qemu-img에는 2,500만 명의 주민만 있습니다. swout예전에는175735. 이는 4096바이트 페이지로 측정되었으며 이는 약 0.7G가 스왑 아웃되었음을 의미합니다.
동시에 cache0.8G에서 2.3G로 늘어났다. free메모리가 0.1G에서 멈췄습니다.
나는 qemu-img가 캐시된 IO를 수행하고 있고 캐시가 다른 메모리를 밀어내고 있으며 이것이 스왑의 원인이라고 생각합니다. 스왑 공간이 없으면 여전히 몇 가지 문제가 있을 것으로 예상됩니다. 즉, 로드된 프로그램 코드와 다른 캐시가 제거될 것입니다.
drop_caches16G 파일 이 있으면 상당한 cp양의 스와핑을 실행할 수 있습니다. 나는 같은 문제가 재현되고 있다고 생각합니다 cp. 나는 그것이 특정 세부 사항에 국한되지 않는다고 생각합니다 qemu-img convert.