Socket导致cpu消耗10%以上

最新推荐文章于 2024-11-19 12:38:23 发布
原创 最新推荐文章于 2024-11-19 12:38:23 发布 · 2.1k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

针对一个基于JT808协议的项目，通过AndroidProfiler定位到SocketChannel的read方法导致CPU占用超过10%的问题。通过在read返回-1时增加延时，成功解决了CPU占用过高的情况。

1.接手的项目apk中基于JT808协议用Socket上传位置等消息，用命令top -m 10 -s cpu

查看cpu消耗时发现此app占用cpu超过10%

先把GPS停了，重新运行还是会很耗cpu

2.定位

用Android Profiler查了下点record

在这里插入图片描述

最终定位到
线程里SocketChannel里的read方法

 while (true) {

                try {
                    int len = 0;
                    len = channel.read(readbuffer);

                    //Log.i(TAG, "channel.read len == " + len);

                    if ( len > 0 && handler != null) {

发现是死循环里不断read

于是在read读不到也就是返回-1里，做了短暂延时，问题解决.

ldwying
关注
PHP在宝塔面板下，CPU占用过高 接近100%，吓死宝宝了
喵喵喵~~~的博客
11-09 2461
你好，打工人！ 早上上班，前端妹子说要对接客服系统，我就兴高采烈地给她讲解怎样在客户端嵌入我部署的客服系统， 经过一阵暴雨梨花的讲解，终于，在我口水即将喷完的时候讲明白了，我飘了~~~。 然后我准备再去服务器上巡视一番，当我打开宝塔面板的时候，惊呆了， 服务器 cup使用率100%，负载状态100%，瞬间从一万米高空坠下，周身气温降到零下。 看到这种情况，我只能努力的平复面临崩溃的心态，右手抚额，由上而下，滑过鼻尖的时候深吸一口气， 假装淡定的 一顿shell操作，查看源头（其实只会一
cpu core thread socket
o_alpha的博客
06-15 1122
CPU 插槽(socket)，也称为 CPU 插槽(slot)，是计算机硬件中的一个组件，在微处理器和印刷电路板 （PCB） 之间提供机械和电气连接。它允许您放置和更换中央处理器，而无需焊接。此功能可以方便地升级或更换计算机系统中的 CPU。
cpu、socket、core、thread 等术语之间的关系
布袋和尚
11-01 5047
当我们在看技术文档时，经常会发现很多有关 cpu 的术语，比如 cpu、cpu socket、cpu core、hyper-threading 等，乱乱的分不清楚，这篇文章我带大家用三分钟时间，快速的过一遍各种术语代表什么，以及它们之间的关系。上图中 thread 总数是用 cpu 来表示的，这也是为什么上文说，cpu 是个比较宽泛的概念，在不同的语境下有不同的定义，这里表示的就是逻辑核，也就是 thread。core 的中文意思是核心，它就是我们平时说的，一个 cpu 中有几核的核的概念。
socket 降低cpu 占用率 ，放弃Thread和Whell 循环
幻辰科技 nbhctec.com
11-12 429
2、 创建一个消息体（结构包）1、创建一个消息体的类型。3、创建一个处理的包。4、创建一个包的事件。
C#中Socket占用CPU高，解决方案！
zhhonglian的专栏
12-17 6902
我们在监听客户端信息时，一般会使用while(true)的方式来循环监听。 当客户端没有发送消息，这时就造成了cpu的开销浪费 为了解决这个问题，可以在循环中添加判断，判断是否有消息被送过来，如果没有则休眠一段时间。 eg:  while (true) //循环从客户端获取信息             {                //没有访问连接时，进程休眠         
解决PostgreSQL服务启动后占用100% CPU卡死的问题
09-11
1. **查询优化**：执行高计算密集型或无索引的复杂查询可能导致CPU使用率飙升。检查`pg_stat_activity`视图可以找出正在运行的长时间查询并优化它们的SQL语句。 2. **后台进程**：PostgreSQL有许多后台进程，如wal ...
CPU狂飙900%，该怎么处理？
weixin_45817985的博客
09-19 911
CPU狂飙900%，该怎么处理？
解决LoadRunner回放Socket脚本时CPU 100%，LR崩溃，报“mmdrv.exe”错误的问题
12-23
4. **脚本问题**：过于复杂的脚本，或者存在死循环，可能导致CPU占用过高。检查并优化脚本逻辑是解决问题的关键步骤之一。 5. **LR配置不当**：如并发用户数设置不合理，或者资源管理设置不恰当，都可能导致问题...
惊悚，单个java进程占用700%的CPU
ailiandeziwei的专栏
06-11 1474
CPU飙升问题定位的一般步骤是：1.首先通过top指令查看当前占用CPU较高的进程PID；2.查看当前进程消耗资源的线程PID： top -Hp PID3.通过print命令将线程PID转为16进制，根据该16进制值去打印的堆栈日志内查询，查看该线程所驻留的方法位置。4.通过jstack命令，查看栈信息，定位到线程对应的具体代码。5.分析代码解决问题。
MySQL进程CPU飙升到900%，怎么处理
lc547913923的专栏
11-19 1649
陈某提示：大家介绍场景的时候，就说自己主要涉及了两个场景， Java进程飙升900%、MySQL进程飙升900%两种场景，其实，这两个场景就足够讲半天了， 其他的，使用规避技巧规避一下就行。转换后的结果分别为7665，由于导出的线程快照中线程的nid是16进制的，而16进制以0x开头，所以对应的16进制的线程号nid为0x7665。但是，一旦高并发场景，要么走到了死循环，要么就是在做大量的 GC, 容易出现这种 CPU 飙升的情况，CPU飙升900%，是完全有可能的。目测数据量不大，也就几百万条而已。
宝塔面板下，服务器 PHP CPU占用过高
weixin_45662978的博客
12-26 1096
宝塔面板下，服务器CPU占用过高 代码 top命令之后 显示 PHP占用最高 多次解决不成功 最后解决办法及分析 宝塔安装了多个PHP版本，虽然在宝塔进行了卸载，但是后台文件依然存在，删除相关文件之后恢复正常，也有可能是PHP插件 ioncube 两个版本 争夺解释权的问题，都进行了删除，CPU恢复正常 ...
socket select 超时问题 导致CPU高
伍意的博客
05-24 3943
以下代码问题在哪里，会不会select每次1秒超时呢？ void IPCServer::DoWork() { fd_set read_set; struct timeval tv_select; tv_select.tv_sec = 1; tv_select.tv_usec = 0; int max_fd = m_nListenSocket; int r = 0; struct
[实战] PHP WorkerMan CPU过高导致的业务延时 排查与优化
weixin_34409741的博客
07-18 1681
WorkerMan介绍 官方项目地址：https://www.workerman.net/features workerman是一个高性能的PHP socket 服务器框架，workerman基于PHP多进程以及libevent事件轮询库， PHP开发者只要实现一两个接口，便可以开发出自己的网络应用，例如Rpc服务、聊天室服务器、手机游戏服务器等。 workerman的目标是让PHP开发者更容...
Socket 服务器内存占用偏高,服务器内存使用飙升的排查
weixin_28725553的博客
07-30 2489
这几天自己线上的乞丐服务器遇到一个问题，io会瞬间飙升到很高很高，造成内存使用飙升。但是实际上并发量并不大(网络连接数)。知道是哪个进程造成的，但是确实排查代码中没有是么地方会有这么大的读写。实在想不通。部署的是一个socket服务。用测试脚本跑，同时100个socket连接毫无压力。也不知道对方到底发的什么数据导致这么大的内存占用。之前也处理过类似的问题。麻烦之处在于很好的定位问题，重现实际的操...
PHP占用CPU过高几种思路
weixin_30785593的博客
10-28 1003
PHP占用CPU过高几种思路 今天在做测试的时候突然间很卡，用top观察了下 php占用CPU达到了70%多，具体操作以下几步： 1.strace -o output.txt -T -tt -e -c trace=all -p pid 结果： 查了下。。一直在执行read,write操作sql语句 2.ll /proc/25...
解决 socket.io 频繁连接导致 cpu 升高问题
AnitaSun的博客
05-17 2701
前提 如果前端频繁刷新页面或者频繁断开重连将会导致服务端 cpu 升高 解决方法 使用 localStorage 缓存连接，每次通信都使用这个连接 代码 let socket; if(localStorage.getItem('socket')) { socket = JSON.parse(localStorage.getItem('socket')); // 创建一个不自动连接的 socket 对象 let temp = io({autoConnect: false});
关于socket长连接 CPU占用较高解决办法
热门推荐
银色木马的博客
07-11 1万+
在接受和发送的white循环里面停顿10毫秒。Thread.sleep(10);
为什么网络socket编程是阻塞的？因为非阻塞轮询占CPU，用多线程和IO复用
modi000的博客
06-06 1832
2020.8.27一直不明白为什么网络socket编程默认都是阻塞的，阻塞了程序不就停了不响应了吗，好纠结。现在有点了解了，阻塞时是等待状态，类似于内核把它sleep，不占用CPU，对操作系统正常运转是非常有利的。非阻塞方式：程序不会停止响应，socket函数会马上返回，但程序需要一直轮询socket，如果socket没有动作，那其实就是在while(1)啊，CPU占用是100％啊。不行啊，操作系统要完蛋的。所以还是用阻塞方式吧，内核已经把最优方案给我们了。但是，一个socket这么用是没问题的，多个soc
cpu,socket,core,thread
IForFree
03-09 525
相关概念介绍：cpu/socket/core/thread
mysqld_safe的cpu100%问题
最新发布
04-23
<think>好的，我现在需要解决用户关于“mysqld_safe进程CPU占用100%”的问题。首先，我应该回忆一下mysqld_safe的作用。mysqld_safe是一个守护进程，用来启动、监控和重启MySQL服务器进程mysqld的。如果mysqld崩溃或者被终止，mysqld_safe会尝试重新启动它。所以，当mysqld_safe占用高CPU时，可能是它频繁尝试重启mysqld导致的。 接下来，我需要考虑可能的原因。根据引用[1]，用户提供的日志显示mysqld进程结束，这可能意味着mysqld异常终止，导致mysqld_safe不断尝试重启，从而占用高CPU。此外，引用[2]提到在没有大量业务的情况下，可能排除业务量过高的因素，转而考虑其他问题，比如配置错误或资源不足。 可能的排查步骤包括： 1. 检查错误日志：查看MySQL的错误日志，确定mysqld崩溃的原因。引用[1]中的日志提到pid文件结束，可能意味着mysqld异常退出。 2. 检查资源使用情况：比如内存、磁盘空间等，资源不足可能导致mysqld崩溃，进而触发mysqld_safe频繁重启。 3. 配置文件问题：引用[3]提到多实例配置可能涉及多个配置文件，检查是否有配置冲突或错误参数，比如socket路径、端口设置等。 4. InnoDB配置：引用[4]提到InnoDB的日志刷新设置可能影响性能，不当配置可能导致崩溃。例如，innodb_flush_log_at_trx_commit设置不当可能引起I/O压力，进而导致问题。 5. 临时表大小：引用[5]中的tmp_table_size设置过小可能导致磁盘临时表使用过多，影响性能，但这里可能更多关联到mysqld本身的性能，而不是mysqld_safe的问题。 另外，用户提到mysqld_safe占用CPU高，而mysqld可能已经崩溃，所以需要确认当前是否有多个mysqld进程在运行，或者mysqld_safe不断重启失败，导致循环消耗资源。例如，如果mysqld启动失败，mysqld_safe可能会反复尝试启动，每次启动失败都会记录日志，并可能占用CPU。 解决方案可能包括： - 修复mysqld崩溃的根本原因：如调整配置参数，增加内存，修复损坏的表等。 - 检查是否有僵尸进程或残留的pid文件，导致mysqld_safe无法正确启动mysqld。 - 更新MySQL版本到修复了相关问题的版本。 - 在极端情况下，如果mysqld_safe本身有问题，可能需要重启服务器或重新安装MySQL。 需要确保用户检查了错误日志，这是解决问题的关键步骤。同时，提醒用户备份数据，避免操作导致数据丢失。</think>### mysqld_safe进程CPU占用100%解决方案 #### 一、问题定位步骤 1. **确认进程关联性** 使用`top -c`查看具体进程信息，确认占用CPU的是`mysqld_safe`而非`mysqld`。若`mysqld_safe`持续占用资源，通常是由于其频繁尝试重启`mysqld`导致的循环异常[^1]。 2. **检查MySQL错误日志** 查看`/var/log/mysql/error.log`或`/data/mysql/data1/主机名.err`（路径参考配置文件），分析`mysqld`崩溃原因。常见崩溃原因包括： - 内存不足（OOM） - 表损坏或磁盘空间不足 - InnoDB配置参数不合理（如`innodb_buffer_pool_size`过大）[^4] 3. **排查PID文件冲突** 检查`/data/mysql/data1/*.pid`文件是否残留。若存在多个实例共用同一`pid`文件，会导致`mysqld_safe`误判进程状态并频繁重启[^3]。 #### 二、解决方案 1. **修复mysqld崩溃根源** - **调整内存参数**： 修改`my.cnf`，降低`innodb_buffer_pool_size`（建议为物理内存的50-70%）并增加`tmp_table_size`（参考值128M）[^5]。 ```ini innodb_buffer_pool_size = 4G tmp_table_size = 128M ``` - **修复表损坏**： 使用`myisamchk`或`innodb_force_recovery`模式启动后执行表修复。 2. **清理残留文件** ```bash rm -f /data/mysql/data1/*.pid # 删除残留pid文件 ``` 3. **优化mysqld_safe行为** 修改`/etc/my.cnf`中的`[mysqld_safe]`配置，限制重启频率： ```ini [mysqld_safe] restart-interval=60 # 每次重启间隔60秒 ``` 4. **升级MySQL版本** 若问题由已知Bug导致（如特定版本的崩溃问题），建议升级至稳定版本。 #### 三、验证与监控 1. **重启MySQL服务** ```bash systemctl restart mysql # 或使用mysqld_multi重启多实例[^3] ``` 2. **持续观察资源占用** 使用`htop`或`pidstat -u -p <PID> 1`监控进程状态，确认CPU占用恢复正常。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值