Ubuntu 14.04를 사용하여 30분 동안 실행한 후하이브리드 SSD를 사용하는 많은 프로세스가 있습니다 iotop
. 예를 들어 gedit에서 빈 파일을 열고 닫으면 dconf 쓰기 설정으로 인해 닫히는 데 2초가 걸릴 수 있으며 이는 비슷한 방식으로 다른 사용자에게도 영향을 줍니다. 전체 시스템.
strace를 사용하여 fsync 호출을 다시 추적하고 거기에서 sync 명령을 사용하여 이를 재현했습니다.
요약하면 sync
터미널에서 단순히 반복적으로 실행하는 데 1~2초가 걸릴 수 있지만 가동 시간은 30분 후에만 가능합니다.
이를 시연하기 위해 동기화를 수행하는 데 걸리는 시간을 기준으로 가동 시간을 초 단위로 출력하는 스크립트를 만들고 매초 실행했습니다.
while true;
do
cat /proc/uptime | awk '{printf "%f ",$1}'; /usr/bin/time -f '%e' sync;
sleep 1;
done;
위의 스크립트를 실행하고 약 1시간 동안 기다렸다가(시스템이 유휴 상태임) gnuplot에 결과를 표시했습니다(y = 동기화 수행 시간(초), x = 가동 시간(초)).
그래프는 약 1780(1780/60 = 약 30분)에서 최고점에 도달합니다.
이 시점에서는 스크립트 이외의 어떤 것도 디스크에 기록되어서는 안 됩니다. 따라서 첫 번째 동기화 후에는 페이지 캐시에 거의 아무것도 없어야 하며, 이후의 각 동기화는 스크립트에 기록되는 내용을 정확하게 기록합니다(약 100바이트). .
예를 들어 재부팅 후에도 문제가 지속됩니다. 30분 동안 속도가 느려질 때까지 기다렸다가 재부팅하면 속도 저하가 계속 발생합니다. 전원을 껐다가 다시 켜면 30분 후에 문제가 사라집니다.
또 다른 흥미로운 점은 위의 이미지를 검토하고 속도 저하가 발생하는 영역을 확대하면 다음과 같은 결과가 나온다는 것입니다.
최고점과 최저점은 최저점에서 최저점으로 거의 10초마다 반복되며, 최고점과 최저점은 떨어지면서 꼬이기도 합니다.
또한 속도를 늦추기 전에 hdparm 테스트를 실행했습니다( hdparm -t /dev/sda
및).hdparm -T /dev/sda
/dev/sda:
Timing cached reads: 23778 MB in 2.00 seconds = 11900.64 MB/sec
/dev/sda:
Timing buffered disk reads: 318 MB in 3.01 seconds = 105.63 MB/sec
경기 침체기 동안:
/dev/sda:
Timing cached reads: 2 MB in 2.24 seconds = 915.50 kB/sec
/dev/sda:
Timing buffered disk reads: 300 MB in 3.01 seconds = 99.54 MB/sec
이는 실제 디스크 읽기는 영향을 받지 않지만 캐시 읽기는 영향을 받는다는 것을 보여줍니다. 이는 하드 드라이브가 아니라 시스템 버스와 관련이 있다는 의미입니까?
내가 시도한 솔루션은 다음과 같습니다.
하드 드라이브의 속도 감소 설정을 변경하면 하드 드라이브가 절전 모드로 들어갈 수 있습니다.
hdparm /dev/sda -S252 #(set it to 5 hours before spindown)
파일 시스템의 로그 유형을 정렬 대신 쓰기 저장으로 변경하면 성능이 향상될 수 있지만 30분 동안 느려지지 않는 가동 시간을 고려하지 않았기 때문에 문제가 해결되지 않았습니다.
30분 후에 발생하는 것으로 보이므로 CRON을 비활성화합니다.
CPU 사용량은 양호하고 완전히 유휴 상태이므로 어떤 프로세스의 탓으로 돌릴 수는 없지만 세션 관리자(lightdm)를 포함한 모든 서비스를 끄려고 시도했지만 문제가 낮은 수준이라고 생각하여 아무 조치도 취하지 않았습니다.
30분 이후에 들어온 새로운 프로세스를 분석해 보면 아무런 변화가 없었습니다. PS의 출력 전과 후를 비교해보니 차이가 없었습니다.
이 문제는 불과 2주 전부터 아무것도 설치되지 않고 업데이트도 이루어지지 않은 상태에서 발생하기 시작했습니다. 이 질문은 훨씬 낮은 수준이라고 생각하므로 여기에 도움을 주시면 정말 감사하겠습니다. 제가 아무것도 모르고 올바른 방향을 가리키는 것조차 도움이 될 것입니다. 예를 들어 페이지 캐시가 새로 고쳐지고 있는지 확인할 수 있는 방법이 있습니까?
문제의 디스크에서 쓰기 캐싱이 활성화되어 있으며 쓰기 장벽도 비활성화해 보았습니다. 하드 드라이브의 스마트 데이터는 하드 드라이브 자체에는 아무런 문제가 없음을 시사하지만, 재부팅 후에도 지속되기 때문에 하드 드라이브가 신비한 일을 하고 있는 것으로 의심됩니다.
편집하다:
나는 그것을 완료했습니다:
watch -n 1 cat /proc/meminfo
...메모리가 어떻게 변화하는지, 특히 더티 라인과 다시 쓰기 라인을 보면 이것이 HD 디스크 버퍼인 것 같습니다. 대부분 0으로 유지되며 최대 300kb까지 유지됩니다. sync를 호출하면 예상대로 다시 0으로 플러시되지만 더티 페이지가 없고 디스크 버퍼에 0kb가 있을 때 sync를 호출하면 속도가 느려지는 동안 IO가 계속 잠깁니다. 페이지 캐시와 쓰기 캐시를 플러시할 방법이 없으면 동기화로 또 무엇을 할 수 있나요?
답변1
이러한 증상은 대부분의 포화된 IO 시스템과 매우 일치하지만 OS/사용자 공간 측면에서 발생하는 IO 로드를 크게 배제하면서 드라이브가 자체적으로 자체 테스트를 실행하고 있을 수도 있습니다. 모든 분야를 읽었습니다. 이는 smartctl에서 쿼리 가능/조정 가능해야 합니다(쿼리에는 적어도 한 곳의 smartctl -c가 사용됨).
지금 갑자기 왔다가 사라지기 시작한 이유는 다음과 같습니다.
- 드라이브가 수명 주기의 특정 단계(기록된 섹터 수, 회전 시간 등)를 통과했으며 드라이브의 펌웨어가 검색 중 하나를 트리거했습니다.
- 나는 이것이 smartctl을 통해서도 트리거될 수 있다고 생각하므로 일부 자동화된 프로세스가 이를 트리거할 수도 있습니다.
- 스캔 중 하나를 트리거하고 진행 중 또는 시작됨으로 표시합니다. 드라이브가 한동안 켜져 있으면 처음부터 다시 트리거되거나 중단된 부분에서 다시 시작됩니다.