标签：linux

共 476 篇相关文章

IT 累计浏览 2,465

大量小包的CPU密集型系统调优案例一则

这是一篇典型的方案/架构类文章，作者从一个处理大量小数据包的生产系统调优实践出发，详细分享了将单网卡流量从100M提升至230M（预估可达480M）且CPU负载保持均衡的完整优化路径。核心方案围绕着“硬件选型与内核调优”展开。作者首先强调了必须使用支持MSI-X和多队列的网卡，这是性能提升的硬件基础。在软件层面，他将操作系统从RHEL 5升级至RHEL 6.1，以利用其内核对Google RPS/RFS补丁的支持，从而将软中断负载均衡到多个CPU核心。此外，文章还详细说明了如何手动关闭irqbalance服务，并通过设置smp_affinity将网卡队列中断精确绑定到指定CPU，以实现更精细的负载控制。对于发送方向，作者也提到了利用内核2.6.38引入的XPS特性进行优化。整个调优过程有很强的数据支撑，作者展示了调优后单网卡承载15万/秒数据包、系统负载为0且各CPU核心均保有余量的生产环境截图，并解释了因网卡队列数与CPU数不匹配时，为何不能简单将中断广播到所有CPU，而需要采用物理/固定模式进行一对一绑定。文章为类似网游、CDN等“小包量大”的场景提供了一套可落地的系统性能挖掘手册。

IT 累计浏览 3,880

linux下cp，mv进行动态库覆盖问题分析

这篇讲的是一个生产环境中典型的“隐形地雷”：明明只是想更新一个动态库文件（.so），为什么用 cp 命令覆盖后，正在运行的程序就莫名崩溃了？作者从一次周会讨论的问题出发，抽丝剥茧地分析了这个现象的深层原因。文章先厘清了 Linux 文件系统的两个关键概念：inode 存储文件元数据，dentry 建立文件名到 inode 的映射。核心分析由此展开：cp 和 mv 操作对正在被进程使用的文件影响截然不同。cp 命令本质是“打开目标文件并截断，然后写入新数据”，这个截断操作会通知内核释放该文件在内存中的所有页面映射。当程序再次执行到该库的代码时，会触发缺页中断，但因为原文件数据块已失效，内核无法正确填充内存，于是导致总线错误（bus error）或段错误（segment fault）。相比之下，mv 命令仅仅是重命名操作，只改变了目录项（dentry）的指向，并未影响文件本身（inode）及其内存映射，因此是安全的。文章通过 strace 跟踪和进程内存映射的视角，清晰展示了故障现场。结论很明确：对于已被进程动态链接的库文件，在线更新的正确姿势是 mv（将新文件重命名为原名），而不是 cp。

IT 累计浏览 4,025

怎样用core文件调试你的linux程序？

这篇讲的是如何配置Linux系统，让它能在程序异常崩溃时自动生成核心转储（core dump）文件，从而方便你找出程序崩溃的具体原因。作者从默认Linux禁止生成core文件这个常见限制出发，一步步演示了解锁方法。核心是使用`ulimit -c unlimited`命令，但文章也特别指出了它的临时性——设置仅对当前会话有效，重启或重登就会失效。如果想要更持久的配置，可以修改`/etc/profile`，不过作者也留下了思考：为什么不推荐这样做呢？更深入的配置在于控制core文件“生在哪里”和“叫什么名字”。文章详细讲解了通过编辑`/etc/sysctl.conf`文件，设置`kernel.core_pattern`参数来实现。例如，将核心文件统一生成到`/tmp`目录，并使用包含程序名、进程ID、信号值等信息的规则来命名，这对于同时调试多个程序非常方便。最后，文章点明了核心文件的归宿：使用强大的gdb调试器载入这个文件，就能回溯程序崩溃现场，定位问题代码。整个流程非常实用，是每个Linux开发者都应该掌握的调试技巧。

IT 累计浏览 1,737

DNSv6和DNS64简单配置

这篇讲的是如何在Linux系统上配置IPv6环境下的DNS服务，特别是DNSv6和DNS64功能。作者从上一篇DHCPv6的部署延伸出来，直指DNS作为互联网入口在IPv6时代的重要性。文章以Bind服务为例，给出了清晰的实操路径。它从最简单的源码安装开始，然后聚焦于核心配置：如何让DNS监听IPv6地址（`listen-on-v6`指令是关键），并配置了测试用的IPv6地址段。配置过程还包括了关闭防火墙、设置SELinux等便于测试的准备工作，同时提醒线上环境需合理配置安全策略。最终，文章提供了一个精简的主配置文件（`/etc/named.conf`）示例，让读者能快速抓住启用IPv6 DNS服务的配置要点。整体而言，这是一篇步骤明确、重点突出的配置指南，适合需要快速上手IPv6 DNS服务搭建的运维人员参考。

IT 累计浏览 3,273

Linux内核中通过文件描述符获取绝对路径

这篇深入探讨了一个内核开发中具体且实用的场景：当你只知道一个进程的pid和它持有的某个文件描述符fd时，如何在内核里一步步找回该文件在磁盘上的绝对路径。文章的核心思路是沿着内核的数据结构进行“导航”。它首先通过pid找到进程的task_struct，再从中取出进程打开的文件表files_struct。以fd为索引，就能定位到代表这个文件的内核结构体file。接下来是最关键的两步：从file中获取封装了dentry（目录项）和挂载点信息的path结构，并最终调用内核函数`d_path()`，将这一系列结构解析为人类可读的绝对路径字符串。整个实现过程清晰展示了Linux内核管理进程与文件系统的精巧层次。这种从进程到文件、再到路径的逆向追踪能力，对于调试内核模块、进行系统监控或编写特定内核功能来说，是一项非常基础且重要的技术。

IT 累计浏览 4,066

Intel 10-GbE 网卡性能优化[翻译]

这篇翻译文档详细拆解了如何将一块 10GbE 网卡的性能从默认的“可用”状态压榨到“极限”。作者指出，Linux 的默认网络栈配置（如缓冲区大小、TCP 内存分配）是为了可靠性而非峰值吞吐量设计的，这对万兆网卡尤其不利。文章的核心思路是分层优化，并基于 Intel 官方驱动文档提供了实操步骤。优先级最高的操作是在交换机和服务器两端启用巨型帧（MTU 9000），这能大幅提升大流量传输效率。其次是调整内核的 `sysctl` 参数，例如关闭 SACK 和时间戳、将 TCP 收发缓冲区统一设为 10MB，并提高网络设备积压队列上限。更进阶的操作是通过 `setpci` 命令调整网卡 PCI-X 总线的 MMRBC 寄存器，将内存读块大小提升到 4KB，以增强对突发流量的处理能力。文章最有说服力的部分在于其测试数据：经过上述优化，使用 `iperf` 测试的吞吐量从优化前的约 4.70 Gbits/sec 飙升至 9.90 Gbits/sec，几乎跑满了万兆带宽。作者强调，优化过程需配合压力测试（如 iperf、netperf）来验证效果，结果可能因硬件和网络环境而异。对于需要榨干网卡性能的 HDFS、高性能计算等场景，这套调优方法提供了清晰的参考路径。

IT 累计浏览 16,308

Linux如何统计进程的CPU利用率

想在脚本里“非阻塞”地获取Linux进程CPU利用率，却遇到top需要等1秒、ps只显示平均值的问题？这篇文章就从这个实际需求出发，直接深入到/proc文件系统，带你看清背后的原理。文章的核心是对比两种思路：使用现成工具vs手动计算。作者明确指出，像top和ps这样的工具，虽然方便，但本质上提供了不同的“快照”——ps给出的是进程生命周期的平均利用率，而top需要至少1秒的采样间隔。关键差异在于，它们都无法满足对“当前时刻”瞬时利用率的精确、非阻塞获取。真正的解决方案隐藏在/proc/stat和/proc/[pid]/stat这两个文件中。文章详细拆解了其中各列的含义，并给出了具体的计算公式：在两个时间点分别读取系统总CPU时间片和进程CPU时间片，通过差值比来计算这段时间内的利用率。这就像用两张“照片”的位移差来算速度，揭示了CPU利用率本质是一个时间段内的统计量，而非一个瞬时值。最后，文章还解释了ps命令中%CPU指标的准确含义，即它是进程自启动以来的累计平均利用率。如果你需要在监控脚本中实现高精度的进程CPU统计，或者对系统工具背后的实现原理感到好奇，这篇文章提供的思路和细节会很有参考价值。

IT 累计浏览 1,726

使用 lsyncd 同步本地和远程目录

这篇讲的是如何解决文件同步的实时性与服务器资源消耗之间的矛盾。作者从常见的 rsync + cron 方案切入，指出其“定时轮询”的固有局限——间隔设得太短则频繁启动 rsync 增加负担，设得太长则同步不及时。文章的核心方案是引入基于 Linux inotify 事件驱动的 lsyncd 工具。它不同于 cron 的定时执行，而是像一位尽职的哨兵，持续监测本地目录的变动。一旦捕捉到文件或目录的变更事件（默认触发条件是每20秒或累积1000次写入），便立即触发 rsync 或 rsync+ssh 进行精准同步。这种“按需启动”的模式，从根本上避免了无谓的资源消耗。作者用清晰的步骤，演示了从安装、手动创建配置目录，到编写 Lua 配置文件（重点指明 source、host、targetdir 三个参数）和设置无密码 SSH 登录的全过程。配置完成后，lsyncd 服务启动即可自动守护同步任务。最终，文章指出通过简单修改配置文件（将远程同步改为本地目录同步），lsyncd 同样能胜任本地目录镜像备份的任务，提供了灵活的文件同步选项。

IT 累计浏览 2,008

使用 SysRq 键安全重启挂起的 Linux

这篇讲的是，当一台 Linux 服务器（比如 NFS 文件服务器）完全卡死——能 ping 通但无法通过 SSH 或本地终端登录时，在万不得已需要重启前，如何避免数据丢失和文件系统损坏。问题的根源在于，Linux 为了性能会将大量数据暂存在内存缓存中，而非实时写入磁盘。如果此时强制断电重启，这些尚未落盘的数据就会丢失，导致不一致或损坏。文章的解决方法是利用 Linux 内核的“Magic SysRq”机制。这个机制很特别，它工作在系统服务层之下，只要系统还能响应键盘中断，就能通过一组特定的按键组合执行底层操作。作者详细介绍了标准的安全重启序列：Alt + SysRq + R-E-I-S-U-B。这六个字母并非随意组合，而是一套严谨的操作流程：先让键盘进入原始模式（R），然后温和地终止除初始化进程外的所有进程（E、I），接着将内存缓冲区强制同步到磁盘（S），再将文件系统重新挂载为只读（U），最后安全重启（B）。每一步之间还需留出适当的等待时间。对于紧急情况，文章也给出了一个实用简化版：通常只用 Alt + SysRq + S（同步磁盘）和 Alt + SysRq + B（重启）。在按下 S 键并看到同步完成的提示后，再按 B 键，就能在数据安全的前提下完成重启。这确实是在系统看似完全无解时，一个能挽救数据和系统的关键技巧。

IT 累计浏览 5,143

让进程在后台可靠运行的几种方法

这篇讲的是如何在 SSH 断开或终端关闭后，让进程继续可靠运行的经典方法。文章从一个常见痛点出发：在远程执行耗时任务时，网络波动或误关终端会导致任务中断。作者围绕如何规避 HUP（挂断）信号，对比了多种解决方案。核心方法包括：最常用的 `nohup`，让进程忽略 HUP 信号；使用 `setsid` 或 `(cmd &)` subshell 技巧，让进程在新会话中运行，从而脱离原终端。文章特别指出了一个关键差异：`nohup` 启动的进程父进程仍是原终端，而 `setsid` 启动的进程父进程会变为 init（PID=1），从根源上隔绝了信号影响。对于已经提交的任务，文章也介绍了补救措施：通过 `Ctrl-Z` 挂起、`bg` 后台运行，最后用 `disown` 命令将其移出作业表，使其不再受 HUP 信号影响。这些方法各有简单的操作示例，非常适合临时任务或未预先规划的场景。总的来说，文章系统梳理了从预防到补救的完整工具链，帮助你在不同情境下灵活选择，确保关键进程不会意外中断。

IT 累计浏览 3,472

Linux内核代码中的脏话统计

这篇讲的是作者从一个已停更的“the linux kernel fuck count”项目获得灵感，对Linux内核的C、H及汇编源代码进行了一次系统的脏话统计分析。作者按版本号，分别从脏话的绝对数量和代码行的脏话密度两个维度绘制了图表。数据呈现了一个有趣的趋势：从2.4版本开始，脏话的绝对数量显著攀升。然而，考虑到同期内核代码总量也在激增，折算下来，平均每行代码的“脏话密度”反而是在下降的。文章坦诚地分享了统计方法的局限，比如会将词中包含的词也计入，以及受FreeBSD正则引擎内存泄漏的影响未能优化。作者最终开源了统计脚本，但也自嘲其代码质量混乱。这本质上是一次用独特视角审视开源社区文化的趣味实践，既看到了开发者情绪的外露，也反映了代码库膨胀带来的稀释效应。

IT 累计浏览 4,847

Linux内核协议栈对于timewait状态的处理

这篇文章从一次生产环境的运维问题切入，详细剖析了Linux内核从2.6.18升级到2.6.32后，系统TIME_WAIT状态连接数显著增多的根因。作者的核心工作是对两个版本内核的代码进行diff，精准定位到了`net/ipv4/inet_timewait_sock.c`文件中的一处关键变更。问题的核心在于`inet_twdr_hangman`函数里，一行负责轮转回收槽位的代码`twdr->slot = ...`的位置被移动了。在旧版本中，无论当前槽位（slot）的timewait块是否被完全清理，该自增操作都会执行；而在新版本中，它被放入了一个条件分支，仅当当前槽位被成功清空时才执行。这个看似微小的时序调整，改变了内核回收timewait块的调度逻辑，最终导致了回收变慢和积压。文章不仅给出了结论，更通过分析`inet_timewait_death_row`数据结构与`inet_twdr_hangman`的定时回收机制，完整还原了问题发生的底层路径。对于需要理解TCP连接生命周期管理，或是面临类似内核升级后网络连接数异常的工程师来说，这篇深入源码实现的排障手记提供了非常具体的思路和技术细节。

IT 累计浏览 10,488

linux内核研究笔记(一）内存管理 – page介绍

这篇讲的是 Linux 内核内存管理中最基础的数据结构——`struct page`。作者以一名服务器程序员的视角，从对“虚拟内存”的好奇出发，深入内核底层，剖析了物理内存管理的核心。文章首先展示了 `page` 结构体的关键字段，并指出它是内核描述物理内存页的最小单元。核心在于，这片物理页在不同场景下被赋予不同角色：作为页缓存（`mapping` 域）加速文件IO，作为私有数据（`private` 域）用于缓冲或交换，或作为页表映射支撑用户空间的 `malloc`。作者进一步通过宏定义，解释了页帧号（pfn）与 `page` 指针、物理地址、内核逻辑地址之间的转换机制。比如 `pfn_to_page` 本质上是操作全局数组 `mem_map`，巧妙地将连续的物理内存抽象为可索引的对象。文章还厘清了“内核逻辑地址”与“内核虚拟地址”的区别，并点明在 x86_32 架构下 `PAGE_OFFSET` 的由来。理解 `page` 结构是窥探内核如何管理伙伴系统、slab分配器乃至整个虚拟内存系统的钥匙。这篇笔记从最底层的数据结构切入，为后续理解更复杂的内存管理机制打下了坚实基础。

IT 累计浏览 8,542

找回linux丢失的磁盘空间

这篇讲的是服务器磁盘空间莫名“消失”的一次典型排查。作者发现 `df` 命令显示磁盘使用率接近 100%，但用 `du` 统计具体目录占用时，两者结果却相差甚远，这显然不正常。在排除了常见的“挂载点覆盖”问题后，作者将矛头指向了另一个经典场景：已删除的文件仍被进程占用，导致其占用的空间无法释放，且 `du` 也统计不到。通过 `lsof | grep deleted` 命令，果然揪出了一个躲在后台、持续写入的巨大日志文件。解决方法很直接：终止那个持有文件句柄的进程，磁盘空间随即开始逐步释放。重启该进程后，日志也恢复正常写入。整个过程清晰地展示了 Linux 下磁盘空间“丢失”的一个常见原因及其高效定位与解决方法，对于运维人员非常有参考价值。

IT 累计浏览 6,456

Linux下如何知道文件被那个进程写

这篇讲的是一个运维中常见的棘手场景：Linux下文件持续增长，但用lsof等工具却找不到对应的写入进程。作者从一位同学的实际困扰出发，指出问题的普遍性，并给出了一个基于内核视角的解决方案。核心思路是，既然用户态工具难以追踪（可能是进程很快打开又关闭了文件），那就直接在内核的虚拟文件系统层进行监控。文章推荐使用SystemTap工具包中的inodewatch.stp脚本，它通过探测vfs.write事件，能根据文件所在的设备号（major/minor）和inode号，精准定位到正在执行写操作的进程。作者随后用一个生动的实验进行了演示：用dd命令在后台持续写入一个测试文件，通过stat命令获取其inode和设备信息，然后运行stap脚本。终端立刻输出了正在执行vfs_write的dd进程信息（进程名、PID），瞬间“破案”。整个排查过程清晰直观，展现了SystemTap在内核级故障排查中的强大能力。

IT 累计浏览 4,248

Linux下访问文件的基本模式

这篇讲的是Linux内核中几种常见的文件访问方式，作者从底层机制出发，对比了普通模式、同步模式、直接I/O、异步模式以及内存映射这五种模式的运作原理与核心差异。普通模式依赖页高速缓存，读阻塞、写缓存即返回，是默认的平衡选择。同步模式则通过置位O_SYNC标志，强制写操作直到数据落盘才返回，代价是更高的延迟，但确保了数据持久性。直接I/O（O_DIRECT）完全绕过页高速缓存，在用户空间与磁盘间直接传输，适合数据库等需要自主管理缓存的场景。异步模式通过aio系列系统调用实现非阻塞I/O，进程提交请求后可立即返回处理其他任务，提升了并发处理能力。内存映射则通过mmap将文件映射到进程地址空间，把文件操作转化为内存操作，简化了编程模型并可能提升大文件访问效率。文章清晰地拆解了每种模式下内核标志位的状态与数据流路径，帮助开发者理解不同I/O策略的适用场景——比如高性能存储系统可能倾向于直接I/O或异步模式，而追求开发简便性的应用则更适合内存映射。通过对比这些模式的适用场景和实现机制，文章为开发者提供了选择I/O策略的清晰指引。

IT 累计浏览 6,654

Linux下CPU的利用率

这篇讲的是如何真正理解Linux系统下CPU时间的构成，从而看懂利用率背后的含义。文章从内核时间基础切入，解释了HZ（时钟中断频率）、tick（中断间隔）和jiffies（中断累计次数）这几个关键概念，为你打下理解的底子。核心部分是将CPU时间拆解得明明白白：它并非一个整体，而是由用户态（User time、Nice time）、内核态（System time、Hardirq time、Softirq time）以及等待（Waiting time）、空闲（Idle time）和虚拟机偷取（Steal time）时间共同组成。文章直接给出了计算公式，让你能一一对应`top`命令输出中那些让人困惑的`%us`、`%sy`、`%id`等百分比，原来它们分别代表了不同时间段的占用情况。作者最后指明，`top`、`iostat`、`vmstat`这些常用工具的数据源头都是`/proc/stat`文件，其中的时间单位就是tick。搞清楚这些组成，当看到系统卡顿时，你才能从高企的`%sy`判断是内核子系统瓶颈，还是从高`%wa`看出是I/O等待拖了后腿，让性能分析有据可依。

IT 累计浏览 3,010

解决进程间共享内存，由于某个进程异常退出导致死锁问题

这篇讲的是在进程间共享内存编程中，因某个进程异常退出而导致死锁的经典坑。作者从一个线上服务重启后的超时问题出发，层层排查，最终定位到根源：一个读进程在持有读写锁时突然崩溃，导致锁的计数器（`nr_readers`）没有递减，写进程因此永远等不到锁，共享内存数据无法更新，最终引发服务故障。作者不仅用测试代码复现了这一问题，更深入探讨了如何解决。读写锁在这种场景下缺乏自动恢复机制。一个巧妙的出路是改用互斥锁，并设置其`PTHREAD_MUTEX_ROBUST_NP`属性（Robust锁）。当持锁进程死亡时，锁不会永久阻塞，而是返回`EOWNERDEAD`，后续线程调用`pthread_mutex_consistent_np`即可修复锁状态，使其恢复正常。此外，作者还提醒，通过共享内存交换数据时，务必增加完成标记，以确保数据在进程崩溃时不会处于不完整的中间状态。文章从实际故障切入，完整呈现了“发现问题-分析根因-测试验证-寻求方案”的解决链条，特别是对Robust锁的应用，为处理跨进程的异常状态恢复提供了非常实用的思路。

IT 累计浏览 6,901

Linux知识：为什么要用字符~来表示home目录

这篇讲的是Linux和Unix系统里一个常见却很少有人深究的细节：为什么用波浪号“~”来表示用户的home目录。答案其实藏在一段计算机硬件的历史里——这个用法直接沿袭自1970年代流行的Lear-Siegler ADM-3A终端机。文章指出，在这种老式终端上，波浪号“~”键与“Home”键（将光标移至行首）被设计在同一个物理按键上。当Unix系统的开发者需要为home目录找一个便捷的符号表示时，这个现成的、含义紧密相关的按键自然就成了首选。因此，今天我们敲下的“cd ~”，其根源竟是一次跨越数十年的硬件设计传承。文章还配上了该终端机及其键盘布局的实物照片，让这段冷知识变得直观可感。了解这个小小的起源，能让我们对命令行中看似“理所当然”的设计多一分会心一笑的理解。

IT 累计浏览 6,862

Linux探索：一次删除一百万个文件的最快方法

这篇讲的是如何在Linux系统下极高效地删除海量文件。作者从一个Quora上的讨论出发，对几种常见的批量删除方案进行了系统性的速度对比。文章的核心发现令人意外：通常用于数据同步的`rsync`命令，在删除任务中表现极其出色。作者通过两次测评（第二次使用了新硬件和更精确的计时工具）发现，使用`rsync --delete`将一个空目录与目标目录同步，可以在10秒内删除100万个文件。相比之下，传统的`find -delete`、`find | xargs rm`以及直接使用`rm -rf`，耗时都在28秒到41秒之间，性能差距明显。这种高效的背后，是`rsync`直接操作文件系统索引的高效机制，避免了为每个文件单独发起系统调用的巨大开销。文章不仅给出了具体命令（`rsync -a --delete empty/ target/`），还指出该方法的灵活性——配合`--exclude`参数可以实现选择性删除，并且在删除后保留了原目录结构，方便复用。对于运维人员或需要处理临时文件、缓存文件的开发者来说，这是一个非常实用的技巧，能显著节省处理时间。