用Linux感觉低效吗?来看看这几个技巧!

本文介绍提高Linux工作效率的技巧,包括使用bd命令快速跳转目录、利用terminator实现终端分屏,以及选择优秀的Markdown编辑器Tpyora,帮助你在Linux环境下更加高效地工作。


Linux已经成为目前最火的操作系统之一,尽管现在的Linux用户很多,但很多使用Linux的同学发现,他们在Linux下的工作效率并不高,那么这是为什么呢?其实使用Linux也可以很舒适,通过一些技巧,也可以让工作效率大大提升。本文将介绍一些有助于提高Linux工作效率的技巧,让我们的工作变得变得更为舒适、优雅。

一、跳转目录随心所欲

1. bd 命令

如果当前目录很深,那么要往上跳转多层目录,就需要执行“cd …/…/…/…”这样的命令,而且不小心还容易弄错层数,显得有点傻。不过使用bd命令,一切都会有所不同。

bd是第三方命令,需要使用下面的命令安装。

sudo wget --no-check-certificate -O /usr/bin/bd https://raw.githubusercontent.com/vigneshwaranr/bd/master/bd
sudo chmod 777 /usr/bin/bd
echo 'alias bd=". bd -si"' >> ~/.bashrc
source ~/.bashrc

注意,在安装完bd命令后,需要使用chmod命令设置bd的可执行权限,否则bd默认是没有执行权限的。如果想忽略大小写,可以使用-si命令行参数,本例为bd -si起一个别名,也就是说,只要输入了bd,就相当于bd -si。修改.bashrc文件后的样式如下图所示。

最后使用source命令执行.bashrc文件,让配置生效。

现在来看一下bd命令如何用。如果只是执行bd命令,那么会一层一层往上退,相当于执行“cd …”命令。

现在假设当前的目录如下:

/root/software/person/slib/test/your

如果要立刻回到slib目录,只需要输入“bd slib”,bd会自动匹配到slib,并且立刻跳转到该目录。如果有多个匹配,则回到最近一个slib目录。除此之外,还可以进行头部匹配,例如,输入“bd s”,bd会匹配所有以s开头的目录,这里有2个:software和slib,根据最近匹配原则,bd会跳转到slib目录,当然,如果在slib目录下再次输入“bd s”,那么则跳转到software目录。

2. cd命令的常用技巧

cd命令后面不跟任何参数,可以回到home目录,相当于cd ~。

cd 后面不跟任何参数,回用户主目录,等同:cd ~。

cd
cd ~

cd - 回退,返回之前目录:

cd -

3. 自定义目录跳转命令

在Linux中可以使用alias命令自定义命令,为了方便调整目录,可以将经常要跳转的目录做成自定义命令。例如,要跳转到/software/nginx/conf目录,可以使用下面的命令自定义跳转命令。

alias nc='cd /software/nginx/conf'

然后只要执行nc,就会从任何目录跳转到/software/nginx/conf目录。为了让开机时自动起作用,可以将上面的命令加到profile文件或其他启动文件中。

二、终端也可以分屏

在很多场景下需要同时执行多个命令,而且需要同时观看执行结果,这就需要同时显示多个窗口。按传统的做法就是启动多个终端,不过一不小心将终端最小化,还需要一个一个重新切换到前台,很麻烦。为了解决这个问题,可以使用一个第三方的工具,这就是terminator。

如果读者使用的是centos,需要使用下面的命令安装terminator:

yum install terminator

如果读者使用的是ubuntu,需要使用下面的命令安装terminator:

apt-get install terminator

要注意的是,使用terminator必须安装图像接口,如果只安装了命令行接口,是无法使用terminator的,所以这里使用ubuntu演示terminator的使用。

安装完terminator后,在终端中输入下面的命令就可以启动terminator :

terminator &

启动后,在右键菜单中会有常用的功能,如水平分割屏幕,垂直分割屏幕等,如下图所示:

分屏后的效果如下图所示:

terminator可以分别对每一个分屏单独进行设置,如设置不同的字体尺寸等。在右键菜单中单击“配置文件首选项”菜单,会弹出如下图的设置菜单,里面有很多设置,包括快捷键等便捷操作方式。大家可以根据需要自行探索。

三、选一个好的Markdown编辑器,就和选一个好的伴侣一样非常重要

经常写博客的同学肯定非常熟悉Markdown,这是一种文件格式,可以插入文本、图像、HTML等元素,非常适合编辑一般格式的文档。在Linux下挑选一款合适的Markdown编辑器尤为重要,这回对文档编辑工作起到事半功倍的效果,这里推荐使用Tpyora。读者可以使用下面的命令安装Tpyora。

wget -qO - https://typora.io/linux/public-key.asc | sudo apt-key add -
sudo add-apt-repository 'deb https://typora.io/linux ./'
sudo apt-get update
sudo apt-get install typora
<think>嗯,我收到了用户的查询,是关于服务器CPU负载100%但top命令没有高负载进程的问题。首先需要仔细分析用户的问题描述。用户提到服务器多个CPU负载显示100%,但用top查看时没有发现任何进程占用很高的CPU。这说明负载高不是因为用户空间的进程,而是其他原因导致的。 首先,我得回忆一下Linux系统负载的含义。系统负载包括运行队列中的进程和不可中断状态的进程(比如等待I/O的进程)。用户给的引用里提到大桥和车辆的比喻,当负载达到1.7以上时说明有大量等待的进程。这可能指向I/O等待问题,因为不可中断的进程不会被top算入CPU使用率,但会计入负载。 然后思考可能的原因。用户已经排除了常见进程的问题,所以需要从其他方向考虑。第一个想到的是I/O瓶颈,比如磁盘读写过慢,导致进程阻塞在D状态(不可中断睡眠)。这时候可以用iostat或iotop检查磁盘使用率是否过高,特别是%util和await指标。如果磁盘响应时间长,说明存在I/O问题。 另外,中断处理也可能导致负载高。硬件中断由内核处理,不会显示在用户进程的CPU占用中。使用mpstat查看每个CPU核心的中断情况,或者检查/proc/interrupts文件,看是否有特定设备的中断异常增多,比如网卡或磁盘控制器。 还有可能是内核态的任务,比如系统调用频繁或锁竞争。使用top命令按H键查看内核线程(kworker),或者用pidstat -u检查是否有内核进程占用高CPU。另外,vmstat的sy(系统CPU时间)指标如果很高,说明内核操作消耗资源。 短生命周期进程也是一个方向。top默认刷新间隔可能抓不到瞬间结束的进程,这时候用atop或者开启top的批处理模式记录快照,有助于捕捉这类进程。或者使用perf工具生成CPU使用报告,查看调用栈信息。 用户提到多个CPU同时满载,可能涉及进程在不同核心间迁移,或者中断均衡的问题。检查irqbalance服务是否运行,以及中断分配情况。此外,资源限制如cgroup可能限制进程的CPU使用,导致负载堆积但进程显示不高。 解决方案步骤方面,需要逐步排查。先用vmstat和mpstat确认系统态和中断情况,再用iostat检查I/O。然后检查中断分布,排查短进程,最后审查资源限制配置。引用中的日志分析命令可能帮助不大,因为问题不在外部请求,但可以辅助排除恶意流量导致的中断。 </think>好的,这个问题很经典,也是服务器运维中常见的疑难杂症之一。**核心问题在于:Linux 的 `top` 命令显示的 CPU 使用率 (%) 和系统负载 (Load Average) 反映的是不同的方面,并且在特定情况下,可能导致负载 (Load Avg) 飙到 100% 而 `top` 显示的进程 CPU 使用率却不高。** 结合您提供的引用和我们理解的需求,分析原因和解决方案如下: ## 根本原因分析 (为什么负载高而 top 没有高 CPU 进程?) 1. **I/O 等待 (Disk I/O Wait - `wa`) 是最大嫌疑:** * **引用[1]中的“桥”比喻非常好理解负载:** 负载高意味着“桥”上或等待上“桥”的“车”(任务)很多。但这些任务**未必都在使用 CPU**,它们可能大部分时间在**等待**。 * 当服务器存在严重的磁盘 I/O 瓶颈时(例如:数据库频繁读写、大量小文件操作、慢速磁盘/NFS、磁盘故障、RAID 重建等),进程会进入 **`D` 状态 (Uninterruptible Sleep/Disk Sleep)**。 * **关键点在于:** * **`D` 状态的进程会被计入负载平均值 (Load Average)。** 因为它们确实是系统中需要处理的任务(只是卡在等待 I/O)。 * **`D` 状态的进程在 `top` 命令的 `%CPU` 列显示为 `0.0` 或很低的值。** 因为它们此时没有使用 CPU,只是在等待 I/O 完成。 * 如果系统中大量的进程都处于 `D` 状态等待 I/O,那么: * **Load Average 会飙升**(因为很多任务在排队等待)。 * **`top` 的 `%CPU` 占用看起来不高**(因为 CPU 本身可能很空闲,都在等 I/O)。 * **`top` 的 `wa` (I/O Wait) 百分比会非常高。** 这是最重要的指标!请务必在 `top` 的第一行查看 `%wa` 的值。如果它接近 100%,就是铁证。 * **总结:高负载 (`D`状态进程堆积) + 低进程 CPU% + 高 `wa` = 强烈的 I/O 瓶颈信号。** 2. **中断风暴 (Interrupt Storm):** * CPU 不仅要处理用户进程的请求,还要处理硬件(网卡、磁盘控制器等)发来的中断请求 (IRQ)。 * 如果硬件故障(如坏网卡、磁盘控制器问题)或配置不当(如错误的驱动程序、高流量导致网卡中断激增),CPU 可能会花费**绝大部分时间在内核态处理中断 (`hi` - hardware irq, `si` - software irq)**。 * **关键点在于:** * 处理中断消耗的 CPU 时间**会计入 `top` 第一行的 `%hi` 和 `%si`**,而不是计入某个特定用户进程的 `%CPU`。 * 如果中断处理程序本身设计不佳或中断数量过大,CPU 会被大量占用,导致整体系统卡顿和负载升高(中断处理程序调度也算任务)。 * 此时 `top` 可能显示用户进程的 `%CPU` 不高(因为它们被中断抢占了),但 `%hi`/`%si` 会非常高,且 Load Avg 也会升高。 3. **内核态操作 (Kernel Space CPU Usage):** * 除了中断,内核还需要处理系统调用、内存管理、网络协议栈、文件系统操作等。如果某个内核操作本身非常耗时(例如:处理海量小包的网络连接、复杂的文件系统操作、频繁的上下文切换、内核锁竞争激烈),CPU 会花费大量时间在内核态 (`%sy` - System CPU time)。 * **关键点在于:** * 这部分 CPU 消耗**计入 `top` 第一行的 `%sy`**,而不是某个特定用户进程的 `%CPU`。 * 如果 `%sy` 非常高(远超正常水平,比如 >30%-50% 甚至更高),并且 Load Avg 也高,而用户进程 `%CPU` 不高,说明内核自身可能是瓶颈。 * 检查内核线程(在 `top` 中按 `Shift+H` 显示线程,看 `kworker` 或类似内核线程的 CPU 占用)。 4. **短生命周期进程 (Short-lived Processes):** * 如果有很多进程启动后**运行时间非常短**就结束了(例如:频繁的 `cron` 任务、脚本调用某个命令),`top` 可能抓不到它们的高 CPU 瞬间。 * **关键点在于:** * 这些进程在其短暂的生命周期内消耗了大量的 CPU 时间(瞬间拉高负载),但刷新 `top` 时它们已经消失或 CPU 使用率降到很低。 * 它们对负载的贡献**会持续存在一段时间**(Load Average 是按时间衰减的平均值),导致你看到高负载时,却找不到一个持续高 CPU 的进程。 * 需要工具来捕捉这些瞬间的高 CPU 进程。 5. **CPU 调度问题 / 进程迁移开销:** * 如果进程在 CPU 核心之间频繁迁移(NUMA 架构下尤其明显),或者调度器本身成为瓶颈,也可能导致 CPU 时间被浪费在调度上(体现在 `%sy`),负载升高而用户进程 CPU 使用率统计不高。 ## 解决方案 (如何排查与解决?) ### 第一步:确认瓶颈类型 (使用综合监控工具) 1. **查看 `top` 关键行:** * **第一行 (`Cpu(s)`):** 重点看 `%us` (用户态), `%sy` (内核态), `%id` (空闲), `%wa` (I/O 等待), `%hi` (硬中断), `%si` (软中断)。哪个接近 100% 哪个就是主因! * **第二行 (`Tasks`):** 看有多少进程处于 `D` (Uninterruptible sleep) 状态。大量的 `D` 状态进程是 I/O 问题的直接证据。 * **按 `1` 键:** 查看每个 CPU 核心的使用情况分布。是否所有核心都高?还是负载集中在某几个核心?这有助于判断是否是中断亲和性或特定核心问题。 2. **使用 `vmstat` (动态监控整体状态):** ```bash vmstat 1 5 # 每秒刷新一次,共5次 ``` * 重点关注列: * `r` (等待运行的进程数):高值对应高负载。 * `b` (不可中断睡眠进程数):高值对应大量 `D` 状态进程 (I/O 瓶颈)。 * `us`, `sy`, `id`, `wa`:含义同 `top` 第一行。 3. **使用 `iostat` (监控磁盘 I/O):** ```bash iostat -dx 1 # 每秒刷新一次,显示扩展磁盘统计 ``` * **关键列 (`Device`):** * `%util`: 设备利用率百分比。**长时间接近 100% 表示设备饱和,是严重瓶颈。** * `await`: 平均 I/O 响应时间 (ms)。值越高,I/O 越慢。 * `r/s`, `w/s`: 每秒读写次数。 * `rkB/s`, `wkB/s`: 每秒读写数据量 (KB)。 * 找出哪个磁盘设备 (`sda`, `sdb`, `nvme0n1` 等) 的 `%util` 和 `await` 异常高。 4. **使用 `mpstat` (监控每个 CPU 核心中断和开销):** ```bash mpstat -P ALL 1 # 每秒刷新一次,报告所有 CPU 核心的统计信息 ``` * 查看每个核心的 `%irq` (硬件中断), `%soft` (软件中断), `%guest` (虚拟机开销), `%gnice`, `%idle` 等。判断中断是否集中在某个核心。 5. **使用 `dstat` (全能监控):** ```bash dstat -tcdngy 1 # 每秒刷新,显示时间、CPU、磁盘、网络、系统负载、中断统计 ``` * 一个命令整合 `vmstat`, `iostat`, `ifstat` 等信息,非常直观。 ### 第二步:针对性排查与解决 #### A. 如果确定是 I/O 瓶颈 (`%wa` 高, `vmstat b` 高, `iostat %util` 高) 1. **定位高 I/O 进程:** * **`iotop`:** ```bash iotop -oPa # 显示当前正在进行 I/O 的进程和线程,按 I/O 使用排序 ``` 这是定位 I/O 消耗者的最佳工具。 * **`pidstat`:** ```bash pidstat -d 1 # 每秒报告一次进程的 I/O 统计(kB_rd/s, kB_wr/s) ``` 2. **分析 I/O 来源:** * 找到高 I/O 进程后,分析它在做什么: * 是数据库 (MySQL, PostgreSQL)? 检查慢查询、索引、配置。 * 是日志记录 (syslog, journald, application logs)? 检查日志级别、轮转策略、写入量。 * 是文件服务 (NFS, Samba)? 检查客户端访问模式。 * 是备份任务? 检查备份策略和时间。 * 是应用本身 (PHP, Java)? 对应引用[1]中提到的 PHP 进程问题,虽然 `top` 没显示高 CPU,但如果 PHP 脚本在疯狂读写文件/数据库,也可能导致高 I/O Wait。 * **结合引用[2]的日志分析思路(但目标不同):** ```bash # 查看哪个进程在读写哪些文件 (需要 root) lsof -p <高IO进程PID> | grep -E "REG|DIR" # 或用更强大的工具 opensnoop-bpfcc # (需要安装 bcc-tools) 实时跟踪文件打开 ``` 3. **解决 I/O 问题:** * **优化应用:** 减少不必要的磁盘读写(如缓存、批量操作、优化查询、异步写日志)。 * **调整文件系统:** 使用更高效的文件系统 (`ext4`, `xfs`),调整挂载参数 (`noatime`, `nodiratime`, `data=writeback` - **评估风险**)。 * **升级硬件:** 更换更快的 SSD (NVMe),增加内存(减少 Swap 使用),优化 RAID 级别 (RAID 10 通常比 RAID 5/6 写性能好)。 * **分散压力:** 将高 I/O 服务(数据库、日志)迁移到独立的磁盘或服务器。 * **检查磁盘健康:** `smartctl -a /dev/sdX`。 * **内核参数调优 (谨慎!):** 如调整 I/O 调度器 (`deadline`, `kyber`, `none`),虚拟内存参数 (`vm.dirty_ratio`, `vm.dirty_background_ratio`)。**调优前务必理解含义并备份。** #### B. 如果确定是中断问题 (`%hi`/`%si` 高) 1. **定位中断来源:** * **查看 `/proc/interrupts`:** 这个文件动态显示每个 CPU 核心处理的中断计数和中断号对应的设备。观察哪个中断号 (IRQ) 的计数增长异常快。 ```bash cat /proc/interrupts watch -d 'cat /proc/interrupts' # 动态高亮变化 ``` * **关联 IRQ 和设备:** 通过中断号查找关联的设备 (通常设备名在中断号旁边显示,如 `eth0`, `ahci`, `nvme`)。也可以查看 `/proc/irq/<IRQ_num>/spurious` 和 `/proc/irq/<IRQ_num>/` 下的信息辅助判断。 2. **解决中断问题:** * **硬件检查:** 如果是特定设备(如某块网卡 `eth0`)中断异常高,检查硬件是否故障或驱动有问题。尝试重启该设备 (`ifdown eth0 && ifup eth0`) 或更新/回滚驱动程序。 * **调整中断亲和性 (IRQ Affinity):** 手动将特定设备的中断绑定到少数几个 CPU 核心上(通常是 CPU0 以外的核心),避免所有核心都被中断打搅。这需要根据 `/proc/interrupts` 的信息和 CPU 拓扑来操作,通常通过 `/proc/irq/<IRQ_num>/smp_affinity` 文件设置。**操作需谨慎,建议查阅相关文档。** * **启用中断合并 (Interrupt Coalescing):** 对于网络设备 (`ethtool`),可以调整参数让网卡积累多个数据包后再触发一次中断,减少中断频率。例如: ```bash ethtool -C eth0 rx-usecs 100 # 设置接收中断延迟为100微秒 (具体值需测试) ``` * **检查 `irqbalance`:** 确认 `irqbalance` 服务是否在运行 (`systemctl status irqbalance`)。它通常负责优化中断在 CPU 间的分配。在特定场景下(如虚拟机),有时关闭它并手动绑定 IRQ 效果更好,但这需要深入理解和测试。 * **减少不必要的网络流量/连接:** 对应引用[2]的思路,检查是否被异常 IP 攻击或扫描导致网络中断暴增: ```bash netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n # 查看连接数统计 # 或者用更现代的 ss ss -ntu state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n ``` 结合防火墙规则 (`iptables`/`nftables`) 或 TCP 参数调优缓解。 #### C. 如果确定是内核态开销高 (`%sy` 高) 1. **定位高内核 CPU 的进程/线程:** * **在 `top` 中按 `Shift+H` 显示线程。** * **使用 `pidstat`:** ```bash pidstat -u 1 | grep -v PID # 每秒刷新进程CPU统计,包括 %system pidstat -t 1 # 每秒刷新线程CPU统计 ``` 找出 `%system` 列高的进程或线程。 2. **分析高 `%sy` 原因:** * **系统调用 (syscall) 过多:** 使用 `strace` 或 `perf trace` 追踪问题进程的系统调用。优化应用,减少不必要的系统调用(例如,使用更高效的库函数)。 * **上下文切换过多 (`cs` in `vmstat`):** 高 `cs` 值意味着进程/线程切换频繁。检查 `pidstat -w` 或 `vmstat` 的 `cs` 列。 * 原因可能是:进程/线程过多、锁竞争激烈、调度策略不当。优化应用并发模型,减少锁争用。 * **内存管理开销:** 检查 `vmstat` 的 `si`/`so` (Swap In/Out) 是否持续非零。频繁的 Swap 会极大增加 `%sy`。解决方法:增加物理内存,优化应用内存使用,减少 OOM 风险 (`vm.overcommit_memory`, `vm.swappiness` 参数调优 - **需谨慎**)。 * **文件系统锁:** NFS 或其他网络文件系统有时会遇到锁问题。 * **内核 Bug 或低效路径:** 特定内核版本可能存在性能问题。考虑更新至稳定版内核。 #### D. 如果怀疑是短生命周期进程 1. **使用能捕捉瞬间高 CPU 的工具:** * **`atop`:** 功能强大的交互式监控工具,记录历史信息,能回溯查看过去高 CPU 的进程。 * **`top` 批处理模式 + 日志:** ```bash top -b -d 1 -n 60 > top.log # 每秒采样一次,共60秒,输出到文件 ``` 然后分析 `top.log`,寻找虽然总采样时间内平均 CPU 不高,但单次采样瞬间 CPU 很高的进程。 * **`perf`:** Linux 性能分析神器。 ```bash perf record -g -a sleep 10 # 记录所有CPU 10秒内的性能事件和调用栈 perf report # 分析报告,查找热点函数和调用堆栈 ``` 这需要一些学习成本,但非常强大,能深入到函数级别。 2. **检查计划任务 (`cron`):** 查看 `/etc/crontab`,`/etc/cron.d/*`, 以及用户 `crontab -l`,是否有高频率或高消耗的任务在运行。 ## 总结与关键步骤流程图 ```mermaid graph TD A[服务器负载高 Load Avg > CPU 核心数] --> B[top 命令检查] B --> C1{%wa 高?} --> |Yes| D[I/O 瓶颈] B --> C2{%hi/si 高?} --> |Yes| E[中断问题] B --> C3{%sy 高?} --> |Yes| F[内核态瓶颈] B --> C4{用户进程%CPU 低?} --> |Yes| G[检查 D 状态进程] G --> |D 状态进程多| D G --> |D 状态不多| H[短生命周期进程?] H --> |Yes| I[用 atop/perf/top -b 捕获] H --> |No| J[CPU 调度/进程迁移?] D --> K[使用 iostat/iotop 定位磁盘和设备] D --> L[定位高 IO 进程 pidstat -d/iotop/lsof] D --> M[优化应用/磁盘/FS/硬件] E --> N[查看 /proc
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值