您的位置:首頁 > 系統軟件

                                            Linux 啟動性能分析

                                            發布時間:2022-04-13 22:59:24  來源:IT資訊網    采編:author  背景:

                                            系統管理員的一部分工作就是分析系統性能,發現并解決引起性能不佳、啟動時間長的問題。系統管理員也需要去檢查 systemd 的配置和使用的其它方面。

                                            systemd 初始化系統提供了 systemd-analyze 工具,可以幫助發現性能問題和其他重要的 systemd 信息。在以前的文章《??分析

                                            systemd 日歷和時間跨度??》里,我用了 systemd-analyze 去分析 systemd

                                            里的時間戳和時間跨度,但是這個工具還有很多其他用法,這個文章里我將再揭示一些。

                                            (LCTT 譯注:systemd 是目前主流 Linux 發行版采用的系統管理系統)

                                            (LCTT 譯注:為了區分英文的 “boot” 和 “startup” 的不同涵義,此處將 “boot” 翻譯為“引導”,“startup”

                                            翻譯為“啟動”。)

                                            概述啟動

                                            Linux 啟動過程是值得學習關注的地方,因為 systemd-analyze

                                            工具很多功能聚焦在啟動startup過程。但是首先,要理解引導boot和啟動startup。引導階段從 BIOS

                                            加電自檢(POST)開始,結束于內核完成加載并控制主機系統,然后是開始了啟動過程,也是 systemd 日志的開始點。

                                            這個系列的第二篇文章《??理解 Linux 啟動時的

                                            systemd??》中,我詳細討論了啟動階段的內容和過程。在這篇文章里,我想研究一下啟動過程,看看需要多少時間和大部分時間花費在哪里。

                                            下面我將展示的結果來自我的主要工作站,這比虛擬機的結果要有趣得多。這個工作站包括一塊 華碩 TUF X299 Mark 2 主板、一個英特爾

                                            i9-7960X CPU(16 核 32 線程),64 G 內存。下面的一些命令非 root 用戶也可以使用,但是我在這篇文章里使用了 root

                                            用戶,以避免在用戶之間切換。

                                            檢查啟動過程有幾種方法,最簡單的 systemd-analyze 命令顯示了啟動的幾個主要部分耗費的時間,包括內核啟動、裝載運行 initrd(即初始

                                            ramdisk,這是一個用來初始化一些硬件、掛載 /

                                            根文件系統的臨時系統鏡像),還有用戶空間(加載所有使主機達到可用狀態的程序和守護程序)。如果沒有像該命令傳遞子命令,默認是 systemd-analyze

                                            time:

                                            [root@david ~]$ systemd-analyzeStartup finished in 53.921s (firmware) + 2.643s (loader) + 2.236s (kernel) + 4.348s (initrd) + 10.082s (userspace) = 1min 13.233sgraphical.target reached after 10.071s in userspace[root@david ~]#

                                            這個輸出中最值得注意的數據是在固件(BIOS)中花費的時間:幾乎 54 秒。這是一個不太正常的時間,我的其他物理系統都沒有花費這么長的時間來通過

                                            BIOS。

                                            我的 System76 Oryx Pro 筆記本在 BIOS 階段只花了 8.506 秒,我家里所有的系統都在 10

                                            秒以內。在線搜索一陣之后,我發現這塊主板以其超長的 BIOS 引導時間而聞名。我的主板從不“馬上啟動”,總是掛起,我需要關機再開機,BIOS 報錯,按 F1

                                            進入 BIOS 設置,選擇要引導的驅動器完成引導,多花費的時間就是這樣用掉的。

                                            不是所有主機都會顯示固件數據(LCTT 譯注:固件引導中不涉及 systemd)。我的不科學的實驗使我相信,這個數據只顯示給英特爾 9

                                            代或以上的處理器。但這可能是不正確的。

                                            這個關于引導、啟動的概述提供了很好的(雖然有限)的信息,但是還有很多關于啟動的信息,我將在下面描述。

                                            分配責任

                                            你可以用 systemd-analyze blame 來發現哪個 systemd 單元的初始化時間最長。其結果按照初始化時間長短排序,從多到少:

                                            [root@david ~]$ systemd-analyze blame 5.417s NetworkManager-wait-online.service 3.423s dracut-initqueue.service 2.715s systemd-udev-settle.service 2.519s fstrim.service 1.275s udisks2.service 1.271s smartd.service 996ms upower.service 637ms lvm2-monitor.service 533ms lvm2-pvscan@8:17.service 520ms dmraid-activation.service 460ms vboxdrv.service 396ms initrd-switch-root.service<截斷:刪去了好多時間不長的條目>

                                            因為很多服務是并行開始的,在 BIOS 之后所有單元加在一起的總數大大超過了 systemd-analyze time

                                            匯總數。很多都是小數,不能顯著的節省時間。

                                            這個命令提供的數據指明了改善啟動時間的辦法。無用的服務可以禁用(disable)。在這個啟動過程中,似乎沒有任何一個服務需要花費過長的時間。你可能會在每次啟動時看到不同的結果。(LCTT

                                            譯注:并行啟動服務的原因)

                                            關鍵鏈

                                            就像項目管理中的關鍵路徑一樣,關鍵鏈顯示了在啟動過程中發生的時間關鍵的事件鏈(LCTT 譯注:systemd

                                            可以定義服務間的依賴,構成關鍵鏈)。如果啟動緩慢,這些是你想查看的 systemd

                                            單元,因為它們是導致延遲的單元。這個工具不會顯示所有啟動的單元,只顯示這個關鍵事件鏈中的單元。(LCTT

                                            譯注:相當于最短路徑。并不顯示依賴不在關鍵鏈上的服務單元)

                                            [root@david ~]# systemd-analyze critical-chainThe time when unit became active or started is printed after the "@" character.The time the unit took to start is printed after the "+" character.graphical.target @10.071s└─lxdm.service @10.071s └─plymouth-quit.service @10.047s +22ms └─systemd-user-sessions.service @10.031s +7ms └─remote-fs.target @10.026s └─remote-fs-pre.target @10.025s └─nfs-client.target @4.636s └─gssproxy.service @4.607s +28ms └─network.target @4.604s └─NetworkManager.service @4.383s +219ms └─dbus-broker.service @4.434s +136ms └─dbus.socket @4.369s └─sysinit.target @4.354s └─systemd-update-utmp.service @4.345s +9ms └─auditd.service @4.301s +42ms └─systemd-tmpfiles-setup.service @4.254s +42ms └─import-state.service @4.233s +19ms └─local-fs.target @4.229s └─Virtual.mount @4.019s +209ms └─systemd-fsck@dev-mapper-vg_david2\x2dVirtual.service @3.742s +274ms └─local-fs-pre.target @3.726s └─lvm2-monitor.service @356ms +637ms └─dm-event.socket @319ms └─-.mount └─system.slice └─-.slice[root@david ~]#

                                            前面有 @ 的數字表示單元激活開始啟動所使用的絕對秒數。前面有 + 的數字顯示單元啟動所需的時間。

                                            系統狀態

                                            有時候你需要確定系統的當前狀態,systemd-analyze dump 命令轉儲了當前系統狀態的大量數據。有主要的啟動時間戳,一個每個 systemd

                                            單元的列表,并對每個單元狀態進行了完整描述:

                                            [root@david ~]# systemd-analyze dumpTimestamp firmware: 1min 7.983523sTimestamp loader: 3.872325sTimestamp kernel: Wed 2020-08-26 12:33:35 EDTTimestamp initrd: Wed 2020-08-26 12:33:38 EDTTimestamp userspace: Wed 2020-08-26 12:33:42 EDTTimestamp finish: Wed 2020-08-26 16:33:56 EDTTimestamp security-start: Wed 2020-08-26 12:33:42 EDTTimestamp security-finish: Wed 2020-08-26 12:33:42 EDTTimestamp generators-start: Wed 2020-08-26 16:33:42 EDTTimestamp generators-finish: Wed 2020-08-26 16:33:43 EDTTimestamp units-load-start: Wed 2020-08-26 16:33:43 EDTTimestamp units-load-finish: Wed 2020-08-26 16:33:43 EDTTimestamp initrd-security-start: Wed 2020-08-26 12:33:38 EDTTimestamp initrd-security-finish: Wed 2020-08-26 12:33:38 EDTTimestamp initrd-generators-start: Wed 2020-08-26 12:33:38 EDTTimestamp initrd-generators-finish: Wed 2020-08-26 12:33:38 EDTTimestamp initrd-units-load-start: Wed 2020-08-26 12:33:38 EDTTimestamp initrd-units-load-finish: Wed 2020-08-26 12:33:38 EDT-> Unit system.slice: Description: System Slice Instance: n/a Unit Load State: loaded Unit Active State: active State Change Timestamp: Wed 2020-08-26 12:33:38 EDT Inactive Exit Timestamp: Wed 2020-08-26 12:33:38 EDT Active Enter Timestamp: Wed 2020-08-26 12:33:38 EDT Active Exit Timestamp: n/a Inactive Enter Timestamp: n/a May GC: no<截斷:刪除了大量的輸出行>

                                            在我的主工作站上,這個命令生成了 49680 行輸出,大概 1.66MB,這個命令非???,不需要等待。

                                            我很喜歡為各種連接設備(如存儲設備)提供的大量細節。每個 systemd

                                            單元有一個部分,包括各種運行時、緩存、日志目錄的模式、啟動單元的命令行、PID、開始時間戳,以及內存和文件限制等細節。

                                            systemd-analyze 的手冊頁里展示了 systemd-analyze --user dump

                                            選項,目的是顯示用戶管理器的內部狀態。但這個選項對我來說是失敗的,互聯網搜索之后表明它可能有一些問題。在 systemd 里,--user

                                            實例用來管理和控制處理器給每個用戶的進程資源。處理能力按分給每個用戶的進程都屬于一個控制組,我將在以后的文章中介紹。

                                            分析圖表

                                            大多數啥都不懂的猥瑣老板(PHB)和許多優秀的管理者都發現漂亮的圖表比我通常喜歡的基于文本的系統性能數據更容易閱讀和理解。但有時,即使是我也喜歡一個好的圖表,systemd-analyze

                                            提供了顯示引導/啟動數據的 SVG 矢量圖表。

                                            下面的命令生成一個矢量圖文件,來顯示在引導和啟動過程發生的事件。生成這個文件只需要幾秒:

                                            [root@david ~]# systemd-analyze plot > /tmp/bootup.svg

                                            這個命令創建了一個 SVG 文件,SVG 是一個定義了一系列圖形矢量的文本文件,包括 Image Viewer、Ristretto、Okular、Eye

                                            of Mate、LibreOffice Draw 在內的這些可以生成圖形的應用,可以用 SVG 來創建圖像。

                                            我用 LibreOffice Draw(LCTT

                                            譯注:一個辦公文檔軟件)來渲染一幅圖形。這張圖形很大,你需要放到很大才能看清細節。這里是它的一小部分:

                                            The bootup.svg file displayed in LibreOffice

                                            Draw.

                                            圖中時間軸上零點(0)的左邊是引導階段,零點的右邊是啟動階段。這一小部分顯示了內核、initrd 和 initrd 啟動的進程。

                                            這張圖一目了然地顯示了什么時候啟動,啟動需要多少時間,以及主要的依賴項。關鍵路徑用紅色高亮顯示。

                                            另外一個生成圖形輸出的命令是 systemd-analyze plot,它生成了 DOT 格式的文本依賴圖。產生的數據流通過 dot

                                            工具進行處理,這是一組用來從多種類型數據中生成矢量圖文件的程序。這些 SVG 文件也能被上面列出的工具處理。

                                            首先,生成文件,在我的主工作站花了 9 分鐘:

                                            [root@david ~]# time systemd-analyze dot | dot -Tsvg > /tmp/test.svg Color legend: black = Requires dark blue = Requisite dark grey = Wants red = Conflicts green = Afterreal 8m37.544suser 8m35.375ssys 0m0.070s[root@david ~]#

                                            我不會在這里重現輸出,因為產生的圖形就像一大堆意大利面條。但是你應該試試,看看我想讓你看到的結果。

                                            條件

                                            在閱讀 systemd-analyze(1)

                                            的手冊頁時,我發現了一個更有趣的功能,但又有點通用,就是條件子命令。(是的,我確實在讀手冊頁,而且我神奇地通過這種方式學到了很多東西!)。這個

                                            condition 子命令能用來測試 systemd 單元文件中的條件和斷言。

                                            它也可以在腳本中用來評估一個或多個條件 —— 如果所有條件都滿足,則返回 0;如果有條件不滿足,則返回 1。在其它情況下,它都會輸出其結果文本。

                                            下面的例子來自手冊頁,稍微有點復雜。它測試了內核版本是否在 4.0 和 5.1 之間,主機是否使用交流電供電,系統結構是否是 ARM,以及

                                            /etc/os-release 目錄是否存在。我添加了 echo $? 來打印返回值。

                                            [root@david ~]# systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \ 'ConditionKernelVersion = >=5.1' \ 'ConditionACPower=|false' \ 'ConditionArchitecture=|!arm' \ 'AssertPathExists=/etc/os-release' ; \echo $?test.service: AssertPathExists=/etc/os-release succeeded.Asserts succeeded.test.service: ConditionArchitecture=|!arm succeeded.test.service: ConditionACPower=|false failed.test.service: ConditionKernelVersion=>=5.1 succeeded.test.service: ConditionKernelVersion=!<4.0 succeeded.Conditions succeeded.0[root@david ~]#

                                            條件和斷言的列表大約從 systemd.unit(5) 手冊頁的第 600 行左右開始。

                                            列出配置文件

                                            systemd-analyze 工具提供了一種將各種配置文件的內容發送到 STDOUT 的方法,如圖所示。其基本目錄是 /etc/。

                                            [root@david ~]# systemd-analyze cat-config systemd/system/display-manager.service# /etc/systemd/system/display-manager.service[Unit]Description=LXDM (Lightweight X11 Display Manager)#Documentation=man:lxdm(8)Conflicts=getty@tty1.serviceAfter=systemd-user-sessions.service getty@tty1.service plymouth-quit.service livesys-late.service#Conflicts=plymouth-quit.service[Service]ExecStart=/usr/sbin/lxdmRestart=alwaysIgnoreSIGPIPE=no#BusName=org.freedesktop.lxdm[Install]Alias=display-manager.service[root@david ~]#

                                            打了這么多字卻和標準的 cat 命令做的差不多。我發現下一條命令小有幫助,它能在標準的 systemd 所在的位置搜索具有指定模式的內容:

                                            [root@david ~]# systemctl cat backup*# /etc/systemd/system/backup.timer# This timer unit runs the local backup program# (C) David Both# Licensed under GPL V2#[Unit]Description=Perform system backupsRequires=backup.service[Timer]Unit=backup.serviceOnCalendar=*-*-* 00:15:30[Install]WantedBy=timers.target# /etc/systemd/system/backup.service# This service unit runs the rsbu backup program# By David Both# Licensed under GPL V2#[Unit]Description=Backup services using rsbuWants=backup.timer[Service]Type=oneshotEnvironment="HOME=/root"ExecStart=/usr/local/bin/rsbu -bvd1ExecStart=/usr/local/bin/rsbu -buvd2[Install]WantedBy=multi-user.target[root@david ~]#

                                            這兩個命令在每個文件的內容前面都有一個注釋行,包含文件的完整路徑和名稱。

                                            單元文件檢查

                                            當創建了一個新的單元文件,可以利用 verify 子命令幫助檢查語法是否正確。它能指出來不正確的拼寫,并列出缺失的服務單元。

                                            [root@david ~]# systemd-analyze verify /etc/systemd/system/backup.service

                                            秉承 Unix/Linux 的“沉默是金”的宗旨,沒有輸出意味著掃描的文件中沒有錯誤。

                                            安全性

                                            security 子命令檢查指定服務的安全級別。它只能針對服務單元,其他類型的單元文件不起作用:

                                            [root@david ~]# systemd-analyze security display-manager NAME DESCRIPTION >? PrivateNetwork= Service has access to the host's network >? User=/DynamicUser= Service runs as root user >? CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities >? CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges >? CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace() debugging abilities >? RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets >? RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces >? RestrictAddressFamilies=~… Service may allocate exotic sockets >? CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unres>? CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks >? CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges >? CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules<截斷>? CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup() >? CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system >? RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets >→ Overall exposure level for backup.service: 9.6 UNSAFE ?lines 34-81/81 (END)

                                            是的,表情符是輸出的一部分。但是,當然,許多服務需要幾乎完全訪問所有的東西,以便完成它們的工作。我針對幾個服務運行了這個程序,包括我自己的備份服務;結果可能有所不同,但最底下一行似乎大多是一樣的。

                                            這個工具對于在嚴格的安全環境檢查和修復用戶空間的服務單元是很有用的。我不認為我們的大多數都能用到它。

                                            最后總結

                                            這個強力的工具提供了一些有趣而驚人的有用選項。本文探討的大部分內容是關于使用 systemd-analyze 來深入了解 Linux 使用 systemd

                                            的啟動性能。它還可以分析 systemd 的其他方面。

                                            其中有些工具的作用有限,有幾個應該完全忘記。但在解決啟動和其他 systemd 功能的問題時,大多數都能起到很好的作用。

                                              聲明:本文僅為傳遞更多網絡信息,不代表IT資訊網觀點和意見,僅供參考了解,更不能作為投資使用依據。


                                            返回網站首頁 本文來源:IT資訊網

                                            本文評論
                                            快速排序算法的深入分析
                                            那么現在,我就來徹底分析下此快速排序算法,希望能讓讀者
                                            日期:03-10
                                            新款Mac也能安裝Windows了!還干掉了Surface?
                                            在前幾天,macOS 最強虛擬機軟件 Parallels Desktop,它們
                                            日期:02-11
                                            白帽黑客展示新技術,僅需換一條數據線就能遠程操控你的電腦
                                            近日,一位白帽黑客在自己的社交賬號上分享了一則視頻。
                                            日期:03-29
                                            2022年首月數據出爐:運營商虎年喜迎“開門紅”
                                            作為2022年第一張“月考”成績單,三家運營商共同迎來了
                                            日期:02-23
                                            基于K8S,云原生架構的成本優化指南
                                            我們這次主要討論公有云的服務器成本優化和服務器利用
                                            日期:04-07
                                            運維如何才能不背鍋?這份災備秘籍了解一下
                                            運維要想不背鍋,就需要從掌握災備知識做起。不管你是西
                                            日期:04-05
                                            MegaMIMO系統讓WiFi提速10倍
                                            在近日發表的一篇新研究論文中,美國麻省理工學院的工程
                                            日期:04-03
                                            數字音樂多元時代,“高潮挑歌”劍指何處?
                                            全新推出的殺手锏神器“高潮挑歌”,可謂一舉兩得。既解
                                            日期:03-03
                                            管理即服務?不要小看云計算的能力
                                            管理即服務可以為企業提供一些關鍵的優勢,比如降低成本
                                            日期:02-13
                                            2022年的五大網絡安全挑戰
                                            2022年將是“構建更大彈性并將其整合到業務運營的各個
                                            日期:01-24
                                            切換到托管Kubernetes的六個理由
                                            托管Kubernetes服務已經成熟到許多企業將密鑰移交給他
                                            日期:03-05
                                            Windows 10 RS2截圖曝光:開始菜單很Windows 7
                                            Windows操作系統已經與我們的工作和生活密不可分,一直
                                            日期:04-04
                                             

                                            精品无码久久午夜福利