document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-22 23:00:57 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update and rename sources/tech/20200916 Analyze Linux startup performance.md to tranlated/tech/20200916 Analyze Linux startup performance.md

Browse Source
This commit is contained in:
jiamn 2022-04-07 16:18:16 +08:00 committed by GitHub
parent 67fb2362fa
commit a86feb989f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 73 additions and 72 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

145
sources/tech/20200916 Analyze Linux startup performance.md → tranlated/tech/20200916 Analyze Linux startup performance.md
View File

@ -7,26 +7,23 @@
[#]: via: (https://opensource.com/article/20/9/systemd-startup-configuration)
[#]: author: (David Both https://opensource.com/users/dboth)
Analyze Linux startup performance
分析 Linux 启动性能
======
Use systemd-analyze to get insights and solve problems with Linux
startup performance.
用 systemd-analyze 查看 Linux 启动性能或者解决一些问题
![Magnifying glass on code][1]
Part of the system administrator's job is to analyze the performance of systems and to find and resolve problems that cause poor performance and long startup times. Sysadmins also need to check other aspects of systemd configuration and usage.
The systemd init system provides the `systemd-analyze` tool that can help uncover performance problems and other important systemd information. In a previous article, [_Analyzing systemd calendar and timespans_][2], I used `systemd-analyze` to analyze timestamps and timespans in systemd timers, but this tool has many other uses, some of which I will explore in this article.
系统管理员的一部分工作就是分析系统性能，去发现并解决引起性能不佳、长时间启动系统的问题。系统维护者也需要去检查系统配置和使用等。
systemd 初始化系统提供了 systemd-analyze 工具，帮助查看性能和其他重要的 systemd 信息。在以前的文章 分析 [_systemd 日历和时间间隔_][2] 里，我用了 systemd-analyze 去分析 systemd 里的时间戳和时间间隔，但是这个工具有很多其他用法，这个文章里我再揭示一些。
（译者注： systemd 是目前主流Linux release 采用的系统管理；boot翻译为启动，startup翻译为起动）
### Startup overview
The Linux startup sequence is a good place to begin exploring because many `systemd-analyze` tool functions are targeted at startup. But first, it is important to understand the difference between boot and startup. The boot sequence starts with the BIOS power-on self test (POST) and ends when the kernel is finished loading and takes control of the host system, which is the beginning of startup and the point when the systemd journal begins.
In the second article in this series, [_Understanding systemd at startup on Linux_][3], I discuss startup in a bit more detail with respect to what happens and in what sequence. In this article, I want to examine the startup sequence to look at the amount of time it takes to go through startup and which tasks take the most time.
The results I'll show below are from my primary workstation, which is much more interesting than a virtual machine's results. This workstation consists of an ASUS TUF X299 Mark 2 motherboard, an Intel i9-7960X CPU with 16 cores and 32 CPUs (threads), and 64GB of RAM. Some of the commands below can be run by a non-root user, but I will use root in this article to prevent having to switch between users.
There are several options for examining the startup sequence. The simplest form of the `systemd-analyze` command displays an overview of the amount of time spent in each of the main sections of startup, the kernel startup, loading and running `initrd` (i.e., initial ramdisk, a temporary system image that is used to initialize some hardware and mount the `/` [root] filesystem), and userspace (where all the programs and daemons required to bring the host up to a usable state are loaded). If no subcommand is passed to the command, `systemd-analyze time` is implied:
### 总览
LINUX起动顺序是值得学习关注的地方，因为 systemd-analyze 工具很多功能聚焦在起动startup过程。但是首先，要理解启动boot和起动startup。启动从BIOS加电自检（POST）开始，装载和控制主机系统结束，然后是起动startup，systemd 日志开始。
这个系列的第二篇文章， [_理解LINUX起动 systemd_][3]，我讨论了起动startup的一点顺序上的细节，文章里，我试图解释起动startup顺序时间总进程和大部分时间花费在哪里。
我的主工作站比虚拟机的结果更有意义。工作站组成是ASUS TUF X299 Mark 2 主板，Intel i9-7960X cpu （16核 32线程），64G内存。一些命令非超级用户可以使用，但是我在这篇文章里使用了超级用户避免在用户之间切换。
检查起动过程有几个选项，最简单的是从 systemd-analyze 命令显示起动的几个主要分段耗费的时间汇总，内核起动，装载运行 initrd （初始ramdisk，一个临时系统镜像用来初始化一些硬件，挂载 / 根文件系统），还有用户空间 （所有的程序和后台进程需要主机起动到一个可用的状态）。如果没有子命令传递给命令， systemd-analyze time 是这样的：
```
[root@david ~]$ systemd-analyze
@ -34,18 +31,17 @@ Startup finished in 53.921s (firmware) + 2.643s (loader) + 2.236s (kernel) + 4.3
graphical.target reached after 10.071s in userspace
[root@david ~]#
```
特别要注意的BIOS花费了接近54秒，这是一个非同寻常的时间段，基本上所有的物理硬件系统都要使用BIOS。
The most notable data in this output is the amount of time spent in firmware (BIOS): almost 54 seconds. This is an extraordinary amount of time, and none of my other physical systems take anywhere near as long to get through BIOS.
我的System76 Oryx Pro笔记本在BIOS只花了8.506秒，我家里所有的系统都在10秒以内。在线搜索一阵之后，我发现这个主板（译者注：作者的主工作站主板）因为不同寻常的BIOS启动时间著名，我的主板从不“启动”，总是挂掉，我需要关机再开机，BIOS报错，按F1进入BIOS设置，选择要启动的驱动器完成启动，多出的时间就是这样用掉的。
My System76 Oryx Pro laptop spends only 8.506 seconds in BIOS, and all of my home-built systems take a bit less than 10 seconds. After some online searches, I found that this motherboard is known for its inordinately long BIOS boot time. My motherboard never "just boots." It always hangs, and I need to do a power off/on cycle, and then BIOS starts with an error, and I need to press F1 to enter BIOS configuration, from where I can select the boot drive and finish the boot. This is where the extra time comes from.
不是所有主机显示固件数据（译者注：固件启动无法用systemd）。用Intel 9代或者更高的处理器就感觉不科学。尽管那不是正确的。（译者注：更高代的cpu启动时间更短，因为优化的BIOS）
Not all hosts show firmware data. My unscientific experiments lead me to believe that this data is shown only for Intel generation 9 processors or above. But that could be incorrect.
总结关于启动起动是非常有趣的，同时提供了很好的（虽然有限）的信息，仍然有很多关于起动的信息，就像下面我将描述的一样。
This overview of the boot startup process is interesting and provides good (though limited) information, but there is much more information available about startup, as I'll describe below.
### 指定火炬
### Assigning blame
You can use `systemd-analyze blame` to discover which systemd units take the most time to initialize. The results are displayed in order by the amount of time they take to initialize, from most to least:
你可以用 systemd-analyze blame 去发现初始化每个 systemd 单元用掉的时间，结果按照初始化时间长短排序，从多到少：
```
@ -64,14 +60,15 @@ You can use `systemd-analyze blame` to discover which systemd units take the mos
        396ms initrd-switch-root.service
<SNIP – removed lots of entries with increasingly small times>
```
注：删去了好多时间不长的条目
Because many of these services start in parallel, the numbers may add up to significantly more than the total given by `systemd-analyze time` for everything after the BIOS. All of these are small numbers, so I cannot find any significant savings here.
因为很多服务是并行开始的，在BIOS之后所有单元加在一起的总数超过了 systemd-analyze time 汇总数。很多都是小数，不能显著的节省时间。
The data from this command can provide indications about which services you might consider to improve boot times. Services that are not used can be disabled. There does not appear to be any single service that is taking an excessively long time during this startup sequence. You may see different results for each boot and startup.
这个命令提供的数据显明了提升启动时间的办法。无用的服务禁止（disable）掉。在起动序列中花掉很多时间的单一服务呈现明显。每次启动起动你可以看到不同结果。（译者注：并行起动服务的原因）
### Critical chains
### 严格链
Like the critical path in project management, a _critical chain_ shows the time-critical chain of events that take place during startup. These are the systemd units you want to look at if startup is slow, as they are the ones that would cause delays. This tool does not display all the units that start, only those in this critical chain of events:
项目管理中有个严格链，（译者注：systemd可以定义服务间严格依赖，构成严格链）在起动中可以通过查看一个严格链与时间相关的事件。有一些systemd单元起动中很慢，可能因为依赖严格链影响的，工具没有从开始显示所有单元，仅仅是有严格限制关系的事件。（译者注：相当于最短路径。并不显示依赖但不在严格链上的服务单元）
```
@ -108,11 +105,11 @@ graphical.target @10.071s
[root@david ~]#
```
The numbers preceded with `@` show the absolute number of seconds since startup began when the unit becomes active. The numbers preceded by `+` show the amount of time it takes for the unit to start.
@后面的秒数数字是从起动开始到单元激活的时间，+后面是单元开始花费的时间。
### System state
### 系统状态
Sometimes you need to determine the system's current state. The `systemd-analyze dump` command dumps a _massive_ amount of data about the current system state. It starts with a list of the primary boot timestamps, a list of each systemd unit, and a complete description of the state of each:
有时候你需要决定系统的当前状态， systemd-analyze dump 命令挖显出当前系统状态的一堆数据。有主要的启动时间戳，一个每个 systemd 单元的列表，和一个每个完整的详细描述：
```
@ -149,38 +146,37 @@ Timestamp initrd-units-load-finish: Wed 2020-08-26 12:33:38 EDT
<SNIP – Deleted a bazillion lines of output>
```
On my main workstation, this command generated a stream of 49,680 lines and about 1.66MB. This command is very fast, so you don't need to wait for the results.
注：删掉了很多输出行
I do like the wealth of detail provided for the various connected devices, such as storage. Each systemd unit has a section with details such as modes for various runtimes, cache, and log directories, the command line used to start the unit, the process ID (PID), the start timestamp, as well as memory and file limits.
在我的主工作站，这个命令生成了49680行大概1.66MB，命令很快，你不需要等待。
The man page for `systemd-analyze` shows the `systemd-analyze --user dump` option, which is intended to display information about the internal state of the user manager. This fails for me, and internet searches indicate that there may be a problem with it. In systemd, `--user` instances are used to manage and control the resources for the hierarchy of processes belonging to each user. The processes for each user are part of a control group, which I'll cover in a future article.
我喜欢多种连接设备的规格细节，例如存储。每个systemd单元有一节例如模块的多种运行时、缓存、日志目录、单元开始命令、PID、开始时间戳、内存和文件限制。
### Analytic graphs
systemd-analyze 的 man 帮助手册里展示了 systemd-analyze --user dump 选项，显示用户管理器的内部状态。但是我失败了，互联网搜索之后表明机器有一些问题。在systemd里， --user 实例用来管理和控制处理器给每个用户的资源。处理能力按分给每个用户的控制组control group（译者注：系统管理一个特性）分配，我回头再写。
Most pointy-haired-bosses (PHBs) and many good managers find pretty graphs easier to read and understand than the text-based system performance data I usually prefer. Sometimes, though, even I like a good graph, and `systemd-analyze` provides the capability to display boot/startup data in an [SVG][4] vector graphics chart.
### 分析图表
The following command generates a vector graphics file that displays the events that take place during boot and startup. It only takes a few seconds to generate this file:
很多尖头老板(pointy-haired-bosses)和好的经理人发现好的图表特别容易阅读理解，比我经常看的文本类系统性能数据好。看，我喜欢好图表，systemd-analyze 提供了显示启动/起动数据用[SVG][4] 向量图表。
下面的命令生成一个向量图文件来显示在启动起动之间发生的事件。生成这个文件只需要几秒：
```
`[root@david ~]# systemd-analyze plot > /tmp/bootup.svg`
```
This command creates an SVG, which is a text file that defines a series of graphic vectors that applications, including Image Viewer, Ristretto, Okular, Eye of Mate, LibreOffice Draw, and others, use to generate a graph. These applications process SVG files to create an image.
这个命令创建了SVG，SVG是一个定义图向量应用的文本文件，包括Image Viewer、Ristretto、 Okular、 Eye of Mate、 LibreOffice Draw、和其他，(译者注：这些是文档应用）用来生成图。这些应用可以处理SVG来创建一个图像。
I used LibreOffice Draw to render a graph. The graph is huge, and you need to zoom in considerably to make out any detail. Here is a small portion of it:
我用 LibreOffice Draw（译者注：一个办公文档软件）去渲染一幅图。图很大，你需要放大来看细节。这里放的比较小：
![The bootup.svg file displayed in LibreOffice Draw.][5]
(David Both, [CC BY-SA 4.0][6])
The bootup sequence is to the left of the zero (0) on the timeline in the graph, and the startup sequence is to the right of zero. This small portion shows the kernel, `initrd`, and the processes `initrd` started.
启动起始是图上左面的时间线0，起动序列在0的右面。这个小图显示了内核、initrd、和initrd处理开启。 这个图显示了谁什么时候开始，持续了多久，和主要的依赖。严格路径是红色高亮的。
This graph shows at a glance what started when, how long it took to start up, and the major dependencies. The critical path is highlighted in red.
另外一个生成图片输出的命令是 systemd-analyze plot，它生成了[DOT][7] 格式纹理依赖图。结果数据流通过dot工具管道，这是一族用来生成向量图文件多种类型数据的程序。这些SVG文件也能被上面列出的工具处理。
Another command that generates graphical output is `systemd-analyze plot`. It generates textual dependency graph descriptions in [DOT][7] format. The resulting data stream is then piped through the `dot` utility, which is part of a family of programs that can be used to generate vector graphic files from various types of data. These SVG files can also be processed by the tools listed above.
First, generate the file. This took almost nine minutes on my primary workstation:
首先，生成文件，在我的主工作站花了9分钟：
```
@ -197,15 +193,17 @@ sys     0m0.070s
[root@david ~]#
```
I won't reproduce the output here because the resulting graph is pretty much spaghetti. But you should try it and view the result to see what I mean.
我不想重新生成输出了，因为比意大利面还好。但是你应该试试看看我想让你看到的结果。
### Conditionals
### 条件
One of the more interesting, yet somewhat generic, capabilities I discovered while reading the `systemd-analyze(1)` man page is the `condition` subcommand. (Yes—I do read the man pages, and it is amazing what I have learned this way!) This `condition` subcommand can be used to test the conditions and asserts that can be used in systemd unit files.
我不想重新生成输出了，因为比意大利面还好。但是你应该试试看看我想让你看到的结果。
It can also be used in scripts to evaluate one or more conditions—it returns a zero (0) if all are met or a one (1) if any condition is not met. In either case, it also spews text about its findings.
很多有意思的，也有些普遍的，当我读 systemd-analyze man帮助时发现 condition 子命令 （是的，我读了man帮助手册，我就是这样学习的）。这个 condition 子命令能用来测试条件和断言systemd单元文件。
The example below, from the man page, is a bit complex. It tests for a kernel version between 4.0 and 5.1, that the host is running on AC power, that the system architecture is anything but ARM, and that the directory `/etc/os-release` exists. I added the `echo $?` statement to print the return code.
把它放到程序里评估一个或者多个条件成立是否返回0值，或者条件没有成立返回1。 在其他情况，它根据调查结果吐出文本。
下面的例子，来自man帮助手册，稍微有点复杂。它测试了内核版本是不是在4.0和5.1，主机使用AC power，系统结构不是arm，并且它的目录 /etc/os-release 是否存在。我加了 echo $? 来打印返回值。
```
@ -226,11 +224,11 @@ Conditions succeeded.
[root@david ~]#
```
The list of conditions and asserts starts around line 600 on the `systemd.unit(5)` man page.
条件和断言在 systemd.unit(5) man帮助手册的大概600行。
### Listing configuration files
### 罗列配置文件
The `systemd-analyze` tool provides a way to send the contents of various configuration files to `STDOUT`, as shown here. The base directory is `/etc/`:
systemd-analyze 工具可以发送多种配置文件内容去标准输出，像这儿展示的，基础根目录是 /etc/:
```
@ -254,7 +252,7 @@ Alias=display-manager.service
[root@david ~]#
```
This is a lot of typing to do nothing more than a standard `cat` command does. I find the next command a tiny bit helpful. It can search out files with the specified pattern within the standard systemd locations:
这和标准的cat命令做的差不多。我发现另外一条小有帮助的命令，它能在标准的 systemd 所在的位置搜索模式匹配的内容：
```
@ -298,22 +296,22 @@ WantedBy=multi-user.target
[root@david ~]#
```
Both of these commands preface the contents of each file with a comment line containing the file's full path and name.
这些命令为每个文件提供了包含文件的全路径和文件名的注释行。
### Unit file verification
### 单元文件检查
After creating a new unit file, it can be helpful to verify that its syntax is correct. This is what the `verify` subcommand does. It can list directives that are spelled incorrectly and call out missing service units:
当创建了一个新的单元文件，利用 verify 子命令帮助检查语法是否正确。它能指出来不正确的拼写和呼叫错误服务单元的指导。
```
`[root@david ~]# systemd-analyze verify /etc/systemd/system/backup.service`
```
Adhering to the Unix/Linux philosophy that "silence is golden," a lack of output messages means that there are no errors in the scanned file.
Unix/Linux的反馈宗旨是“沉默是金”，没有输出意味着扫描文件没有错。
### Security
### 安全
The `security` subcommand checks the security level of specified services. It only works on service units and not on other types of unit files:
security 子命令检查指定服务的安全级别。只能针对服务单元，其他类型的单元文件不可用：
```
@ -340,28 +338,31 @@ The `security` subcommand checks the security level of specified services. It on
lines 34-81/81 (END)
```
Yes, the emoji is part of the output. But, of course, many services need pretty much complete access to everything in order to do their work. I ran this program against several services, including my own backup service; the results may differ, but the bottom line seems to be mostly the same.
是的，哭脸（emoji）是输出。但是当然，很多服务的工作比美观更重要。我列举了一些服务，包括我自己的备份服务，结果可能不同，但是最下面一行看起来是一样的。
这个工具对于在严格的安全环境检查和修复用户空间服务单元是很有用的。我不认为我们的大多数都能用到它。
This tool would be very useful for checking and fixing userspace service units in security-critical environments. I don't think it has much to offer for most of us.
### 最后总结
### Final thoughts
强有力的工具（sysmted-analyze）提供了一些有意思和迷人的有益的选项。这篇文章阐述了用systemd-analyze来分析systemd Linux内部起动性能。它同样能分析 systemd 的其他方面。
工具的某部分是限制使用的，有些被遗漏。但是大多数对于起动和其他systemd功能的问题解决提供了很好的结果。
This powerful tool offers some interesting and amazingly useful options. Much of what this article explores is about using `systemd-analyze` to provide insights into Linux's startup performance using systemd. It can also analyze other aspects of systemd.
### 资源
Some of these tools are of limited use, and a couple should be forgotten completely. But most can be used to good effect when resolving problems with startup and other systemd functions.
互联网上关于systemd有很多信息，但是很多过于简洁，迟钝，甚至误导。这篇文章中提到的额外的资源，是列在下面的关于 systemd 起动的更细节更可信的web页面。我罗列了自从我开始这个系列的文章影响我研究的内容。
### Resources
There is a great deal of information about systemd available on the internet, but much is terse, obtuse, or even misleading. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup. This list has grown since I started this series of articles to reflect the research I have done.
* The [systemd.unit(5) manual page][9] contains a nice list of unit file sections and their configuration options along with concise descriptions of each.
* The Fedora Project has a good, practical [guide to systemd][10]. It has pretty much everything you need to know in order to configure, manage, and maintain a Fedora computer using systemd.
* The Fedora Project also has a good [cheat sheet][11] that cross-references the old SystemV commands to comparable systemd ones.
* Red Hat documentation contains a good description of the [Unit file structure][12] as well as other important information.  
* For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's [description of systemd][13].
* The [systemd.unit(5) manual page][9] 包含了非常棒的每个都是丰富细节描述的一些单元文件节段和它们的配置文件选项。
* The Fedora Project has a good, practical [guide to systemd][10]. 它指导了你用Fedora systemd要知道的设置，管理，维护。
* The Fedora Project also has a good [cheat sheet][11] 兼容交叉了老的 SystemV 命令和systemd以及比较。
* Red Hat documentation contains a good description of the [Unit file structure][12] 和其他一样重要的信息。
* 关于systemd技术细节和创建的原因，可以去 Freedesktop.org's [description of systemd][13].
* [Linux.com][14]'s "More systemd fun" offers more advanced systemd [information and tips][15].
systemd.unit(5) 手册页面 
Fedora 项目有一个好的练习 systemd指导.
Fedora 项目还有一个好的 备忘录 
Red Hat 文档包含了一个详细的描述 单元文件结构 
 Freedesktop.org systemd详述.
Linux.com的 "更多 systemd 乐趣" 提供了很多高级的 systemd 信息和提示.
There is also a series of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and primary developer of systemd. These articles were written between April 2010 and September 2011, but they are just as relevant now as they were then. Much of everything else good that has been written about systemd and its ecosystem is based on these papers.
@ -386,7 +387,7 @@ via: https://opensource.com/article/20/9/systemd-startup-configuration
作者：[David Both][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
译者：[jiamn](https://github.com/jiamn)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出