今天生产突然遇到一个问题. 一个内部的http 接口服务.
master 进程内存溢出, 快速增长内存 问题.
想了很多 也看了很多日志. 发现服务器 php_error.log 在提示内存溢出写入日志内存失败.
[05-Apr-2024 20:56:09 Asia/Shanghai] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20382400 bytes) in FileLog.php on line 217 |
通过调试发现和 大佬们说的一样:

主进程内存占用过高一般是有大量数据未发送保存在内存缓存区中,请开启心跳检测功能,剔除坏连接。
诶 我们这个问题还是 日志写的太大了. 导致 worker进程直接 Fatal 死掉了. Master 不主动释放, 日积月累服务器内存写满.
文章作者: Leon
版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Leon!
相关推荐
2018-12-24
[踩坑实践] Swoole dispatch_func 自定义分配worker 进程
swoole 的分配worker 进程方式有很多 轮询 争抢 空闲 等等. 因为业务的需求, 我们的服务需要根据用户uid 分配 worker 进程做到用户操作排队. dispatch_func 自定义分配worker进程方法, 真实让我又爱又恨. 好处不多说 满足业务需求, 从此实现用户操作 单进程排队的效果. 坑也不少, 第一个踩的坑 空包处理 return -1, 没想到结果非常惨 Error: Too many open files[24] 可以看下以前的文章 [Error: Too many open files[24]][1] 今天有一个坑 换了个业务 但也需要用 dispatch_func心跳包 或 keepalive 两种检测连接方法都失效了….原因还是 return 负数 我 return -100 仍然不给力 ….改成随便一个worker 就 ok 了 棒棒哒~
2024-02-23
[踩坑] Swoole . http response is unavailable (maybe it has been ended or detached)
今天查看 /var/log/php_error.log 抛错如下: [23-Feb-2024 13:17:34 Asia/Shanghai] PHP Warning: Swoole\Http\Response::header(): http response is unavailable (maybe it has been ended or detached) in ../Listen/Http.php on line 216[23-Feb-2024 13:17:34 Asia/Shanghai] PHP Warning: Swoole\Http\Response::end(): http response is unavailable (maybe it has been ended or detached) in ../Listen/Http.php on line 218 问题很明显 http response is unavailable (maybe it has been ended or detached译 : http响应不可用(可能已结束或分离) ...
2021-11-03
Swoole 使用 Xhprof 调试 HTTP服务
昨天服务出了问题,生产环境代码需要优化 一般我们会通过几种方式分析:日志法:通过各种日志,查看耗时,找出相应的问题,但这种方法有几个缺点:粒度太粗,不好控制侵入性太强,需要人工打点性能指标不够,只能分析出大致的耗时,但不能分区i/o, cpu时间乖 xdebug:目前最牛逼的性能分析工具,可以无侵入式的详细的记录完整的调用链,遗憾的是与swoole不兼容xhprof: facebook出口的一款性能分析工具,简单易用,问题是:后期不维护了,对现在的php版本以及swoole支持度都不好第三方的apm工具: 不可控,也不如前面2位,对swoole支持也不好找到一个网站:https://tideways.com/,维护并持续更新xhprof,使之能支持php7 也支持在swoole下跑 安装 tideways_xhprof# 克隆扩展$ git clone https://github.com/shenzhe/php-xhprof-extension $ cd php-xhprof-extension/ # 没发现phpize $ phpize --version ...
2020-04-03
Swoole WebSoctet 使用 zlib 压缩之 PHP 与 pako.js
一些理论知识先说一下deflate算法吧,deflate是zip压缩文件的默认算法, 其实deflate现在不光用在zip文件中, 在7z, xz等其他的压缩文件中都用, 实际上deflate只是一种压缩数据流的算法,任何需要流式压缩的地方都可以用。 也就是说 zlib 格式, gzip 格式,是文件格式,deflate 是这些文件格式使用的压缩算法。 传输方式 deflate 压缩后是二进制,通常有两种传输方式: 二进制 Base64编码 二进制PHP // 压缩,注意:其中 ZLIB_ENCODING_DEFLATE 参数是不能少的$data = gzdeflate(json_encode($array, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES), 6, ZLIB_ENCODING_DEFLATE);// 使用 swoole 以二进制的方式发送$webSocket->push($fd, $data, WEBSOCKET_OPCODE_BINARY); JavaScript // 消息事件ws.onmess...

2023-12-26
[踩坑] Swoole 抛错 记录
近期遇到三个swoole 的抛错日志, 很头疼 有的有解释 有的并没有, 但总体也算是解决了问题. [2023-11-21 19:44:02<.978122> #9118.2] WARNING del (ERRNO 800): failed to delete events[430], it has already been removed[2023-11-21 22:17:28<.225417> *19693.61] WARNING Worker_discard_data (ERRNO 1007): [2] ignore data[1272 bytes] received from session#15689[2023-11-18 09:15:07 *22844.90] WARNING send_blocking(:206): send 40 bytes failed, Error: Resource temporarily unavailable[11] 问题如上 3种抛错, 数据都是swoole抛错日志, 需要注意的是 : 在Swoole 日...
2019-08-21
Swoole 服务下发现 Core 大文件问题解析
在使用 Swoole 开发的服务中,如果发现 core dump 文件(通常名为 core 或 core.<pid>)变得异常大,可能会引发性能问题或存储空间不足。以下是关于该问题的解析及解决方案。 1. Core Dump 文件概述Core dump 文件是进程在异常终止时生成的内存快照。这种文件包含了进程的内存状态、调用栈、寄存器和其他调试信息,通常用于故障排查。 2. Core Dump 文件产生的原因2.1 代码异常 未捕获的异常:如果代码中存在未捕获的异常,可能导致进程崩溃。 错误的内存访问:访问已释放的内存或越界访问数组等,会导致进程崩溃。 2.2 资源耗尽 内存泄漏:长时间运行后,内存未释放,导致资源耗尽,最终使进程崩溃。 文件句柄或网络连接耗尽:如果打开的文件句柄或网络连接数超出系统限制,也可能导致进程崩溃。 2.3 外部因素 操作系统信号:如 SIGSEGV(段错误)、SIGABRT(强制终止)等信号会导致进程生成 core dump。 3. 解决方案3.1 代码审查 异常处理:确保代码中有适当的异常处理机制,使用 try-catch 语句...
评论
公告
记录技术实践,分享学习与思考。



