システム管理者の仕事の一部は、システムのパフォーマンスを分析し、パフォーマンスの低下と長い起動時間の原因となる問題を見つけて解決することです。システム管理者は、systemdの構成と使用法の他の側面も確認する必要があります。
systemd initシステムは、systemd-analyze
を提供します パフォーマンスの問題やその他の重要なsystemd情報を明らかにするのに役立つツール。前回の記事では、systemdカレンダーとタイムスパンの分析 、systemd-analyze
を使用しました systemdタイマーのタイムスタンプとタイムスパンを分析しますが、このツールには他にも多くの用途があり、その一部についてはこの記事で説明します。
多くのsystemd-analyze
があるため、Linuxの起動シーケンスは探索を開始するのに適した場所です。 ツール機能は起動を対象としています。ただし、最初に、起動と起動の違いを理解することが重要です。起動シーケンスは、BIOS電源投入時自己診断(POST)で始まり、カーネルのロードが終了してホストシステムを制御するときに終了します。これは、起動の開始であり、systemdジャーナルが開始する時点です。
このシリーズの2番目の記事では、Linuxでの起動時のsystemdについて 、何がどのような順序で発生するかについて、スタートアップについてもう少し詳しく説明します。この記事では、起動シーケンスを調べて、起動にかかる時間と最も時間がかかるタスクを確認したいと思います。
以下に示す結果は、プライマリワークステーションからのものであり、仮想マシンの結果よりもはるかに興味深いものです。このワークステーションは、ASUS TUF X299 Mark 2マザーボード、16コアと32 CPU(スレッド)を備えたIntel i9-7960X CPU、および64GBのRAMで構成されています。以下のコマンドの一部はroot以外のユーザーでも実行できますが、この記事ではrootを使用して、ユーザーを切り替える必要がないようにします。
起動シーケンスを調べるには、いくつかのオプションがあります。 systemd-analyze
の最も単純な形式 コマンドは、起動、カーネルの起動、initrd
のロードと実行の各主要セクションで費やされた時間の概要を表示します。 (つまり、初期ramdisk、一部のハードウェアを初期化して/
をマウントするために使用される一時的なシステムイメージ [root]ファイルシステム)、およびユーザースペース(ホストを使用可能な状態にするために必要なすべてのプログラムとデーモンがロードされます)。コマンドにサブコマンドが渡されない場合は、systemd-analyze time
暗示される:
[root @ david〜] $ systemd-analyze
起動は53.921秒(ファームウェア)+ 2.643秒(ローダー)+ 2.236秒(カーネル)+ 4.348秒(初期)+ 10.082秒(ユーザースペース)で終了しました=1分13.233秒
graphical.targetがユーザースペースで10.071秒後に到達しました
[root@ david〜]#
この出力で最も注目すべきデータは、ファームウェア(BIOS)で費やされた時間(約54秒)です。これは非常に長い時間であり、他のどの物理システムもBIOSを通過するのにこれほど長い時間はかかりません。
私のSystem76OryxProラップトップはBIOSでわずか8.506秒しか費やさず、すべての自作システムは10秒より少し短い時間で済みます。いくつかのオンライン検索の結果、このマザーボードはBIOSの起動時間が非常に長いことで知られていることがわかりました。私のマザーボードは「起動するだけ」ではありません。常にハングし、電源のオフ/オンを繰り返す必要があります。その後、BIOSがエラーで起動し、F1を押してBIOS構成に入り、そこからブートドライブを選択してブートを終了する必要があります。これが延長戦の源です。
すべてのホストがファームウェアデータを表示するわけではありません。私の非科学的な実験から、このデータはIntel第9世代以降のプロセッサでのみ表示されていると思います。しかし、それは正しくない可能性があります。
起動起動プロセスのこの概要は興味深いものであり、優れた(限定的ではありますが)情報を提供しますが、以下で説明するように、起動に関して利用できる情報ははるかに多くあります。
systemd-analyze blame
を使用できます 初期化に最も時間がかかるsystemdユニットを検出します。結果は、初期化にかかる時間の大きいものから小さいものの順に表示されます。
5.417sにNetworkManager-待機online.service
3.423sドレーカット-initqueue.service
2.715sにsystemd-のudev-沈降。サービス
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-スイッチroot.service
これらのサービスの多くは並行して開始されるため、この数値は、systemd-analyze time
で指定された合計よりも大幅に多くなる可能性があります。 BIOS以降のすべてに。これらはすべて少数であるため、ここで大幅な節約を見つけることはできません。
このコマンドのデータは、起動時間を改善するために検討する可能性のあるサービスに関する指標を提供できます。使用されていないサービスは無効にすることができます。この起動シーケンス中に過度に長い時間がかかっている単一のサービスはないようです。起動と起動ごとに異なる結果が表示される場合があります。
プロジェクト管理のクリティカルパスのように、クリティカルチェーン は、起動時に発生するタイムクリティカルなイベントのチェーンを示しています。これらは、遅延の原因となるユニットであるため、起動が遅い場合に確認したいsystemdユニットです。このツールは、開始するすべてのユニットを表示するのではなく、このクリティカルチェーンのイベント内のユニットのみを表示します:
[root @ david〜]#systemd-analyzecritical-chain
ユニットがアクティブまたは開始した時刻は、「@」文字の後に印刷されます。
ユニットの起動にかかった時間は印刷されます。 「+」文字の後。
graphical.target @ 10.071s
└─[email protected]
└─[email protected]+ 22ms
└─[email protected]+7ms
└─[email protected]
└─[email protected]
└─[email protected]
└─[email protected]+ 28ms
└─[email protected]
ネットワーク[email protected]
219ms
└─dbus-broker.service @ 4.434s + 136ms
└─dbus.socket@ 4.369s
└─sysinit.target@ 4.354s
└─systemd更新-utmp.service @ 4.345s + 9ms
└─[email protected]+ 42ms
└─systemdジル・setup.service @ 4.254s + 42ms
└─import-state.service @ 4.233s + 19ms
└─local-fs.target @ 4.229s
└─Virtual.mount@ 4.019s + 209ms
└─systemd-のfsck @ DEV-マッパー-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 dump
タイムスタンプファームウェア:1分7.983523s
タイムスタンプローダー:3.872325s
タイムスタンプカーネル:Wed 2020-08-26 12:33: 35 EDT
Timestamp initrd:Wed 2020-08-26 12:33:38 EDT
Timestamp userspace:Wed 2020-08-26 12:33:42 EDT
Timestamp finish:Wed 2020- 08-26 16:33:56 EDT
タイムスタンプセキュリティ-開始:水2020-08-26 12:33:42 EDT
タイムスタンプセキュリティ-終了:水2020-08-26 12:33:42 EDT
タイムスタンプジェネレーター-開始:水2020-08-26 16:33:42 EDT
タイムスタンプジェネレーター-終了:水2020-08-26 16:33:43EDT
タイムスタンプユニット- load-start:Wed 2020-08-26 16:33:43 EDT
Timestamp units-load-finish:Wed 2020-08-26 16:33:43 EDT
Timestamp initrd-security-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-security-finish:Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-generators-start:Wed 2020-08 -26 12:33:38 EDT
Timestamp initrd-generators-finish:Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-start:Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-finish:Wed 2020-08-26 12:33:38 EDT
-> Unit system.slice:
説明:システムスライス
インスタンス:該当なし
ユニットロード状態:ロード済み
ユニットアクティブ状態:アクティブ
状態変更タイムスタンプ:水2020-08-26 12:33: 38 EDT
非アクティブな終了タイムスタンプ:水2020-08-26 12:33:38 EDT
アクティブな開始タイムスタンプ:水2020-08-26 12:33:38 EDT
アクティブな終了タイムスタンプ:該当なし
非アクティブタイムスタンプの入力:該当なし
5月GC:いいえ
私のメインワークステーションでは、このコマンドは49,680行と約1.66MBのストリームを生成しました。このコマンドは非常に高速なので、結果を待つ必要はありません。
その他のLinuxリソース
- Linuxコマンドのチートシート
- 高度なLinuxコマンドのチートシート
- 無料のオンラインコース:RHELの技術概要
- Linuxネットワーキングのチートシート
- SELinuxチートシート
- Linuxの一般的なコマンドのチートシート
- Linuxコンテナとは何ですか?
- 最新のLinux記事
ストレージなど、接続されているさまざまなデバイスに提供される豊富な詳細が気に入っています。各systemdユニットには、さまざまなランタイムのモード、キャッシュ、ログディレクトリ、ユニットの起動に使用されるコマンドライン、プロセスID(PID)、開始タイムスタンプ、メモリとファイルの制限などの詳細が記載されたセクションがあります。
systemd-analyze
のマニュアルページ systemd-analyze --user dump
を示しています オプション。ユーザーマネージャの内部状態に関する情報を表示することを目的としています。これは私にとって失敗し、インターネット検索はそれに問題があるかもしれないことを示しています。 systemdでは、--user
インスタンスは、各ユーザーに属するプロセスの階層のリソースを管理および制御するために使用されます。各ユーザーのプロセスはコントロールグループの一部であり、これについては今後の記事で取り上げます。
ほとんどの先のとがった髪のボス(PHB)と多くの優れたマネージャーは、私が通常好むテキストベースのシステムパフォーマンスデータよりも、きれいなグラフを読みやすく、理解しやすいと感じています。ただし、良いグラフが好きな場合もあり、systemd-analyze
SVGベクターグラフィックチャートで起動/起動データを表示する機能を提供します。
次のコマンドは、起動および起動中に発生するイベントを表示するベクターグラフィックファイルを生成します。このファイルを生成するのに数秒しかかかりません:
[root@david ~]# systemd-analyze plot > /tmp/bootup.svg
このコマンドは、SVGを作成します。これは、Image Viewer、Ristretto、Okular、Eye of Mate、LibreOfficeDrawなどのアプリケーションがグラフの生成に使用する一連のグラフィックベクトルを定義するテキストファイルです。これらのアプリケーションはSVGファイルを処理して画像を作成します。
LibreOfficeDrawを使用してグラフをレンダリングしました。グラフは巨大で、詳細を確認するにはかなりズームインする必要があります。これがそのほんの一部です:
起動シーケンスはグラフのタイムラインのゼロ(0)の左側にあり、起動シーケンスはゼロの右側にあります。この小さな部分は、カーネルinitrd
を示しています。 、およびプロセスinitrd
開始しました。
このグラフは、何がいつ開始されたか、起動にかかった時間、および主な依存関係を一目で示しています。クリティカルパスは赤で強調表示されています。
グラフィカル出力を生成する別のコマンドは、systemd-analyze plot
です。 。 DOT形式のテキスト依存関係グラフの説明を生成します。結果のデータストリームは、dot
を介してパイプされます ユーティリティ。さまざまなタイプのデータからベクターグラフィックファイルを生成するために使用できるプログラムファミリーの一部です。これらのSVGファイルは、上記のツールでも処理できます。
まず、ファイルを生成します。これは私のプライマリワークステーションでほぼ9分かかりました:
[root @ david〜]#timesystemd-ドットを分析| dot -Tsvg> /tmp/test.svg
色の凡例:黒=必須
濃い青=必須
赤濃い灰色=欲しい
後
real 8m37.544s
user 8m35.375s
sys 0m0.070s
[root @ david〜]#
結果のグラフはほとんどスパゲッティであるため、ここでは出力を再現しません。しかし、それを試して結果を見て、私が何を意味するのかを確認する必要があります。
systemd-analyze(1)
を読んでいるときに発見した、より興味深い、しかしやや一般的な機能の1つ マニュアルページはcondition
です サブコマンド。 (はい—私はマニュアルページを読んでいます、そして私がこの方法で学んだことは驚くべきことです!)このcondition
サブコマンドを使用して、systemdユニットファイルで使用できる条件とアサートをテストできます。
また、スクリプトで1つ以上の条件を評価するために使用することもできます。すべてが満たされた場合はゼロ(0)を返し、いずれかの条件が満たされない場合は1を返します。いずれの場合も、調査結果に関するテキストを吐き出します。
以下のmanページの例は、少し複雑です。 4.0〜5.1のカーネルバージョン、ホストがAC電源で実行されていること、システムアーキテクチャがARM以外のものであること、ディレクトリ/etc/os-release
をテストします。 存在します。 echo $?
を追加しました 戻りコードを出力するステートメント。
[root @ david〜]#systemd-条件を分析する'ConditionKernelVersion =! <4.0'\
' ConditionKernelVersion => =5.1'\
' ConditionACPower =| false'\
-リリース'; \
echo $?
test.service:AssertPathExists =/ etc /os-releaseが成功しました。
Assertsが成功しました。
test.service:ConditionArchitecture =|!armが成功しました。
test.service:ConditionACPower =|falseが失敗しました。
test.service:ConditionKernelVersion => =5.1が成功しました。
test.service:ConditionKernelVersion =!<4.0が成功しました。
条件が成功しました。
br /> 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 [email protected]
After =systemd-user-sessions.service getty @ tty1.service plymouth-quit.service livesys-late.service
#Conflicts =plymouth-quit.service
[Service]
ExecStart =/ usr / sbin / lxdm
Restart =always
IgnoreSIGPIPE =no
#BusName =org.freedesktop.lxdm
[Install]
Alias =display-manager.service
[root @ david〜]#
これは、標準のcat
以外の何もしないための多くの入力です。 コマンドは行います。次のコマンドは少し役に立ちます。標準のsystemdロケーション内で指定されたパターンのファイルを検索できます:
[root @ david〜]#systemctl cat backup *
#/etc/systemd/system/backup.timer
#このタイマーユニットはローカルバックアッププログラムを実行します
#(C) David Both
#GPLV2でライセンス供与
#
[Unit]
Description=システムバックアップを実行
Requires=backup.service
[タイマー]
Unit =backup.service
OnCalendar =*-*-* 00:15:30
[インストール]
WantedBy=timers。 target
#/etc/systemd/system/backup.service
#このサービスユニットはrsbuバックアッププログラムを実行します
#David Both
# GPLV2でライセンス供与
#
[ユニット]
説明=rsbuを使用したバックアップサービス
Wants=backup.timer
[サービス]
Type =oneshot
Environment ="HOME =/ root"
ExecStart =/ usr / local / bin / rsbu -bvd1
ExecStart =/ usr / local / bin / rsbu- buvd2
[インストール]
WantedBy =multi-user.target
[root @ david〜]#
これらのコマンドは両方とも、各ファイルの内容の前に、ファイルのフルパスと名前を含むコメント行を付けます。
新しいユニットファイルを作成した後、その構文が正しいことを確認すると役立つ場合があります。これがverify
です サブコマンドは行います。スペルが間違っているディレクティブを一覧表示し、不足しているサービスユニットを呼び出すことができます:
[root@david ~]# systemd-analyze verify /etc/systemd/system/backup.service
「沈黙は黄金である」というUnix/Linuxの哲学に従い、出力メッセージがないということは、スキャンされたファイルにエラーがないことを意味します。
security
サブコマンドは、指定されたサービスのセキュリティレベルをチェックします。サービスユニットでのみ機能し、他のタイプのユニットファイルでは機能しません:
NAMEの説明】【デビッド〜@ルート]>
✗PrivateNetwork =サービスは、ホストのネットワーク>
✗ユーザー=/ DynamicUser =サービスへのアクセス権を持っていますrootユーザーとして実行>
✗CapabilityBoundingSet =〜CAP_SET(UID | GID | PCAP)サービスは、UID / GIDを変更することがアイデンティティ/機能>
✗CapabilityBoundingSet =〜CAP_SYS_ADMINサービス>
✗管理者権限を持っていますCapabilityBoundingSet =〜CAP_SYS_PTRACEサービス(ptraceのを持っている)の能力をデバッグ>
✗RestrictAddressFamilies =〜AF_(INET | INET6)サービス>
インターネットソケットを割り当てることができる✗ RestrictNamespaces =〜CLONE_NEWUSERサービスは、ユーザーを作成することができ、名前空間>
✗RestrictAddressFamilies =〜...サービスは、エキゾチックなソケットを割り当てることができる>
✗CapabilityBoundingSet =〜CAP_(CHOWN | FSETID | SETFCAP)サービスは、ファイルの所有権/アクセスモードを変更することがあり/機能unres>
✗CapabilityBoundingSet=〜CAP_(DAC _ * | FOWNER | IPC_OWNER)サービスはUNIXファイル/IPC権限チェックを上書きする可能性があります>
✗ネットワーク
✗CapabilityBoundingSet=〜CAP_NET_ADMIN CapabilityBoundingSet =〜CAP_SYS_MODULEサービスをロードすることができ、カーネルモジュール
✗CapabilityBoundingSet =〜CAP_SYS_TTY_CONFIGサービス(vhangup発行することができる)>
✗CapabilityBoundingSet =〜CAP_WAKE_ALARMサービスは、タイマー股関節をプログラムすることができますtシステムをウェイクアップ>
✗RestrictAddressFamilies=〜AF_UNIXサービスはローカルソケットを割り当てる可能性があります81(終了)
はい、絵文字は出力の一部です。しかし、もちろん、多くのサービスは、仕事をするためにすべてにほぼ完全にアクセスする必要があります。私はこのプログラムを、自分のバックアップサービスを含むいくつかのサービスに対して実行しました。結果は異なる場合がありますが、収益はほぼ同じようです。
このツールは、セキュリティが重要な環境でユーザースペースサービスユニットをチェックおよび修正するのに非常に役立ちます。私たちのほとんどに提供できるものはあまりないと思います。
この強力なツールは、いくつかの興味深く驚くほど便利なオプションを提供します。この記事で取り上げる内容の多くは、systemd-analyze
の使用に関するものです。 systemdを使用してLinuxの起動パフォーマンスに関する洞察を提供します。 systemdの他の側面を分析することもできます。
これらのツールのいくつかは使用が制限されており、いくつかは完全に忘れておく必要があります。ただし、ほとんどの場合、起動やその他のsystemd関数の問題を解決するときに効果的に使用できます。
インターネット上にはsystemdに関する多くの情報がありますが、その多くは簡潔で、鈍感で、誤解を招くものですらあります。この記事に記載されているリソースに加えて、次のWebページでは、systemdの起動に関するより詳細で信頼性の高い情報を提供しています。このリストは、私が行った調査を反映するためにこのシリーズの記事を始めてから増えています。
- systemd.unit(5)のマニュアルページには、ユニットファイルセクションとその構成オプションの一覧と、それぞれの簡潔な説明が含まれています。
- Fedora Projectには、systemdに関する優れた実用的なガイドがあります。 systemdを使用してFedoraコンピューターを構成、管理、および保守するために知っておく必要のあるほとんどすべてが含まれています。
- Fedora Projectには、古いSystemVコマンドを同等のsystemdコマンドと相互参照する優れたチートシートもあります。
- Red Hatのドキュメントには、ユニットファイル構造の適切な説明とその他の重要な情報が含まれています。
- systemdの詳細な技術情報とその作成理由については、Freedesktop.orgのsystemdの説明をご覧ください。
- Linux.comの「Moresystemdfun」は、より高度なsystemd情報とヒントを提供します。
また、systemdの設計者であり主要な開発者であるLennart Poetteringによる、Linuxシステム管理者向けの一連の詳細な技術記事もあります。これらの記事は2010年4月から2011年9月の間に書かれましたが、当時と同じように関連性があります。 systemdとそのエコシステムについて書かれた他のすべての優れた点の多くは、これらの論文に基づいています。
- PID1を再考する
- 管理者向けsystemd、パートI
- 管理者向けsystemd、パートII
- 管理者向けsystemd、パートIII
- 管理者向けsystemd、パートIV
- 管理者向けsystemd、パートV
- 管理者向けsystemd、パートVI
- 管理者向けsystemd、パートVII
- 管理者向けsystemd、パートVIII
- 管理者向けsystemd、パートIX
- 管理者向けsystemd、パートX
- 管理者向けsystemd、パートXI