socketio测试.zip 测试包 3个客户端， 里面的控制器是实现代码， 客户端连接时我把当前socket的sid存入redis， 然后to（$sid）->emit 的形式实现单聊， 没升级版本前是可以的当时版本2.0+， 后来 composer update 又升级几次，代码没动过就不能实现 私聊和群聊了

按照文档按照组件，配置好了

调用如下

/**
 * @CircuitBreaker(timeout=0.05, failCounter=1, successCounter=1, fallback="App\Model\UserTokenModel::searchFallback")
 */
public  static function  GetPublicToken()
{
    $Authorization = ApplicationContext::getContainer()->get(AuthorizationInterface::class);
    $publicToken=$Authorization->GetPublicToken();//微服务上的一个方法 sleep(30)了
    return $publicToken;
}

public static function searchFallback()
{
    return "超时啦";
}

  异常有抛出    
  "Request timed out, errCode=110[217] in /www/wwwroot/8181.com/hyperf-skeleton/vendor/hyperf/guzzle/src/CoroutineHandler.php

不知道是否还需要配置什么

• Hyperf Version: 1.1.3
• PHP Version: (php -v) 7.3.10
• Swoole Version: (php --ri swoole) 4.4.8

Description:

有一个Consumer进程cpu 100%，server日志中出现过一次AMQP异常，应该是它引起的；从strace信息中看它在无间隙的执行epoll_***，输出信息刷屏非常快。

其它机器都是正常的，只有这一台机器的一个进程挂了。

以下是各种信息截图：

现在使用的hyperf 1.1.22版本在执行composer update后会出现所有业务都不能正常运行的问题。。 没有错误日志，接口都处于pending状态.. 没有什么debug的头绪，能提示一下吗

"name": "hyperf/framework", "version": "v1.1.22", 当前版本 "version": "v1.1.27", 更新后的版本

代码如下：

\Swoole\Runtime::enableCoroutine(); $parallel = new Parallel(257);

    foreach($rows as $rowsdata) {
       $parallel->add(function ()use($rowsdata) {
        $write=array(
            "tables"=>array(
                array(
                    "table_name"=>self::Thetrends_Accept,
                    "rows"=>$rowsdata
                )
            ),
        );
       // $this->otsClient->batchWriteRow($write);//批量写入200
         return;
        });
    }
    $results = $parallel->wait();

说明 $row count为257key 请求的是啊里云的表格存储

使用协程，再不请求第三方接口的前提下，运行大概0.2秒完成

使用协程，请求第三方接口的前提下（即代码注释的那段） ，运行去到了十几秒

如果单次请求第三方接口的话，时间是0.几秒的，加上协程就很慢了

如何可以优化快速完成所有请求呢？

Execute the command and paste the result below.

Command: uname -a && php -v && composer info | grep hyperf && php --ri swoole

/www # php -v
PHP 8.1.8 (cli) (built: Jul  7 2022 22:52:25) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.8, Copyright (c) Zend Technologies
    with Zend OPcache v8.1.8, Copyright (c), by Zend Technologies
/www # php --ri swoole

swoole

Swoole => enabled
Author => Swoole Team <[email protected]>
Version => 4.8.11
Built => Jul 11 2022 10:02:38
coroutine => enabled with boost asm context
epoll => enabled
eventfd => enabled
signalfd => enabled
spinlock => enabled
rwlock => enabled
openssl => OpenSSL 1.1.1q  5 Jul 2022
dtls => enabled
http2 => enabled
json => enabled
curl-native => enabled
pcre => enabled
zlib => 1.2.12
brotli => E16777225/D16777225
mutex_timedlock => enabled
pthread_barrier => enabled
async_redis => enabled

Directive => Local Value => Master Value
swoole.enable_coroutine => On => On
swoole.enable_library => On => On
swoole.enable_preemptive_scheduler => Off => Off
swoole.display_errors => On => On
swoole.use_shortname => On => On
swoole.unixsock_buffer_size => 8388608 => 8388608

Description:

上周二，把公司某些访问量极大的核心项目由 hyperf2.2 + php74 升级到了 hyperf3.0 + php81，升级过程一切顺利。

但是，上线后，却发现容器每天都会报警，报内存不足，心想，线上容器的 limit 全部设置了 2G，而且我个人对自己写的代码还是有信心的，想着不大可能内存泄漏啊，也没当回事儿，前一两次报警就直接重启无脑解决了

然而，在接下来的几天内，每天几乎至少一次的报警，想着可能不能再无视下去了，开始重视了起来。最近没有过大迭代，唯一一次变更就是把 hyperf 及 php 升级到了最新版，想着不大可能是这些原因造成的吧？所以，我首先开始检查审视业务逻辑代码，经过2天多的检查，依然没有发现有明显的内存泄漏情况

所以，我把目标转到了 hyperf + swoole + php81 上，索性，一鼓作气，从 php81 降级到 php74，hyperf 也降级到 2.2，在本地压测后惊奇的发现，内存稳定了？？

然后就有了下面的测试重现

Steps To Reproduce:

第零步：前提说明

php80 环境： php8.0.11 + swoole4.8.11 + hyperf3.0.0-beta10 + hyperf-skeleton 环境 php81 环境： php8.1.8 + swoole4.8.11 + hyperf3.0.0-beta10 + hyperf-skeleton 环境

修改点：

• config.php 中 SCAN_CACHEABLE 默认为 true
• server.php 中 mode 改为 SWOOLE_BASE
• server.php 中 Constant::OPTION_WORKER_NUM 改为 1 （方便查看内存情况）
• server.php 中 注释掉 Constant::OPTION_MAX_REQUEST => 100000 这一行（方便查看内存情况）

其它全部为 hyperf-skeleton 默认代码，无修改

第一步：思考可能的情况

最开始也毫无头绪，不知道从哪里查，在分析线上报警的容器之后，我想，会不会是数据库问题？于是，首先拿了线上其中一个比较简单的接口尝试了一下，复现了。

第二步：根据思考进行压测验证

代码

public function index()
    {
        \var_dump(\memory_get_usage(true));

        $user = $this->request->input('user', 'Hyperf');
        $method = $this->request->getMethod();

        $calls[] = function () use ($user) {
            return User::query()->where('username', $user)->first();           
        };
        $calls[] = function () use ($user) {
            return User::query()->where('username', $user)->first();           
        };
        $calls[] = function () use ($user) {
            return User::query()->where('username', $user)->first();           
        };
        $calls[] = function () use ($user) {
            return User::query()->where('username', $user)->first();           
        };

        $results = \do_parallel($calls);

        return [
            'method' => $method,
            'message' => "Hello.",
            'data' => $results
        ];
    }

use Hyperf\Utils\Exception\ParallelExecutionException;

if (!function_exists('do_parallel')) {
    function do_parallel(array $calls, int $concurrent = 30): array
    {
        try {
            $results = parallel($calls, $concurrent);
        } catch (ParallelExecutionException $e) {
            $throwable = $e->getThrowables();
            $results = $e->getResults();

            foreach ($throwable as $key => $throw) {
                echo '出现并发执行错误: '.$throw->getMessage();
            }
        }

        return $results ?? [];
    }
}

压测命令

同时两个 terminal 执行

ab -k -c 20 -n 10000 "http://127.0.0.1:8080/index/index" （如果想让现象来的快些，可以加大并发，加大并发会使内存比下面测试数据增大，但最终结论与现象一致）

压测现象

• php81 环境下: 内存不稳定，持续增大 (压测结束在 60M，并持续增大中，docker stats 同现象)
• php80 环境下: 内存稳定(压测结束在 33M，并在压测50%左右时已经保持稳定，docker stats 同现象)

压测过程中会出现连接池耗尽的现象，先暂时不管，后面再讨论

思考

这里其实已经能复现出内存溢出的现象了

但是这里应发了我两个思考：

• php80 环境下是否会有同样的现象

  经过实际验证，php80 环境下不会出现内存溢出现象

• 是数据库还是其他方面造成的内存泄漏？

  这里只能确定可能是数据库查询引起的，但是并不能确定，因为是通过 parallel 执行的，如果不通过它执行，会出现什么现象呢？ 于是，应发第三步

第三步：顺序执行数据库查询

代码

public function index2()
    {
        \var_dump(\memory_get_usage(true));

        $user = $this->request->input('user', 'Hyperf');
        $method = $this->request->getMethod();

        $results[] = User::query()->where('username', $user)->first();           
        $results[] = User::query()->where('username', $user)->first();           
        $results[] = User::query()->where('username', $user)->first();           
        $results[] = User::query()->where('username', $user)->first();           

        return [
            'method' => $method,
            'message' => "Hello2",
            'data' => $results
        ];
    }

压测命令

同时两个 terminal 执行

ab -k -c 20 -n 10000 "http://127.0.0.1:8080/index/index2"（如果想让现象来的快些，可以加大并发，加大并发会使内存比下面测试数据增大，但最终结论与现象一致）

压测现象

• php81 环境下: 内存稳定(压测结束在 18M，并在压测50%左右时已经保持稳定，docker stats 同现象)
• php80 环境下: 内存稳定(压测结束在 18M，并在压测50%左右时已经保持稳定，docker stats 同现象)

压测过程中会出现连接池耗尽的现象，先暂时不管，后面再讨论

思考

这里我又发现，这样的写法，内存又稳定了？？那这下能锁定原因了：并不是数据库查询引发的问题，可能是 parallel 或及其实现造成的问题，这样，又引发一个问题，到底是 swoole 底层的原因，还是 hyperf 应用代码层面的原因呢？如果我不用 parallel 这个函数，而是用 swoole 自带的呢？于是第四步就来了

第四步：swoole 原生 WaitGroup 代码实现数据库并发

代码

public function index3()
    {
        \var_dump(\memory_get_usage(true));
        $user = $this->request->input('user', 'Hyperf');
        $method = $this->request->getMethod();

        $calls[] = function () use ($user) {
            return User::query()->where('username', $user)->first();           
        };
        $calls[] = function () use ($user) {
            return User::query()->where('username', $user)->first();           
        };
        $calls[] = function () use ($user) {
            return User::query()->where('username', $user)->first();           
        };
        $calls[] = function () use ($user) {
            return User::query()->where('username', $user)->first();           
        };

        $results = \do_parallel3($calls);

        return [
            'method' => $method,
            'message' => "Hello3",
            'data' => $results
        ];
    }

use Swoole\Coroutine;
use Swoole\Coroutine\WaitGroup;

if (!function_exists('do_parallel3')) {
    function do_parallel3(array $calls, int $concurrent = 30): array
    {
        $wg = new WaitGroup();
        $results = [];

        $wg->add(count($calls));
        
        foreach ($calls as $call) {
            Coroutine::create(function () use ($wg, $call, &$results) {
                try {
                    $results[] = call($call); 
                } catch (\Throwable $e) {
                    echo '出现并发执行错误: '.$e->getMessage();
                } finally {
                    $wg->done();
                }
            });
        }

        $wg->wait();

        return $results ?? [];
    }
}

压测命令

同时两个 terminal 执行

ab -k -c 20 -n 10000 "http://127.0.0.1:8080/index/index3"（如果想让现象来的快些，可以加大并发，加大并发会使内存比下面测试数据增大，但最终结论与现象一致）

压测现象

• php81 环境下: 内存稳定(压测结束在 20M，并在压测50%左右时已经保持稳定，docker stats 同现象)
• php80 环境下: 内存稳定(压测结束在 20M，并在压测50%左右时已经保持稳定，docker stats 同现象)

思考

这里基本上能确定是 hyperf 的 parallel 或及其实现造成的问题。

但，parallel 只是一个 function 而已，没啥逻辑，其实现也是用 swoole 的 channel 实现的，理论上来说不应该啊，继续思考

第五步：会不会和数据库连接池耗尽有关？

刚刚我们提到在压测过程中会出现连接池耗尽的情况，这个现象本来是正常的，毕竟默认 max-connection 设置的是 10 比较低

但是，在压测的过程中，我们发现在 php81 的环境下，在大量出现 Connection pool exhausted. Cannot establish new connection before wait_timeout 的提示之后的十几秒内，内存就会增大一部分，因此又有一个猜想，我把 max-connection 设置为100 看看

这下，有意思的现象来了

压测命令

同时两个 terminal 执行

ab -k -c 50 -n 10000 "http://127.0.0.1:8080/index/index"

压测现象

• php81 环境下: 内存稳定(压测结束在 35M，并在压测50%左右时已经保持稳定，docker stats 同现象)
• php80 环境下：未测试

思考

我感觉最终的可能会和数据库的连接池耗尽有关，继续验证，把 并发调大进行验证

第六步：php81 下加大并发，连接池保持不变验证

压测命令

同时两个 terminal 执行

ab -k -c 100 -n 10000 "http://127.0.0.1:8080/index/index"

压测现象

• php81 环境下: 内存稳定(压测结束在 73M，并且内存不稳定，持续增大中，docker stats 同现象)
• php80 环境下：未测试

思考

不会吧，最后的结论还是和数据库有关？只不过这次的结论是 数据库连接池 的问题，第七步继续验证是否是 swoole 的问题

第七步：php81 下加大并发，连接池保持不变，使用 swoole 原生 WaitGroup 验证

压测命令

同时两个 terminal 执行

ab -k -c 100 -n 10000 "http://127.0.0.1:8080/index/index3"

压测现象

• php81 环境下: 内存稳定(压测结束在 48M，内存在压测不到 50% 时就已稳定，docker stats 同现象)
• php80 环境下：未测试

思考

到这里，总算有一个明确的结论了，在 paralle 的过程中，可能对 数据库连接池耗尽的情况 在 php81 的环境下没有处理好造成的内存泄漏

但是，截止的这里，仍然没有办法解释通为什么线上容器会有内存泄漏的情况，因为线上的连接池是没有 耗尽 的情况的

总结

• 在 paralle 的过程中，可能对数据库连接池耗尽的情况 在 php81 的环境下没有处理好造成的内存泄漏

遗留疑问

线上的连接池是没有 耗尽 的情况的，也出现了内存泄漏的情况

时间关系，没有再继续往下思考验证了，等晚些时候闲下来了，再思考更新吧，目前已经有结论了

Before you submit this issue, you has been search all existed issues and search the documentation

• [] I've been search all existed issues
• [] I've been read all documentation

Describe your question

我们使用hyperf的版本是2.0.x,composer update最新的版本。 我们现在线上使用了阿里的rabbitmq，但是发现每天都会有如下的报错，运行久了偶尔会导致内存猛涨，然后就mq就不消费了，不知道你们有遇到过这个问题吗？：

2020-09-05T06:20:15.599607404Z [INFO] Process[Consumer-callback.29] start.
2020-09-05T06:20:15.640280319Z [ERROR] PhpAmqpLib\Exception\AMQPProtocolChannelException:QueueConsumerNumExceeded[ConsumerNum=66, ConsumerNumLimit=64], ReqId:5F532DF6383136146F8E8EBA(530) in /app/www/GloBalWechatCallback/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Channel/AMQPChannel.php:215
2020-09-05T06:20:15.640326303Z Stack trace:
2020-09-05T06:20:15.640334986Z #0 [internal function]: PhpAmqpLib\Channel\AMQPChannel->channel_close(Object(PhpAmqpLib\Wire\AMQPReader))
2020-09-05T06:20:15.640340731Z #1 /app/www/GloBalWechatCallback/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Channel/AbstractChannel.php(216): call_user_func(Array, Object(PhpAmqpLib\Wire\AMQPReader))
2020-09-05T06:20:15.640346236Z #2 /app/www/GloBalWechatCallback/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Channel/AbstractChannel.php(373): PhpAmqpLib\Channel\AbstractChannel->dispatch('20,40', '\x02\x12]QueueConsume...', NULL)
2020-09-05T06:20:15.640352170Z #3 /app/www/GloBalWechatCallback/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Channel/AMQPChannel.php(995): PhpAmqpLib\Channel\AbstractChannel->wait(Array, false, 0)
2020-09-05T06:20:15.640357587Z #4 /app/www/GloBalWechatCallback/vendor/hyperf/amqp/src/Consumer.php(91): PhpAmqpLib\Channel\AMQPChannel->basic_consume('callback', 'callback', false, false, false, false, Object(Closure))
2020-09-05T06:20:15.640398642Z #5 /app/www/GloBalWechatCallback/vendor/hyperf/amqp/src/ConsumerManager.php(82): Hyperf\Amqp\Consumer->consume(Object(App\Consumers\CallbackConsumer))
2020-09-05T06:20:15.640405812Z #6 /app/www/GloBalWechatCallback/vendor/hyperf/process/src/AbstractProcess.php(113): class@anonymous->handle()
2020-09-05T06:20:15.640411087Z #7 {main}
2020-09-05T06:20:16.003637625Z [INFO] Process[Consumer-callback.26] start.
2020-09-05T06:20:16.068247748Z [ERROR] PhpAmqpLib\Exception\AMQPProtocolChannelException:QueueConsumerNumExceeded[ConsumerNum=66, ConsumerNumLimit=64], ReqId:5F532E20343445DA05910594(530) in /app/www/GloBalWechatCallback/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Channel/AMQPChannel.php:215
2020-09-05T06:20:16.068296455Z Stack trace:
2020-09-05T06:20:16.068302603Z #0 [internal function]: PhpAmqpLib\Channel\AMQPChannel->channel_close(Object(PhpAmqpLib\Wire\AMQPReader))
2020-09-05T06:20:16.068307824Z #1 /app/www/GloBalWechatCallback/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Channel/AbstractChannel.php(216): call_user_func(Array, Object(PhpAmqpLib\Wire\AMQPReader))
2020-09-05T06:20:16.068312863Z #2 /app/www/GloBalWechatCallback/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Channel/AbstractChannel.php(373): PhpAmqpLib\Channel\AbstractChannel->dispatch('20,40', '\x02\x12]QueueConsume...', NULL)
2020-09-05T06:20:16.068318040Z #3 /app/www/GloBalWechatCallback/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Channel/AMQPChannel.php(995): PhpAmqpLib\Channel\AbstractChannel->wait(Array, false, 0)
2020-09-05T06:20:16.068323217Z #4 /app/www/GloBalWechatCallback/vendor/hyperf/amqp/src/Consumer.php(91): PhpAmqpLib\Channel\AMQPChannel->basic_consume('callback', 'callback', false, false, false, false, Object(Closure))
2020-09-05T06:20:16.068328218Z #5 /app/www/GloBalWechatCallback/vendor/hyperf/amqp/src/ConsumerManager.php(82): Hyperf\Amqp\Consumer->consume(Object(App\Consumers\CallbackConsumer))
2020-09-05T06:20:16.068333180Z #6 /app/www/GloBalWechatCallback/vendor/hyperf/process/src/AbstractProcess.php(113): class@anonymous->handle()
2020-09-05T06:20:16.068337895Z #7 {main}

https://laravel.com/docs/7.x/eloquent-mutators#custom-casts https://learnku.com/docs/laravel/7.x/eloquent-mutators/7502

• [x] Added Castable, CastsAttributes and CastsInboundAttributes
• [x] Added Model\Builder::withCasts
• [x] Added Model::loadMorph, Model::loadMorphCount and Model::syncAttributes,

Before you submit this issue, you has been search all existed issues and search the documentation

• [x] I've been search all existed issues
• [x] I've been read all documentation

Describe your question

不知道是否和 #1421 有关？

proto 文件

syntax = "proto3";

package cti;

message AgentCmdRequest {
    string jsonRequest = 1;
}

message AgentCmdReply {
    string jsonReply = 1;
}

service Cti {
    rpc AgentCmd ( AgentCmdRequest) returns ( AgentCmdReply) {}
}

mac 下使用 protoc 生成代码后

/**
     * @RequestMapping(path="fuck", methods={"POST"})
     */
    public function call(): array
    {
        (new CtiGrpc('172.25.1.124:5027', ['credentials' => null]))->fuck('{"action":15,"fuck":"6690170531783684096"}');

        return $this->success();
    }

client 客户端

<?php

declare(strict_types=1);

namespace App\Util\Grpc;

use App\Util\Logger;
use Cti\AgentCmdReply;
use Cti\AgentCmdRequest;

class CtiGrpc extends AbstractClient
{
    public function fuck(string $data)
    {
        $arg = (new AgentCmdRequest())->setJsonRequest($data);

        $response = $this->_simpleRequest('/cti.Cti/AgentCmd', $arg, [AgentCmdReply::class, 'decode']);

        Logger::info('response', $response);

        return $response;
    }
}

最后，请求 fuck，没有一次成功的，每次都是报

[2020-07-25 20:35:53 *17013.1]	NOTICE	http2 stream#1 belongs to an unknown type or it never registered
[2020-07-25T20:35:56.557711+08:00] app.INFO: response {"0":"No response","1":-1,"2":false}

目前，看了相关源码，暂未找到问题，没有头绪，所以请教下

感谢

ps：服务端是 c 写的，附 nodejs 客户端源码

var grpc = require('@grpc/grpc-js');
var protoLoader = require('@grpc/proto-loader');
var PROTO_PATH = 'cti.proto';

var arguments = process.argv.splice(2);

var srv_addr="127.0.0.1:5027";
var message;
if(arguments.length < 1){
    console.log("parms too low!");
    help();
    process.exit(0);
}else if(arguments.length == 1){
    message = arguments[0];
}else{
    srv_addr = arguments[0];
    message = arguments[1];
}
var packageDefinition = protoLoader.loadSync(
    PROTO_PATH, {
        keepCase: true,
        longs: String,
        enums: String,
        defaults: true,
        oneofs: true
    });

var cti_proto = grpc.loadPackageDefinition(packageDefinition).cti;


// 指定地址和端口号
var client = new cti_proto.Cti(srv_addr, grpc.credentials.createInsecure());

console.log("grpc host["+srv_addr+"] message["+message+"] start...");

client.AgentCmd({
    jsonRequest: message
}, function(err, response) {
    if (err !== null) {
        console.log("grpc error:"+err);
        process.exit(0);
    }
    console.log('Greeting:', response);
    process.exit(0);
});

执行 node g-client.js '{"action":15,"fuck":"6690170531783684096"}' 后，是可以正常返回的

项目使用了“Guzzle HTTP 协程客户端”，上线以来一直会有"Connection failed, errCode=110"错误，之前没怎么在意，进入3月份以来，由于请求量大了，这个错误明显增多，请接口方及阿里云协助排查问题后，给出了以下结论：

1，通过招行给的抓包文件可以看出，招行发出了fin ack后，应用并没有及时返回fin ack（只回了对finack的ack）
2，阿里云nat网关收到招行的finack后，会进入一个类似timewait的状态，这个状态只能维持5秒，如果超过5秒的话，nat网关会把对应的session关闭（这个时候源端口就释放出来了）
3，应用一直没有回复finack，等到应用确认数据处理完毕后，发送finack，但是由于nat网关已经将老的session关闭了，因此发布出来（ecs有大量fin重传）
4，这个时候有新的请求发出，nat网关分配端口的时候有可能会分配第二条回收的源端口
5，招行收到这个源端口，发现自己这个会话还在等client的fin ack，于是对syn不响应
6，过了很长时间（招行自己的超时时间），招行没有等待应用的finack，于是对老的会话RST掉

这个结论不一定正确。

我查看Hyperf\Guzzle\CoroutineHandler中的代码，发现execute后，并没有调用$client->close()方法。我对网络并不怎么了解，这个$client如果不主动关闭的话，会不会导致nat网关主动回收这个连接所占用的端口给下一个连接使用，进而导致api提供方无法正确响应这个端口的请求。

错误信息

[ERROR] PhpAmqpLib\Exception\AMQPRuntimeException: Error sending data in /www/hy/code/vendor/hyperf/amqp/src/Connection/SwooleIO.php:198
Stack trace:
#0 /www/hy/code/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Connection/AbstractConnection.php(388): Hyperf\Amqp\Connection\SwooleIO->write()
hyperf/hyperf-skeleton#1 /www/hy/code/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Connection/AbstractConnection.php(516): PhpAmqpLib\Connection\AbstractConnection->write()
hyperf/hyperf-skeleton#2 /www/hy/code/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Channel/AbstractChannel.php(247): PhpAmqpLib\Connection\AbstractConnection->send_channel_method_frame()
hyperf/hyperf-skeleton#3 /www/hy/code/vendor/php-amqplib/php-amqplib/PhpAmqpLib/Connection/AbstractConnection.php(724): PhpAmqpLib\Channel\AbstractChannel->send_method_frame()
hyperf/hyperf-skeleton#4 /www/hy/code/vendor/hyperf/amqp/src/Connection.php(144): PhpAmqpLib\Connection\AbstractConnection->close()
hyperf/hyperf-skeleton#5 /www/hy/code/vendor/hyperf/pool/src/Pool.php(87): Hyperf\Amqp\Connection->close()
hyperf/hyperf-skeleton#6 /www/hy/code/vendor/hyperf/pool/src/Pool.php(68): Hyperf\Pool\Pool->flush()
hyperf/hyperf-skeleton#7 /www/hy/code/vendor/hyperf/amqp/src/Producer.php(36): Hyperf\Pool\Pool->get()
hyperf/hyperf-skeleton#8 /www/hy/code/vendor/hyperf/amqp/src/Producer.php(23): Hyperf\Amqp\Producer->produceMessage()
hyperf/hyperf-skeleton#9 /www/hy/code/vendor/hyperf/utils/src/Functions.php(79): Hyperf\Amqp\Producer->Hyperf\Amqp\{closure}()
hyperf/hyperf-skeleton#10 /www/hy/code/vendor/hyperf/amqp/src/Producer.php(24): retry()
hyperf/hyperf-skeleton#11 /www/hy/code/app/Crontab/AdminSync.php(50): Hyperf\Amqp\Producer->produce()
hyperf/hyperf-skeleton#12 /www/hy/code/vendor/hyperf/utils/src/Functions.php(270): App\Crontab\AdminSync->App\Crontab\{closure}()
hyperf/hyperf-skeleton#13 /www/hy/code/vendor/hyperf/utils/src/Coroutine.php(71): call()
hyperf/hyperf-skeleton#14 {main}

代码

定时器注解 @Crontab(name="AdminSync", rule="*/5 * * * * *", callback="execute", memo="拉取sdk管理员数据，同步数据")

定时器执行的内容

public function execute()
{
    $data         = [
        'method' => time(),
        'time'   => date('Y-m-d H:i:s')
    ];
    $amqpProducer = $this->container->get(Producer::class);
    for ($i = 1; $i <= 10; $i++) {
        $data['key'] = $i;
        go(function () use ($data, $amqpProducer) {
            $message = new AdminProducer($data);

            $amqpProducer->produce($message);
        });
    }
}

对接物联网设备，设备接口提供的操作方法为向服务器发起POST请求，而请求地址固定为【模块名/get】，这样设备发起请求就导致worker退出

代码如下：

#[PostMapping("get")]
public function get(GetRequest $request): string
{
    return "123";
}

用postman发起请求，返回 WARNING Server::check_worker_exit_status(): worker(pid=941, id=1) abnormal exit, status=0, signal=11 A bug occurred in Swoole-v4.8.8, please report it. The Swoole developers probably don't know about it, and unless you report it, chances are it won't be fixed. You can read How to report a bug doc before submitting any bug reports:

https://github.com/swoole/swoole-src/blob/master/.github/ISSUE.md Please do not send bug reports in the mailing list or personal letters. The issue page is also suitable to submit feature requests.

OS: Linux 5.10.124-linuxkit #1 SMP Thu Jun 30 08:19:10 UTC 2022 x86_64 GCC_VERSION: 10.3.1 20211027 OPENSSL_VERSION: OpenSSL 1.1.1n 15 Mar 2022 PHP_VERSION : 8.0.16

改为 #[PostMapping("getRec")] public function get(GetRequest $request): string { return "123"; }

正常返回，问题在于，物联网设备是硬件，无法更修改访问方式及接口地址……

[ERROR] Implicit conversion from float 337.5 to int loses precision[97] in /www/im/vendor/malkusch/lock/classes/util/Loop.php [ERROR] #0 [internal function]: Hyperf\ExceptionHandler\Listener\ErrorExceptionHandler::Hyperf\ExceptionHandler\Listener{closure}() #1 /www/im/vendor/malkusch/lock/classes/util/Loop.php(97): random_int() #8 /www/im/vendor/hyperf/di/src/Aop/ProxyTrait.php(87): Hyperf\Utils\Pipeline->then() #9 /www/im/vendor/hyperf/di/src/Aop/ProxyTrait.php(30): App\Controller\IndexController::handleAround() #10 /www/im/runtime/container/proxy/App_Controller_IndexController.proxy.php(36): App\Controller\IndexController::__proxyCall() #11 /www/im/vendor/hyperf/http-server/src/CoreMiddleware.php(142): App\Controller\IndexController->test() #12 /www/im/vendor/hyperf/http-server/src/CoreMiddleware.php(92): Hyperf\HttpServer\CoreMiddleware->handleFound() #13 /www/im/vendor/hyperf/dispatcher/src/AbstractRequestHandler.php(44): Hyperf\HttpServer\CoreMiddleware->process() #14 /www/im/vendor/hyperf/dispatcher/src/HttpRequestHandler.php(26): Hyperf\Dispatcher\AbstractRequestHandler->handleRequest() #15 /www/im/vendor/hyperf/dispatcher/src/HttpDispatcher.php(34): Hyperf\Dispatcher\HttpRequestHandler->handle() #16 /www/im/vendor/hyperf/http-server/src/Server.php(83): Hyperf\Dispatcher\HttpDispatcher->dispatch() #17 [internal function]: Hyperf\HttpServer\Server->onRequest() #18 {main}

First, huge thanks for this awesome project.

Collection::lazy() can be a lifesaver for performance when processing extreme large arrays which may consume too much ram. :)

Execute the command and paste the result below.

Command: uname -a && php -v && composer info | grep hyperf && php --ri swoole

Darwin devin-2.local 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
PHP 8.1.1 (cli) (built: Dec 21 2021 17:08:32) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.1, Copyright (c) Zend Technologies
Composer is operating slower than normal because you have Xdebug enabled. See https://getcomposer.org/xdebug
friendsofhyperf/cache               v3.0.0-rc.16       The cache componen...
friendsofhyperf/closure-command     v3.0.0-rc.9        The command compon...
friendsofhyperf/compoships          v1.0.0-beta.2      Hyperf relationshi...
friendsofhyperf/confd               v3.0.0-rc.9        The confd componen...
friendsofhyperf/exception-event     v3.0.0-rc.9        The exception comp...
friendsofhyperf/helpers             v3.0.0-rc.17       The commonly used ...
friendsofhyperf/http-client         v3.0.0-rc.16       The http client co...
friendsofhyperf/lock                v3.0.0-rc.16       The lock component...
friendsofhyperf/macros              v3.0.0-rc.17       The commonly used ...
friendsofhyperf/model-morph-addon   v1.0.0-beta.3      The Model morph ad...
friendsofhyperf/mysql-grammar-addon v1.0.1             The MySqlGrammar a...
friendsofhyperf/tinker              v3.0.0-rc.16       The Powerful REPL ...
hyperf/async-queue                  v3.0.0-rc.3        A async queue comp...
hyperf/cache                        v3.0.0-rc.5        A cache component ...
hyperf/circuit-breaker              v3.0.0-rc.3        A circuit breaker ...
hyperf/command                      v3.0.0-rc.7        Command for hyperf
hyperf/config                       v3.0.0-rc.8        An independent com...
hyperf/config-center                v3.0.0-beta.1      The abstraction co...
hyperf/config-etcd                  v3.0.0-rc.1        An etcd adapter fo...
hyperf/constants                    v3.0.0-rc.1        A constants compon...
hyperf/context                      v3.0.0-rc.1        A coroutine contex...
hyperf/contract                     v3.0.0-rc.10       The contracts of H...
hyperf/coordinator                  v3.0.0-beta.1      Hyperf Coordinator
hyperf/crontab                      v3.0.0-rc.8        A crontab componen...
hyperf/database                     v3.0.0-rc.10       A flexible databas...
hyperf/db-connection                v3.0.0-rc.4        A hyperf db connec...
hyperf/devtool                      v3.0.0-rc.8        A Devtool for Hyperf.
hyperf/di                           v3.0.0-rc.8        A DI for Hyperf.
hyperf/dispatcher                   v3.0.0-rc.3        A HTTP Server for ...
hyperf/engine                       v1.3.4            
hyperf/etcd                         v3.0.0-rc.8        Etcd Client for Hy...
hyperf/event                        v3.0.0-rc.5        an event manager t...
hyperf/exception-handler            v3.0.0-rc.9        Exception handler ...
hyperf/framework                    v3.0.0-rc.8        A coroutine framew...
hyperf/grpc                         v3.0.0-rc.5        A GRPC basic libra...
hyperf/grpc-client                  v3.0.0-rc.8        A GRPC Client for ...
hyperf/grpc-server                  v3.0.0-rc.5        A GRPC Server for ...
hyperf/guzzle                       v3.0.0-rc.3        Swoole coroutine h...
hyperf/http-message                 v3.0.0-rc.8        microservice frame...
hyperf/http-server                  v3.0.0-rc.10       A HTTP Server for ...
hyperf/load-balancer                v3.0.0-rc.4        A load balancer li...
hyperf/logger                       v3.0.0-rc.3        A logger component...
hyperf/macroable                    v3.0.0-rc.1        Hyperf Macroable p...
hyperf/metric                       v3.0.0-rc.8        hyperf metric comp...
hyperf/model-cache                  v3.0.0-rc.1        A model cache comp...
hyperf/model-listener               v3.0.0-rc.1        A model listener f...
hyperf/paginator                    v3.0.0-rc.10       A paginator compon...
hyperf/pool                         v3.0.0-rc.3        An independent uni...
hyperf/process                      v3.0.0-rc.3        A process componen...
hyperf/rate-limit                   v3.0.0-rc.3        A rate limiter imp...
hyperf/redis                        v3.0.0-rc.4        A redis component ...
hyperf/rpc                          v3.0.0-beta.1      A rpc basic librar...
hyperf/rpc-client                   v3.0.0-rc.8        An abstract rpc se...
hyperf/rpc-multiplex                v3.0.0-rc.4        Rpc for multiplexi...
hyperf/rpc-server                   v3.0.0-rc.4        An abstract rpc se...
hyperf/server                       v3.0.0-rc.1        A base server libr...
hyperf/testing                      v3.0.0-rc.1        Testing for hyperf
hyperf/tracer                       v3.0.0-rc.8        A open tracing sys...
hyperf/translation                  v3.0.0-rc.3        An independent tra...
hyperf/utils                        v3.0.0-rc.10       A tools package th...
hyperf/validation                   v3.0.0-rc.10       hyperf validation
hyperf/watcher                      v3.0.0-rc.3        Hot reload watcher...

swoole

Swoole => enabled
Author => Swoole Team <[email protected]>
Version => 4.8.11
Built => Dec 15 2022 16:43:47
coroutine => enabled with boost asm context
kqueue => enabled
rwlock => enabled
sockets => enabled
openssl => OpenSSL 1.1.1n  15 Mar 2022
dtls => enabled
http2 => enabled
json => enabled
curl-native => enabled
pcre => enabled
c-ares => 1.18.1
zlib => 1.2.11
brotli => E16777225/D16777225
mysqlnd => enabled
async_redis => enabled

Directive => Local Value => Master Value
swoole.enable_coroutine => On => On
swoole.enable_library => On => On
swoole.enable_preemptive_scheduler => Off => Off
swoole.display_errors => On => On
swoole.use_shortname => Off => Off
swoole.unixsock_buffer_size => 262144 => 262144

Description:

#####开启服务监控（metric）,涉及到io产生协程切换的，就会出现大量慢速，关闭监控后恢复正常

Steps To Reproduce:

Before you submit this issue, you has been search all existed issues and search the documentation

• [] I've been search all existed issues
• [] I've been read all documentation

Describe your question