私は、コールドブート後にLinuxシステムが起動するのにどれくらいの時間がかかるのかを調べたいと思います。uptimeコマンドに似ているか、/proc/uptimeinitプロセスが開始されてからの時間を提供します。これは、カーネルがメモリにロードされるのにかかる時間、ローダ、およびファームウェアの起動時間を考慮しませんsystems-analyze。systems-analyzeそれを使用すると、すべてのシステムサービスが開始されるのを待たなければならないためできません。同じ理由で「ブートチャート」も除外されます。これは、systemdサービスを介して開始時間を収集する必要があるためです（たとえば、他の多くのタスクを実行するなど）。
この情報をどのように取得できるかご存知ですか？
答え1
ストップウォッチを使用してください。ほとんどのプロセスは、システムが準備される前に発生します。
また、ブートストラップが何を意味するのかを定義する必要があります。 Xを介したログインの準備、コンソールによるログインの準備、要求に応答するWebサーバー...
また、テスト中のシステム自体を信頼してはいけません。 （一度はできるだけ早いと主張するシステムの問題を解決していました。知ってみると時計の速度が遅くなっていました。）
答え2
/var/log/boot.msg
次のテキストが表示されます。
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.0.101-108.84-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Nov 30 15:57:27 UTC 2018 (7a72692)
[ 0.000000] Command line: BOOT_IMAGE=dev000:\EFI\SUSE\vmlinuz- 3.0.101-108.84-default root=/dev/disk/by-id/scsi-35000cca070168a20-part2 splash=verbose showopts
[ 0.000000] x86/fpu: Using 'eager' FPU context switches.
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000792de000 (usable)
[ 0.000000] BIOS-e820: 00000000792de000 - 00000000798f4000 (reserved)
それから
[ 4.967393] Brought up 128 CPUs
[ 4.967400] Total of 128 processors activated (512000.20 BogoMIPS).
[ 5.377931] devtmpfs: initialized
[ 5.420574] PM: Registering ACPI NVS region at 79a38000 (5976064 bytes)
[ 5.421208] print_constraints: dummy:
[ 5.421243] Time: 20:15:03 Date: 01/22/19
[ 5.421817] NET: Registered protocol family 16
[ 5.422067] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[ 5.422073] ACPI: bus type pci registered
次に終わる
[ 14.053705] igb 0000:42:00.3: added PHC on eth3
[ 14.066858] igb 0000:42:00.3: Intel(R) Gigabit Ethernet Network Connection
[ 14.080159] igb 0000:42:00.3: eth3: (PCIe:5.0Gb/s:Width x4) 0c:c4:7a:3a:51:33
[ 14.093493] igb 0000:42:00.3: eth3: PBA No: 010A00-000
[ 14.106628] igb 0000:42:00.3: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[ 14.800728] device-mapper: uevent: version 1.0.3
[ 14.814242] device-mapper: ioctl: 4.25.0-ioctl (2012-07-25) initialised: [email protected]
[ 15.254103] loop: module loaded
[ 15.634412] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled
[ 15.648644] SGI XFS Quota Management subsystem
[ 15.661127] XFS (sda1): Mounting Filesystem
[ 15.790512] XFS (sda1): Ending clean mount
[ 15.802635] XFS (sdb1): Mounting Filesystem
[ 15.886148] XFS (sdb1): Ending clean mount
[ 15.898303] XFS (sdd1): Mounting Filesystem
[ 16.010051] XFS (sdd1): Ending clean mount
[ 17.567752] fuse init (API version 7.16)
Kernel logging (ksyslog) stopped.
Kernel log daemon terminating.
Waiting for device /dev/disk/by-id/scsi-35000cca070168a20-part2 to appear: ok
fsck from util-linux 2.19.1
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -C0 /dev/sdc2
myhostname: clean, 1172494/36618240 files, 42233936/146465024 blocks
fsck succeeded. Mounting root device read-write.
Linuxルートパーティションのマウントとカーネルの起動に17.56秒残りました。
それがすべてではないことに気づく始めるLinuxのすべてのサービスが実行されるプロセスです。これを行うには、/var/log/boot.msg移行後に最初のタイムスタンプを見つけ、最後のタイムスタンプを見つけたら、システムが完全に起動したと合理的に結論付けることができます。ファイアウォールが稼働しており、SSHサービスが稼働しており、何よりもGDMが稼働しています。 。
私の最初のタイムスタンプは15:15:06.xを表示し、ライセンスマネージャを自動起動した後、ファイルの最後のタイムスタンプは15:15:53.xを表示します。タイムスタンプはsmartd start exits with status 015:15:43.x、その後はSuSEfirewall2_setup start' exits with status 015:15:44.xです。
したがって、私の例では、合計17.5秒+ 47秒= 64.5秒です。これは通常私の時計と一致しています...気づきました。したがって、関心のある合計時間は大きく異なる可能性があり、コールドブートにかかる時間は、電源ボタンを押したときに定義する場合に使用されるハードウェアによって異なります。ただし、Linuxカーネルで費やされた時間は通常boot.msgで計算できます。
答え3
スマートフォンをモニターに映し出して映像を作りましょう。これは1/N秒、ここでN録画された画像の1秒あたりのフレーム数。
答え4
ACPI FPDTテーブルのサポートを含むUEFIファームウェアを使用し、カーネルにビルドCONFIG_ACPI_FPDT時間オプションが含まれている場合は、/sys/firmware/acpi/fpdt/bootファームウェアとブートローダが起動に費やした時間に関する情報を見つけることができます。隣接するディレクトリには、一時停止および再開操作に関するタイミング情報も含まれる場合があります。
> + ACPI Firmware Performance Data Table (FPDT) provides
> + information for firmware performance data for system boot,
> + S3 suspend and S3 resume. This sysfs entry contains the
> + performance data retrieved from the FPDT.
> +
> + boot:
> + firmware_start_ns: Timer value logged at the beginning
> + of firmware image execution. In nanoseconds.
> + bootloader_load_ns: Timer value logged just prior to
> + loading the OS boot loader into memory.
> + In nanoseconds.
> + bootloader_launch_ns: Timer value logged just prior to
> + launching the currently loaded OS boot loader
> + image. In nanoseconds.
> + exitbootservice_start_ns: Timer value logged at the
> + point when the OS loader calls the
> + ExitBootServices function for UEFI compatible
> + firmware. In nanoseconds.
> + exitbootservice_end_ns: Timer value logged at the point
> + just prior to the OS loader gaining control
> + back from the ExitBootServices function for
> + UEFI compatible firmware. In nanoseconds.
> + suspend:
> + suspend_start_ns: Timer value recorded at the previous
> + OS write to SLP_TYP upon entry to S3. In
> + nanoseconds.
> + suspend_end_ns: Timer value recorded at the previous
> + firmware write to SLP_TYP used to trigger
> + hardware entry to S3. In nanoseconds.
> + resume:
> + resume_count: A count of the number of S3 resume cycles
> + since the last full boot sequence.
> + resume_avg_ns: Average timer value of all resume cycles
> + logged since the last full boot sequence,
> + including the most recent resume. In nanoseconds.
> + resume_prev_ns: Timer recorded at the end of the previous
> + platform runtime firmware S3 resume, just prior to
> + handoff to the OS waking vector. In nanoseconds.
私はこれがsystemd-analyzeファームウェアの起動、ローダー、カーネルのロード時間を取得する場所でもあると思います。
デフォルトでは、の値からの値exitbootservice_end_nsを減算すると、firmware_start_nsCPUブートとLinuxカーネルブートの間の経過時間がわかります。
専用の管理プロセッサーを搭載したサーバークラスのシステムがある場合、通常、管理プロセッサーはシステムが電源が入っている壁のコンセントに接続されるとすぐに起動しますが、管理プロセッサーが初期化を完了するまでメインCPUに電力は供給されません。 、この操作には1〜2分かかることがあります。一方、これらの管理プロセッサは、有用なタイムスタンプを含む広範なログを提供することがよくあります。