我试图找出 Linux 机器在冷启动后启动所需的时间。看起来像uptime命令或/proc/uptime给你自 init 进程启动以来的时间。这没有考虑内核加载到内存中所花费的时间、加载程序和固件启动时间（就像systems-analyze那样）。我不能使用systems-analyze，因为如果我使用它，我将不得不等待所有 systemd 服务启动。出于同样的原因，甚至“bootchart”也被排除在外。这是因为我将不得不通过 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 秒。这通常与我的手表相符...意识到所有这一切都是在 BIOS/EFI 花费大约 2 分钟后发生的，然后通过 LSI Raid 控制器再启动 15 个磁盘的 RAID-5 2 分钟。因此，您关心的总时间可能会有很大差异，并且如果您对冷启动所需时间的定义是按下开机按钮时，则取决于所使用的硬件。但是对于linux内核所花费的时间，你通常可以从boot.msg中计算出来。
答案3
使用智能手机对准显示器制作视频。这将精确到 1/n秒，其中n是每秒录制视频的帧数。
答案4
如果您使用的 UEFI 固件包含对 ACPI FPDT 表的支持，并且您的内核包含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_ns，您将得到 CPU 启动和 Linux 内核启动之间经过的时间量。
请注意，如果您有一个带有专用管理处理器的服务器级系统，通常情况下，一旦系统插入有电源的墙上插座，管理处理器就会开始运行，但主 CPU 将无法供电直到管理处理器完成初始化，这可能需要一两分钟。另一方面，这样的管理处理器通常会自行提供大量带有有用时间戳的日志。