gateworker 分布式部署延迟好几分钟

zsslover

问题描述

这里写描述
gateworker 分布式部署延迟好几分钟
register 和 gateworker mysql 一台服务器简称A ,businessworker 单独一台 简称B,目前
B onmesseage 接受到消息比客户端发送的消息晚了好几分钟
[ 2023-11-11T17:31:58+08:00 ][ log ] 请求参数:{"command":,"api_version":"","data":{"addr":"","cpuname":"","iflist":[{"ifaddr":"","ifmac":"14:3d:f2:f3:c0:7f","ifname":""}],"last_ts":1699694855,"load":0.19705462455749512,"os":"","policy_ver":0,"port":"","uuid":""},"ts":1699694855}

ts的时间戳是1699694855 2023-11-11 17:27:35 日志接受的时间是 17:31:58 差了4分钟多, 目前A服务器cpu 60% B服务器 cpu 20% 这是什么原因呢

其中A服务器启动的start_register 和 start_gateway 目前调的 start_gateway 进程是8个
B服务器启动的是 start_business 进程是128 个

A 服务的status

B服务器status

749 3 0
3个回答

meows

把你的gateway,register,businessworker 配置都发出来。

  • 暂无评论
meows

还是说很少用户发送消息到达businessworker 都会延迟几分钟? 这样的话,就检查下网络环境以及配置文件。

  • meows 2023-11-12

    也不排除你业务的问题

  • zsslover 2023-11-12

    配置文件加上了

  • zsslover 2023-11-12

    2023-11-12 13:52:08 pid:3218758 SendBufferToWorker fail. May be the send buffer are overflow. See http://doc2.workerman.net/send-buffer-overflow.html 现在A服务一直报这个

  • zsslover 2023-11-12

    A 服务器和B服务器的负载都不高,就是有延迟

  • zsslover 2023-11-12

    现在一分钟内有心跳的是5000个

  • latin 2023-11-12

    请求量太大,服务端处理不过来了,导致延迟。
    你们多少客户端在线啊,每秒心跳5000个,30秒一个心跳的话,都要15万在线了。
    感觉是客户端一直在疯狂发请求请求量太大导致

  • zsslover 2023-11-12

    B服务器的负载和cpu都不高

  • zsslover 2023-11-12

    我看了在线数是1000多个

  • zsslover 2023-11-12

    这个和延迟有关系吗

  • zsslover 2023-11-12

    我把status放上去了

  • latin 2023-11-12

    客户端1000个,心跳每秒5000个,说明客户端逻辑有问题,一直在疯狂发心跳请求,甚至业务请求也在疯狂发,业务处理不过来。你发的报错里的url地址里已经说明了原因了

  • zsslover 2023-11-12

    但是cpu和负载都不高 ,我看负载高了才应该增加business 服务器

  • zsslover 2023-11-12

    心跳不是每秒5000个 ,是看了心跳更新时间在一分钟内是5000个

  • latin 2023-11-12

    看报错里的url,原因里面作者给你总结好了

  • zsslover 2023-11-12

    但是一条一条对没有找到原因,按理说这些请求应该能处理好,mysql慢日志也没有

  • zsslover 2023-11-12

    这个和延迟有关吗,这个报错运行一段时间才会报,一开始启动的时候没有这个报错

  • latin 2023-11-12

    有关系,处理不过来,队列挤压,后面的请求等待前面的处理完才能被处理,所以延迟

  • latin 2023-11-12

    文档里说的明明白白的

  • zsslover 2023-11-12

    负载和cpu 不高 也可能出现这种处理不过来的情况吗

  • latin 2023-11-12

    业务有IO请求,比如数据库,curl这些等IO等待的时候不占用本地cpu的。比如一个SQL请求耗时0.5秒,一个进程一秒钟只能处理2个请求。128个进程每秒只能处理256个请求,如果每秒有300个请求过来,请求就处理不过来了。但是你会发现cpu负载很低,因为大部分都在等待IO返回,不耗费cpu。内存够的你可以开512个进程,增加吞吐量。但是也不一定能处理得过来。你最好记录日志,每个请求处理耗时,每秒处理多少请求。

meows

gateway 9 个进程,businesswork 128个进程。
你的描述:
CPU大量空闲,businessworker 大量空闲状态,出现部分worker 繁忙状态。
你的代码里面是不是有调用第三方API的动作?
也可能是SQL执行太慢?strace -ttp [繁忙进程的PID] > output.log,你把日志文件截图发来看看呢?

年代过于久远,无法发表回答
×
🔝