Linux 서버를 다시 시작하는 데 필요한 시간

Question 1

CentOS 7+ 또는 Ubuntu 15.04+를 사용하고 있다고 가정합니다. 둘 다 systemd와 함께 제공됩니다. Systemd에는 시스템 부팅에 걸리는 시간을 계산하는 몇 가지 훌륭한 도구와 그 이유를 이해하는 몇 가지 시각화 도구가 있습니다.

가장 기본적인 출력의 경우 실행하면 systemd-analyze다음과 같은 멋진 요약을 얻을 수 있습니다.

Startup finished in 853ms (kernel) + 3min 50.610s (initrd) + 10.345s (userspace) = 4min 1.809s

이는 마지막으로 시작된 이후 시스템을 시작하는 데 걸린 시간을 알려줍니다. 이는 BIOS/하드웨어 초기화 또는 GRUB 시간 초과를 고려하지 않지만 실제 운영 체제 부팅 시간에 대해서는 정확해야 합니다.

운영 체제가 왜 그렇게 오래 걸리는지 알아내려면 systemd-analyze blame가장 오래 실행되는 서비스의 그래프를 가장 짧은 순으로 보여주는 이 방법을 시도해 보세요. 예를 들어 내 시스템에서

3min 49.219s systemd-cryptsetup@luks\x2d62611c1c\x2d74ab\x2d4be9\x2d8990\x2d41c0fd863b5a.service
      5.315s plymouth-quit-wait.service
      3.084s systemd-udev-settle.service
      2.275s plymouth-start.service
      2.256s docker.service
      1.819s powertop.service
       778ms firewalld.service
       676ms dev-mapper-fedora\x2droot.device
       621ms abrtd.service
       493ms lvm2-monitor.service

내 노트북을 부팅하는 데 4분이 걸리는 것 같습니다. 그 중 3분은 암호화된 드라이브가 있기 때문입니다.

마지막으로 systemd-analyze critical-chain시스템 시작에 "중요"하다고 간주되는 이벤트 목록을 볼 수 있습니다. ~에서매뉴얼 페이지중요란 "시간에 민감한 장치 체인"을 의미합니다. 이는 systemd가 많은 서비스를 병렬화하기 때문입니다. 여기에는 다른 장치를 기다려야 하는 장치와 시작하는 데 걸리는 시간이 나열됩니다.

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 @10.336s
└─multi-user.target @10.323s
  └─docker.service @4.900s +2.256s
    └─network.target @4.868s
      └─wpa_supplicant.service @4.828s +14ms
        └─dbus.service @3.753s
          └─basic.target @3.749s
            └─sockets.target @3.749s
              └─docker.socket @3.741s +6ms
                └─sysinit.target @3.737s
                  └─systemd-update-utmp.service @3.726s +10ms
                    └─auditd.service @3.713s +9ms
                      └─systemd-tmpfiles-setup.service @3.617s +82ms
                        └─fedora-import-state.service @3.568s +36ms
                          └─local-fs.target @3.560s
                            └─run-user-42.mount @5.753s
                              └─local-fs-pre.target @383ms
                                └─systemd-tmpfiles-setup-dev.service @301ms +80ms
                                  └─kmod-static-nodes.service @268ms +10ms
                                    └─system.slice
                                      └─-.slice

부트스트랩 트리를 그림으로 내보내 이메일로 보내거나 svg를 사용하여 그림을 그려 멋진 작업을 수행할 수도 있습니다. 자세한 내용은 매뉴얼 페이지를 참조하거나이 관련 질문자세한 내용을 알아보세요.

Answer

CentOS 7+ 또는 Ubuntu 15.04+를 사용하고 있다고 가정합니다. 둘 다 systemd와 함께 제공됩니다. Systemd에는 시스템 부팅에 걸리는 시간을 계산하는 몇 가지 훌륭한 도구와 그 이유를 이해하는 몇 가지 시각화 도구가 있습니다.

가장 기본적인 출력의 경우 실행하면 systemd-analyze다음과 같은 멋진 요약을 얻을 수 있습니다.

Startup finished in 853ms (kernel) + 3min 50.610s (initrd) + 10.345s (userspace) = 4min 1.809s

이는 마지막으로 시작된 이후 시스템을 시작하는 데 걸린 시간을 알려줍니다. 이는 BIOS/하드웨어 초기화 또는 GRUB 시간 초과를 고려하지 않지만 실제 운영 체제 부팅 시간에 대해서는 정확해야 합니다.

운영 체제가 왜 그렇게 오래 걸리는지 알아내려면 systemd-analyze blame가장 오래 실행되는 서비스의 그래프를 가장 짧은 순으로 보여주는 이 방법을 시도해 보세요. 예를 들어 내 시스템에서

3min 49.219s systemd-cryptsetup@luks\x2d62611c1c\x2d74ab\x2d4be9\x2d8990\x2d41c0fd863b5a.service
      5.315s plymouth-quit-wait.service
      3.084s systemd-udev-settle.service
      2.275s plymouth-start.service
      2.256s docker.service
      1.819s powertop.service
       778ms firewalld.service
       676ms dev-mapper-fedora\x2droot.device
       621ms abrtd.service
       493ms lvm2-monitor.service

내 노트북을 부팅하는 데 4분이 걸리는 것 같습니다. 그 중 3분은 암호화된 드라이브가 있기 때문입니다.

마지막으로 systemd-analyze critical-chain시스템 시작에 "중요"하다고 간주되는 이벤트 목록을 볼 수 있습니다. ~에서매뉴얼 페이지중요란 "시간에 민감한 장치 체인"을 의미합니다. 이는 systemd가 많은 서비스를 병렬화하기 때문입니다. 여기에는 다른 장치를 기다려야 하는 장치와 시작하는 데 걸리는 시간이 나열됩니다.

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 @10.336s
└─multi-user.target @10.323s
  └─docker.service @4.900s +2.256s
    └─network.target @4.868s
      └─wpa_supplicant.service @4.828s +14ms
        └─dbus.service @3.753s
          └─basic.target @3.749s
            └─sockets.target @3.749s
              └─docker.socket @3.741s +6ms
                └─sysinit.target @3.737s
                  └─systemd-update-utmp.service @3.726s +10ms
                    └─auditd.service @3.713s +9ms
                      └─systemd-tmpfiles-setup.service @3.617s +82ms
                        └─fedora-import-state.service @3.568s +36ms
                          └─local-fs.target @3.560s
                            └─run-user-42.mount @5.753s
                              └─local-fs-pre.target @383ms
                                └─systemd-tmpfiles-setup-dev.service @301ms +80ms
                                  └─kmod-static-nodes.service @268ms +10ms
                                    └─system.slice
                                      └─-.slice

부트스트랩 트리를 그림으로 내보내 이메일로 보내거나 svg를 사용하여 그림을 그려 멋진 작업을 수행할 수도 있습니다. 자세한 내용은 매뉴얼 페이지를 참조하거나이 관련 질문자세한 내용을 알아보세요.

Question 2

7년 4개월 전 질문

그것은 다음에 달려있을 것이다섬기는 사람BIOS/EFI 초기화 및 기타 작업 중에 소요될 수 있는 시간뿐만 아니라RAID 디스크 초기화;이 두 가지는 제가 경험한 이름 중 가장 큰 이름입니다. 그러나 Linux와 관련이 없는 시간이 걸리는 다른 일이 발생할 수도 있습니다.

RHEL/Centos 7 이상은 일반적으로 부팅 중에 네트워크를 기다리는 시스템에서 정지됩니다. 직장에 있고 기업 인터넷이 있는 경우 때로는 네트워크 스위치/라우터가 서버에 DHCP IP 주소를 즉시 부여하지 않아 서버에 문제가 발생할 수 있습니다. 적어도 30초 동안 말이죠.

예상 재부팅 시간을 확인하는 가장 쉬운 방법은 SSH를 통해 putty를 입력한 다음 "reboot"를 입력하는 것입니다. 해당 시점부터 시간을 표시 reboot <enter>하고 다른 창에서 시작하여 ping myserver응답을 받을 때까지 기다리세요. 차이점은 예상 시간에 있습니다. 많이 해보고 얼마나 바뀌는지 확인하세요.

ping이 응답하기 시작하면 SSH 및 GDM과 같은 다른 서비스가 아직 시작되지 않았기 때문에 반드시 즉시 로그인할 수 있다는 의미는 아니지만 일반적으로 약 5초 내에 시작되지만 성공적으로 로그인할 수 있는지 간단히 알 수 있습니다. 그런 다음 성공적인 로그인부터 다시 시작한 후 Enter를 누른 시간이 귀하의 시간입니다.

reboot또한 데이터를 디스크에 기록해야 하거나 일부 NFS 서비스가 시간 초과되어야 하는 경우 입력 후 종료할 때 눈에 띄는 지연이 발생할 수 있습니다.

종료 및 시작 프로세스 중에 시간이 많이 걸릴 수 있는 합법적인 일이 많이 발생합니다. XFS를 사용하는 RHEL 7/8과 달리 SLES 11.4, EXT4 파일 시스템을 사용하면 fsck has not been run in ~30 days일부 cr@p가 발생하므로 서버가 100일 이상 재부팅되지 않은 경우(드물지 않은 일임) 부팅 시 fsck가 실행됩니다. 거대한 회전 디스크이므로 30분 정도 걸릴 수 있습니다.

내 경험에 따르면 일반적으로 5분 미만이 예상됩니다. 서버 BIOS 및 디스크 RAID의 경우 약 3분, RHEL 7/8의 grub 메뉴에서 Linux의 경우 1:30 미만입니다. 10분이 지나면 서버실로 가서 콘솔(또는 IPMI나 iDRAC를 통해)에서 무슨 일이 일어나고 있는지 살펴봅니다.

Answer