☰

시작하는 데 왜 이렇게 오랜 시간이 걸리나요?

tag-icon • tag-icon fedora boot systemd io
시작하는 데 왜 이렇게 오랜 시간이 걸리나요? 
# systemd-analyze blame
       40.256s firewalld.service
       38.154s initial-setup-graphical.service
       26.161s dev-mapper-VolGroup\x2dlv_root.device
       24.262s abrtd.service
       24.118s systemd-udev-settle.service
       20.907s systemd-journal-flush.service
       17.716s accounts-daemon.service
       16.398s libvirtd.service
       11.097s systemd-udevd.service
       10.533s systemd-journald.service
       10.389s systemd-sysctl.service
       10.266s dnf-makecache.service
        4.412s polkit.service
        4.404s jexec.service
        3.767s lvm2-monitor.service
        3.439s chronyd.service
        3.300s systemd-logind.service
        3.157s livesys.service
        3.155s akmods-shutdown.service
        3.144s akmods.service
        3.143s gssproxy.service
        2.889s rpcbind.service

그 외에도 각 IO를 완료하는 데 시간이 오래 걸리나요? 이것을 어떻게 추적하나요?

답변1

사용안내도IO가 시작 시 제한 요소인지 확인합니다. 그래프는 기본적으로 항상 100% IO를 표시하며 CPU를 완전히 활용하는 짧은 순간만 표시될 것으로 예상합니다.

그놈 디스크에서 빠른 성능 테스트가 가능합니다. Spinning Rust는 검색당 10밀리초로 100MB/s가 조금 넘는 속도를 보여줄 것으로 예상해야 합니다.

저는 전통적인 기계적 저장에 있어서 타이밍 규모가 합리적이라고 생각합니다. Firewalld의 기능은 익숙해 보일 것입니다. 내 디스크 기반 시스템에는60세 이상90초(!). systemd-analyze blame하지만 그다지 나쁘지는 않은 것 같습니다.

업스트림(및 Fedora) 개발자는 좋은 비기계적 스토리지를 구입하는 경향이 있습니다. 프로그램을 시작할 때의 성능은 잘 알려진 이점입니다 :-).

systemd-readahead유지되지 않았으며 결국 제거되었습니다. 서비스는 요청 시(및 비순차적) 페이지 읽기를 방지하기 위해 시작에 필요한 파일을 순차적으로 미리 읽습니다. 즉, 느린 기계 작동 횟수를 줄입니다.

우분투 이야기가 무엇인지 궁금합니다. 우분투가 systemd를 채택하면 큰 퇴보를 알아차릴 만큼 충분한 리소스가 있다고 생각합니다.

방금 알아차렸어livesys.service CD 또는 DVD에서 부팅하는 경우 부팅 성능이 저하될 수 있습니다.. 기본 USB 드라이브의 경우... 더 좋지만 불행하게도 순차 읽기는 내부 저장소만큼 빠르지 않습니다.

답변2

"IO를 완료하는 데 시간이 오래 걸립니다."에서 자신만의 답변을 제공했을 수도 있습니다. 부팅 볼륨 하드웨어에 성능 문제가 있을 수 있습니다. I/O가 매우 느리다면 소프트웨어에서 눈에 띄는 차이를 만들기 위해 할 수 있는 일이 없을 것입니다.

관련 정보