dnf가 너무 느립니다

dnf가 너무 느립니다

패키지를 설치하는 동안 컴퓨터가 몇 초 동안 정지될 정도로 dnf가 매우 느린 이상한 문제에 부딪혔습니다. Fedora 29를 실행하지만 이런 일이 수년 동안 발생했습니다. 그렇지 않으면 컴퓨터가 정상적으로 작동하고 충돌이 발생하지 않습니다. 분명히 dnf에만 몇 가지 약점이 있습니다. "dnf 업그레이드"는 100개 패키지를 완료하는 데 1시간이 걸릴 뿐만 아니라, 매년 Fedora를 업그레이드할 때 Begins Friday night에서 3000개 이상의 패키지가 업데이트되므로 주말 동안 컴퓨터 없이 살 수 있도록 크리스마스 휴일을 기다립니다. 일요일에 끝납니다.

루트는 기존 SSD 디스크에 마운트되고, /home은 새 클래식 디스크(WD Caviar Black)에 마운트되며, 백업용으로 또 다른 디스크가 있습니다(여러 디스크가 마운트되어 있음을 나타냄). 기존 SSD가 제대로 작동하지 않는 것으로 의심되어 루트 파티션을 클래식 디스크 중 하나로 옮겼지만 상황이 개선되지 않았습니다(더 느려졌습니다).

Journalctl, dmesg 또는 /var/log/messages에는 특별한 내용이 표시되지 않습니다. Sysbench에 따르면 설치된 모든 디스크의 디스크 성능은 좋은 dnf가 포함된 Fedora 29를 실행하는 다른 (구형) 컴퓨터와 마찬가지로 좋습니다(몇 분 만에 업그레이드, 연간 업그레이드는 점심 시간에 출시됨).

무슨 일이 일어나고 있는지 알아보기 위해 어디를 봐야 하는지 아는 사람이 있나요?

PS top, iotop, iostat, dmesg,journalctl, 이런 기본적인 것들을 많이 확인했습니다. iotop은 업그레이드를 수행할 때 디스크에서 99.99%의 활동으로 Python...(dnf)을 표시하지만 이는 정상적인 것 같습니다. 위에서 언급한 sysbench에서도 dnf를 쉽게 수행하는 다른 컴퓨터보다 디스크가 약간 더 빠른 것으로 나타났습니다.

브랜드: i7-920 프로세서, 24G RAM, 스왑 없음

답변1

로버트: 어떤 시스템 호출이 가장 오래 걸리는지 아는 것은 흥미로울 것입니다.

perf 추적을 사용하여 간단한(임의) 패키지를 설치한 다음 정렬하여 가장 긴 호출을 찾을 수 있습니까?

예: # perf Trace -s -o /tmp/trace.out dnf install -y xorg-x11-apps-7.7-20.fc28.x86_64

그런 다음 /tmp/trace.out 파일의 내용을 게시합니다. 요약 파일이므로 너무 크지는 않지만 어떤 시스템 호출이 가장 오래 걸리는지, 정상 범위를 벗어나는지 지적하는 데 도움이 됩니다.

답변2

이 질문이 오래전부터 있었던 일이라는 것은 알지만, 이 문제의 원인은 쓰기 속도가 터무니없이 느린 SMR(Single Magnetic Resonance) 드라이브를 사용하고 있기 때문일 수 있다고 생각합니다. 다음은 몇 가지 참고 자료입니다.

그리고 일부 공급업체 참고자료:

관련 정보