yuanmenghao

本文分析了WSL+Docker环境下出现NVIDIA-SMI couldn't find libnvidia-ml.so错误的原因和解决方案。关键发现是当Docker镜像已包含/usr/lib/wsl/lib目录时，NVIDIA runtime会跳过GPU库挂载，导致容器无法访问GPU。解决方法是通过-v /usr/lib/wsl/lib:/usr/lib/wsl/lib手动挂载WSL GPU库，并设置LD_LIBRARY_PATH环境变量。文章详细介绍了问题排查步骤，包括检查WSL GPU状态、Docke

Linux下高效管理VS Code进程指南 本文介绍了在Linux系统中管理VS Code进程的正确方法。针对VS Code卡死或残留进程问题，对比了kill和pkill命令的区别：kill针对特定PID，而pkill可按名称批量操作。解释了pgrep -i code输出大量PID的原因——VS Code的多进程架构和模糊匹配特性。提供了精准管理方案：用pgrep -x code查主进程，pkill -f "/usr/share/code/code"彻底关闭所有进程，并建议先SIGTER

📋 本章摘要 在第十八章中,我们使用 捕捉库函数的性能热点,定位到正则表达式库（ 占用 89%）、加密函数和 JSON 解析成为新的瓶颈。通过函数级别的性能分析,将帧率从 30 FPS 提升到 980 FPS。 但当问题进入**内核路径**（调度延迟、软中断拥塞、块 IO 队列、kworker 异常

📋 本章摘要 在第十九章中,我们掌握了 ftrace 的核心用法,通过直接操作 接口完成了 kworker 高负载和软中断风暴的排查。但手工操作 ftrace 存在明显的痛点： - **操作繁琐**：需要手动 echo 到多个文件,容易出错 - **数据管理难**：trace 数据无法持久化保存和分

📋 本章摘要 在第十七章中，我们深入探讨了系统调用的性能开销——单次 100-300ns，但频繁调用会累积到整体性能的 50% 以上。通过 strace 诊断，我们发现一个感知算法每秒调用 845,000 次 gettimeofday，导致 load 8.5 但 CPU 使用率仅 15%。通过批量优

📋 本章摘要 在第十六章中，我们深入探讨了文件系统层面的性能优化，发现文件系统会引入 12% 的性能开销，元数据操作比数据写入慢 500-1000 倍，fsync 每次耗时约 5ms。通过优化自动驾驶日志系统（目录分片、批量 fsync、切换到 XFS），我们将写入次数降低 99%，延迟降低 95%

📋 本章摘要 在第十五章中，我们深入探讨了磁盘 IO 的三大性能指标（IOPS、吞吐量、延迟），发现队列深度和 IO 块大小对性能的决定性影响。通过优化传感器数据录制系统，我们将 NVMe SSD 的写入带宽从 150MB/s 提升到 520MB/s。但磁盘 IO 只是存储栈的底层，在应用程序和磁盘

🔗 从 Swap 到磁盘：存储性能的最后一环 在第十四章中，我们深入探讨了 Swap 机制——当物理内存不足时，内核将不活跃的匿名页 swap 到磁盘。我们诊断了一个自动驾驶系统的性能崩溃问题，发现每秒 2345KB 的 swap in 和 3456KB 的 swap out 导致 CPU iowa