fpm 和 cli 的内存处理问题

[datoubb]

前提

目前公司内用的 cli 常驻进程队列只能通过 kill 掉重启,避免 define 常量对多次请求之间的影响?(像 fpm 的 worker 一样)

[公司队列里我的任务调用很多其他组提供的方法都直接用了 define 常量,所以需要在任务开启时先 define,但是不 kill 掉进程 就会影响到下一次请求的常量]

个人分析

1.fpm 的 master 去 fork 的 worker 子进程每次处理完请求不会 kill 掉,结束时只调用 register_shutdown_function 注册的 gc_collect_cycles()去执行回收机制,但是我记得 gc 也只回收 zval 容器,不回收常量. 又因为看到 fpm 也会有内存泄露的可能,所以通过 max_request 配置去优化

=> 所以猜测出子进程的旧内存块不会清理,而是重新申请一块新内存块

2.又查到申请内存跟 emalloc，erealloc 之类的有关 ( https://www.kancloud.cn/kancloud/php-internals/42797)

3.那么怎么才能让 cli 跟 fpm 那样,再不 kill 掉进程的同事能重新分配内存块呢?在下小菜鸡一个,请求各位大神,百度谷歌都不太好找

[FrankAdler]

常量就是用来放置不会变的数据，怎么会多个请求之间影响，建议你别用 define 了

[datoubb]

@FrankAdler 就是单独一个请求里是不会变 ，但是一个队列 worker 执行执行多条请求的时候就会导致 define 重复定义的问题 define 这个是我调用别人的方法里面他直接用到的，历史原因不好改

[ihipop]

fpm 的跨请求内存泄漏大部分是 C 部分引起的
其它问题你看下 fpm 的生命周期再问

要么你描述有问题，要么你公司实现有问题