linux 进程cpu 占用过高排查

这很简单。
如果JVM进程的CPU使用率过高，则必须这样做：
1 . 首先安装工具，apt-get install pstack strace。
这两个工具可以帮助你检查调用堆栈和系统调用。
2 . 查看top，找到CPU占用率高的进程（例如PID为1 9 2 5 8 ），并记下其名称（例如python或django）。
3 .top -H -p ，查看本品下哪个线程占用CPU较多。
4 . pstack 或对于线程 pstack ，这可以显示调用堆栈并查找高频函数。
5 . strace -f -p ，检查系统调用，高频的mmap/munmap或者文件网络I/O可能是问题。
6 . 使用cProfile或py-spy检查Python代码热点，或使用gdb检查调用堆栈。
7 . perf和火焰图，这些先进的产品可以帮助你走得更深入。

记住权限，不要搞乱生产环境。
对于多线程进程，取决于线程ID。
通过这样的操作，CPU占用率高的问题应该就找到了，优化就有了方向。

linuxcpu占用率过高时问题排查

哈，你的Linux CPU故障排除手册很详细，步骤清晰，命令也清晰可见。
但说实话，我经常会遇到CPU占用率高的问题。
我可能没有那么一步一步，但是核心思想还是一样的。

就在上周，我正在处理一个上海某公司服务器CPU突然被撞的案例。
当时客户非常担心，说服务器CPU已经达到9 8 %以上，网站打不开。
我的第一反应是使用提升的命令并按 1 查看多核负载。
果然，有一个进程几乎使用了 9 5 % 的 CPU。
输入PID为1 2 3 4 ，然后ps-p1 2 3 4 -L-otid、pcpu、comm查看线程，发现有一个线程（TID为5 6 7 8 ）占用了8 0%的CPU。
这时我开始怀疑这是不是一个无限循环。

然后我使用strace-p1 2 3 4 来查看系统调用。
因为权限不够，所以给了我客户端root。
我一看，哦，这个过程居然疯狂的调用了sched_yield，而且每次的参数都是一样的。
这显然陷入了某种条件判断，典型的死循环。
然后我使用 lsof-p1 2 3 4 查看它打开了哪些文件，发现它卡在一个大日志文件中并且被重复读取。
可能是日志解析逻辑有问题。

实际上解决得很快。
因为这个进程是特定监控程序的自定义脚本，并不是关键的系统进程，所以我简单地kill-9 1 2 3 4 来强制它终止。
搞完之后CPU立马掉线了。
但要彻底解决问题，我建议客户更新监控脚本，更改死循环逻辑。
它还询问我是否可以限制该脚本的 CPU 使用率，因此我教它使用 systemd-run--cpu-quota=3 0% [xss_clean]。
这样，即使再出现问题，CPU最多也只会使用到3 0%，不会导致整个服务器崩溃。

只能说，这四个步骤其实还是蛮实用的。
尤其是高级分析，比如内核日志、线程栈分析等，有时候确实需要依靠经验，仅仅依靠命令并不能直接找到问题所在。
例如，我上次在北京调试Java应用程序时，CPU使用率很高。
我用jstack查看线程池。
哎呀，两根线互相切入对方的锁并卡住了。
这种问题只看顶层是看不出来的。
应该从线程层面来分析。

不过说实话，我之前并没有关注过美丽和美丽的优先范围。
有时它们调整不正确，这会使系统更加卡住。
所以当你谈到调整进程优先级时，我想提醒你，优先级范围是-2 0到1 9 值越低，优先级越高。
但不要随意修复它，特别是对于系统进程。
如果不小心，可能会导致系统不稳定。

总的来说，您的指南非常可靠，对初学者来说应该非常有帮助。
在实际操作中，你可能会遇到各种意想不到的情况，比如硬件问题、内核bug等。
这需要积累更多的经验。
反正，你只需要弄清楚。
只有理论与实践相结合，才能更好地解决问题。

Linux系统中CPU和Sys占用过高的调查与应对

这就是问题所在。
直接使用kill-9 终止进程可能会导致数据丢失，因此请谨慎使用。

实用笔记：优化代码前备份重要数据，升级内核前测试服务兼容性。