부팅 속도가 느린 이유는 무엇입니까?

부팅 속도가 느린 이유는 무엇입니까?

저는 Fedora 23, MATE 버전을 사용하고 있습니다. 컴퓨터가 시작되는 속도가 매우 느리게 느껴집니다. 어떻게 속도를 높일 수 있나요?

세부https://i.stack.imgur.com/vpJEG.jpg

$ systemd-analyze 
Startup finished in 16.571s (firmware) + 2.605s (loader) + 824ms (kernel) + 1.997s (initrd) + 48.466s (userspace) = 1min 10.464s

$ systemd-analyze blame
         31.448s mlocate-updatedb.service
         18.211s akmods.service
         16.019s firewalld.service
          9.127s systemd-journald.service
          7.709s accounts-daemon.service
          7.368s dev-sdd3.device
          7.037s systemd-udev-settle.service
          5.219s abrtd.service
          4.854s chronyd.service
          4.629s ModemManager.service
          4.081s livesys.service
          3.958s unbound-anchor.service
          3.920s systemd-logind.service
          3.823s rsyslog.service
          3.781s gssproxy.service
          3.780s akmods-shutdown.service
          3.698s avahi-daemon.service
          3.651s mcelog.service
          3.636s rtkit-daemon.service
          2.735s polkit.service
          2.163s systemd-udevd.service
          2.150s lvm2-monitor.service
          1.569s proc-fs-nfsd.mount

$ systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @35.395s
└─lightdm.service @34.563s +830ms
  └─systemd-user-sessions.service @34.146s +129ms
    └─remote-fs.target @34.143s
      └─remote-fs-pre.target @34.143s
        └─iscsi-shutdown.service @34.128s
          └─network.target @34.019s
            └─NetworkManager.service @33.009s +1.009s
              └─firewalld.service @16.979s +16.019s
                └─polkit.service @17.870s +2.735s
                  └─basic.target @12.883s
                    └─sockets.target @12.864s
                      └─dbus.socket @12.844s
                        └─sysinit.target @12.704s
                          └─sys-fs-fuse-connections.mount @48.351s +3ms
                            └─system.slice
                              └─-.slice

답변1

이는 알려진 문제이며 다음 항목에 설명되어 있습니다.레드햇 버그질라:

systemd에는 cron의 무작위 지연 기능이 부족하여 우리에게 타격을 줍니다. 기능 요청이 있는 것을 봤습니다. 하지만 그때까지는,updateb를 실행하기 전에 수동으로 임의 절전 모드를 설정하는 것이 해결책인 것 같습니다.. 지금 updateb를 실행하려면 cron을 사용하는 방식으로 돌아가거나, updateb를 실행하기 전에 무작위 또는 특정 절전 모드를 수행하는 것이 좋습니다. 예: sleep 1h

해결책:

sed 's/daily/weekly/' /usr/lib/systemd/system/mlocate-updatedb.timer >/etc/systemd/system/mlocate-updatedb.timer

이제 월요일의 느린 시작을 견뎌내면 됩니다.

답변2

다음 해결 방법을 권장합니다. mlocate-updatedb.service 시작을 몇 분(예: 10분) 지연하여 시스템 시작 시 실행해야 하는 경우 일정 시간 후에 시작되도록 합니다.

다음은 이를 수행하며 mlocate 패키지가 업데이트되면 교체되지 않습니다.

mkdir /etc/systemd/system/mlocate-updatedb.service.d
cat <<EOF > /etc/systemd/system/mlocate-updatedb.service.d/mlocate-updatedb.conf
[Service]
ExecStart=
ExecStart=/bin/sleep 10m
ExecStart=/usr/libexec/mlocate-run-updatedb
EOF

이것의 이점은 느린 시작을 방지한다는 것입니다(아직 테스트하지는 않았지만 이 작업을 수행해야 하며 위치 지정 데이터베이스를 매일 업데이트합니다.

systemd-222-14.fc23.x86_64(이상)가 포함된 Fedora 23의 경우: systemd 타이머에는 이제 이 문제에 대한 해결책을 제공하는 것으로 보이는 RandomizedDelaySec라는 새로운 옵션이 있습니다. 따라서 다음과 같은 라인을 추가하는 것도 효과가 있습니다: RandomizedDelaySec=30m

(지연은 여전히 ​​임의적이므로 때로는 매우 작아서 시작 속도가 느려질 수 있습니다.)

고쳐 쓰다:업데이트가 Fedora 테스트 저장소에 푸시되었습니다. 이로 인해 서비스 유형이 에서 변경된 것으로 보입니다 oneshot. 이로 인해 systemd는 계속하기 전에 종료를 기다리지 않게 simple됩니다 . updatedb이것은 어느 정도 문제를 해결합니다. 그러나 IO가 너무 많으면 시작 프로세스가 느려질 수 있으므로 시작 중에 실행되지 않도록 sleepor 를 사용하는 것이 좋습니다 .RandomizedDelaySec

관련 정보