ZDNET을 팔로우하세요: 우리를 선호 소스로 추가하세요 Google에서.
ZDNET의 주요 시사점
- Linux 시스템의 부팅 속도가 느린 경우 이 도구를 사용해 보세요.
- Systemd-analyze는 도움이 되는 몇 가지 옵션을 제공합니다.
- 시스템을 지원하는 모든 Linux 시스템에는 이러한 기능이 있습니다.
Linux에는 올바른 것, 잘못된 것, 그 사이의 모든 것을 찾아내는 데 도움이 되는 수많은 유용한 도구가 있습니다. 원하는 대로 사용자 정의하거나 그대로 둘 수 있습니다.
어떤 시점에서는 Linux 시스템의 부팅 시간을 늦추는 원인이 무엇인지 궁금할 수 있습니다. 어려운 작업처럼 들릴 수도 있지만 실제로는 얼마나 쉬운지 놀라실 것입니다. 실제로 Linux에는 이를 수행하는 데 도움이 되는 도구가 내장되어 있습니다.
또한: 귀하에게 적합한 Linux 데스크탑 배포판을 선택하는 방법
Linux 배포판이 systemd init 시스템을 사용하는 경우 느린 부팅 시간 문제를 해결하는 데 필요한 것이 이미 있는 것이므로 도구 사용 방법을 보여 드리겠습니다.
시스템 분석
문제의 도구는 systemd init 시스템의 일부이며 systemd-analyze라고 합니다. 이 도구가 하는 일은 Linux의 초기화 관리자를 분석하고 디버그하는 것입니다.
단순히 명령을 실행한다면 시스템 분석다음과 같은 결과가 표시됩니다.
6.669초(커널) + 30.368초(사용자 공간) = 37.037초 내에 시작 완료
사용자 공간에서 27.479초 후에 graphic.target에 도달했습니다.
위에서 볼 수 있듯이 내 컴퓨터 중 하나의 총 시작 시간은 37.037초이며, 커널의 경우 6.669초, 사용자 공간 앱의 경우 30.368초입니다. 그런 다음 27.479초에 graphic.target에 도달했습니다(로그인 화면).
또한: MacOS나 Windows에서는 할 수 없지만 Linux로는 할 수 있는 8가지
꽤 좋은 정보이긴 하지만 실제로는 별로 도움이 되지 않습니다. 좋은 소식은 무슨 일이 일어나고 있는지 파악하는 데 도움이 되는 몇 가지 중요한 옵션이 있다는 것입니다.
탓하다
첫 번째 옵션은 Blame으로, 모든 시스템 장치 파일을 나열하여 마지막 부팅 중에 각 장치를 초기화하는 데 걸린 시간을 가장 긴 것부터 가장 짧은 것 순으로 표시합니다. 비난 옵션은 시작 시 지연을 일으키는 서비스를 식별하는 데 유용합니다.
비난 옵션은 다음과 같이 사용됩니다.
systemd-분석 비난
결과는 다음과 같습니다.
57.158s apt-daily.service
20.879s apt-daily-upgrade.service
17.609s snapd.service
10.647s docker.service
7.217s snapd.seed.service
4.772초 fstrim.service
4.160s dev-sda2.device
3.824s motd-news.service
3.756s cloud-init-local.service
3.369s cloud-config.service
3.173s snap.lxd.activate.service
2.932초 컨테이너d.service
2.877s cloud-final.service
2.677s systemd-udev-settle.service
2.498초 cloud-init.service
2.125s networkd-dispatcher.service
2.051s man-db.service
보시다시피 apt-daily.service는 가장 많은 시간을 소비하는 시스템 단위입니다. 그 단위는 무엇입니까? apt-daily.service 유닛은 Debian 기반 Linux 배포판의 소프트웨어 업데이트를 매일 자동으로 확인하는 일을 담당합니다.
또한: 집에서 리눅스를 사용해야 하는 가장 중요한 이유
apt-daily.service를 중지할 수는 있지만 권장하지는 않습니다. systemd-analyze Blame으로 생성된 목록을 살펴보고 부팅 속도를 높이기 위해 안정적이고 안전하게 비활성화할 수 있는 서비스가 있는지 확인할 수 있습니다.
중요한 사슬
중요한 체인 옵션은 부팅 프로세스를 심각하게 느리게 만든 장치 체인을 표시합니다. 이 옵션은 종속성 체인의 병목 현상을 찾아내는 데 도움이 됩니다. 출력에서 장치가 활성화되는 시간은 @ 문자 뒤에 인쇄되고, 장치가 시작하는 데 걸린 시간은 + 문자 뒤에 인쇄됩니다.
핵심 체인의 출력은 다음과 같습니다.
graphic.target @27.479s
└─다중 사용자.대상 @27.478s
└─docker.service @16.830s +10.647s
└─containerd.service @13.891s +2.932s
└─dbus.service @13.869s
└─basic.target @13.796s
└─sockets.target @13.794s
└─snapd.socket @13.745s +44ms
└─sysinit.target @13.659s
└─cloud-init.service @11.149s +2.498s
└─systemd-networkd-wait-online.service @10.024s +1.118s
└─systemd-networkd.service @9.838s +180ms
└─network-pre.target @9.832s
└─cloud-init-local.service @6.073s +3.756s
└─systemd-remount-fs.service @1.434s +174ms
└─systemd-journald.socket @1.147s
└─system.slice @1.067s
└─-.slice @1.067s
보시다시피, 이 시스템(Ubuntu Server 시스템)에서 병목 현상을 일으킬 수 있는 두 가지 서비스는 docker.service 및 Containerd.service입니다. 부팅 시간을 단축하려면 부팅 시 해당 서비스를 비활성화하고 수동으로 시작할 수 있습니다.
구성
마지막으로 부팅 프로세스 및 관련 종속성을 시각적으로 나타내는 .svg(확장 가능한 벡터 그래픽) 파일을 생성하는 플롯이 있습니다. 파일이 생성되면 SVG 파일을 지원하는 웹 브라우저나 이미지 뷰어에서 열 수 있습니다.
이에 대한 명령은 다음과 같습니다.
systemd-분석 플롯 > boot.svg
그러면 현재 작업 디렉터리에서 .svg 파일을 찾을 수 있습니다. 대부분의 웹 브라우저는 파일 형식을 지원하고 이미지가 다소 클 수 있으므로 웹 브라우저에서 파일을 여는 것이 좋습니다.
이미지 파일은 용량이 클 수 있습니다.
잭 월렌/ZDNET
또한: Wine을 사용하여 Linux에서 Windows 앱을 실행하는 방법
내 샘플에서 볼 수 있듯이 약 18초가 되면 대부분의 애플리케이션과 서비스가 초기화되기 시작합니다.
systemd-analyze 도구는 가지고 다니기에 편리합니다. 이를 통해 시스템이 예상보다 느리게 부팅되는 문제 해결을 시작할 수 있습니다.