工具与资源peteris.rocks
Htop 详解
Htop Explained
2016 — 2019，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇教程逐项讲解了 htop 界面中每个指标的含义，包括 CPU 状态、内存、负载平均值（load average）等容易混淆的概念，作者还通过实验（如删除 acpid 进程）验证各组件的作用。文章以系统化的方式帮助读者真正读懂 htop 显示的信息，而不只是看个热闹。
为什么经久不衰：htop 是最常用的终端监控工具之一，而负载平均值等概念几十年来一直困扰 Unix 用户，这篇讲解清晰且经实践验证，至今仍是理解系统监控指标的好入门材料。
HN 评论精选
负载平均值源于 I/O 瓶颈时代，在现代系统中应分别观察 CPU、磁盘、网络负载
htop 是个优秀的工具。我很欣赏作者解释负载平均值的努力，这个概念困扰 Unix 用户几十年了。他的解释基本正确，但缺少一些早期 Unix 性能问题的背景：90 年代初 Unix 系统经常受 I/O 瓶颈限制，磁盘慢且大量进程争抢磁盘访问，swap 也很常见。负载平均值大致是等待 CPU 或等待 I/O 的进程数之和，这在当时是合理的。但现代系统的工作负载往往明确地受磁盘、CPU 或网络某一方面限制，最好分别观察这三类负载——htop 正适合做这件事，而汇总的负载平均值如今已不那么有用了。
NelsonMinar查看英文原文
htop is an excellent tool. I appreciate his valiant effort to explain what load average is; it's confused Unix users forever. His explanation is more or less right but I think misses a bit of context about the old days of Unix performance. It used to be in the early 90s that Unix systems were quite frequently I/O bound; disks were slow and typically bottlenecked through one bus and lots of processes wanted disk access all the time. Swapping was also way more common. Load average is more or less a quick count of all processes that are either waiting on CPU or waiting on I/O. Either was likely in an old Unix system, so adding them all up was sensible. In modern systems your workload is probably very specifically disk bound, or CPU bound, or network bound. It's much better to actually look at all three kinds of load separately. htop is a great tool for doing that! but the summary load average number is not so useful anymore.
htop 在 Linux 上因依赖 procfs 文本解析而在多进程时开销较大
Linux 上 htop 的问题是当系统有 200+ 个进程时，htop 会占用可观的 CPU。因为 htop 每秒都要遍历 procfs 中的每个进程条目（open、read、close）并解析文本内容，而不像 OpenBSD 等系统那样直接调用系统调用获取信息。如果内核以二进制形式提供进程信息，或像 macOS、Windows、OpenBSD、Solaris 那样提供专门的系统调用，会好得多。
for_xyz查看英文原文
The problem with htop on Linux is that once there are 200+ processes running on the system htop takes significant portion of CPU time and utilization. This is because htop has to go through each process entry in procfs (open, read, close) every second and parse the text context instead of just calling appropriate syscall like on the OpenBSD and friends to retrieve such information. It would help if kernel provided process information in binary form instead of serializing it into text. Or even better to provide specific syscalls for it like on macOS, Windows, OpenBSD, Solaris and others.
推荐 atop 作为 htop 的补充，适合排查渐进式问题
htop 是我在非 Linux 系统上最怀念的工具之一。在服务器上我发现 atop 其实更适合排查那些渐进发生、不明显的问题，atop 和 htop 可以互补使用。atop 是 Linux 下的全屏性能监控工具，能报告所有进程（包括期间已结束的进程）的活动，支持长期日志记录、用颜色高亮过载资源，配合可选内核模块还能显示每进程的网络活动。
baldfat查看英文原文
htop is one of the most missed tools when I am on a non-Linux OS. On servers I find atop to actually be a better tool for finding issues that happen incrementally and not an obvious issue. I think that atop and htop both are very complimentary. http://www.atoptool.nl/ "Atop is an ASCII full-screen performance monitor for Linux that is capable of reporting the activity of all processes (even if processes have finished during the interval), daily logging of system and process activity for long-term analysis, highlighting overloaded system resources by using colors, etc. At regular intervals, it shows system-level activity related to the CPU, memory, swap, disks (including LVM) and network layers, and for every process (and thread) it shows e.g. the CPU utilization, memory growth, disk utilization, priority, username, state, and exit code. In combination with the optional kernel module netatop, it even shows network activity per process/thread."
纠正 /proc/uptime 第二个数字的含义：是所有核心空闲秒数之和
文章说 /proc/uptime 的第二个数字是机器空闲的秒数，实际上它是所有核心空闲秒数的总和，所以这个数字可能大于第一个数字。
makkes查看英文原文
> The second number is how much of that time the machine has spent idle, in seconds Actually, the second number is the sum of the number of seconds that all cores on the machine have spent idle, so that number may be higher than the first one. Source: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-proc-uptime.html
历次讨论
同类还值得读
直接在浏览器中启动 Linux 内核
Boot a linux kernel right inside your browser.
Fabrice Bellard 的 JSLinux 页面，用 JavaScript 在浏览器里启动一个 Linux 内核，并提供一个可交互的终端环境。
工具与资源上首页 5 次 · 2011–2025bellard.orgHacker News 未公开功能与行为清单（2018）
A List of Hacker News's Undocumented Features and Behaviors (2018)
数据科学家 Max Woolf 整理的 Hacker News 未公开功能与行为清单，涵盖投票机制、排名算法、账号惩罚等社区运作细节。
工具与资源上首页 5 次 · 2019–2025github.comMapSCII：在终端中用盲文和 ASCII 渲染地图
MapSCII – Braille and ASCII map renderer for the console
MapSCII 是一个在命令行终端里渲染地图的开源工具，用盲文字符和 ASCII 字符把地理数据画成可交互浏览的字符地图。
工具与资源上首页 5 次 · 2017–2025github.com顶尖大学的免费在线课程
Free Online Courses from Top Universities
Open Culture 整理的一份免费在线课程合集，汇集了全球顶尖大学（如 MIT、斯坦福、耶鲁等）向公众开放的网络课程资源，涵盖音频、视频等多种形式。
工具与资源上首页 5 次 · 2010–2022openculture.com淘气字符串：容易引发用户输入问题的字符串清单
Naughty Strings: A list of strings likely to cause issues as user-input data
一个 GitHub 仓库，收录了大量容易让程序出问题的用户输入字符串，如特殊字符、emoji、SQL 注入片段、系统命令等，供开发者用于测试输入处理逻辑。
工具与资源上首页 4 次 · 2015–2020github.com