基于 Yii 2.0 实现的命令行脚本，持续运行期间，占用内存过高的分析与解决

1、当在 MySQL 与 Redis 中的数据量较小时，Docker 容器的 CPU：0.02%，内存：298MB，如图1、图2

2、查看 MySQL 的实例监控情况，内存占用：2328MB，如图3

3、查看 Redis 的实例监控情况，已使用容量：33MB，如图4

4、命令行脚本 \console\controllers\CmcConsoleUserController.php 、\console\controllers\ConfigColumnUserController.php 代码如下：

5、命令行脚本的运行基于 Supervisor 提供支持，/etc/supervisord.d/yii-cmc-console-user-sync.ini、/etc/supervisord.d/yii-config-column-user-sync.ini，如图5

6、在 8 个租户下批量导入用户数据，让每个租户下的导入的用户数量为 999 个，总计 8000 左右，如图6

租户名称：广东省、广州市、深圳市、南山区、罗湖区、蛇口街道、招商街道、DEFAULT租户

7、在本地环境的 Redis 中，用户数量为 8223，在开发环境的 Redis 中，对接的同一个框架，但用户数量一直为 3000 左右，始终未达到 8223，如图7、图8

8、最终发现问题所在，原因在于有 2 个容器在同时运行，每个容器中皆在运行命令行：cmc-console-user/sync，数据相互冲突覆盖，停止掉另一个容器中的命令行脚本(计划后续将命令行单独部署至一个容器中，隔离开，以为后续集群部署做准备)，如图9

9、在本地环境的 Redis 中，用户数量为 8223，在开发环境的 Redis 中，用户数量为 8223，已经一致，如图10

10、在 8 个租户的栏目设置中，每个租户下添加 2 个栏目，每个栏目中添加全部用户，即每个租户下添加的数据数量为 2000 左右，总计 16000 左右，如图11

11、在 第 6 步骤执行完毕后，Docker 容器的 CPU：0.05%，内存：382MB，内存增加了 80MB 左右，每 1000 条数据的添加，内存会增加 10 MB 左右。在 第 10 步骤执行完毕后，Docker 容器的 CPU：9.9%，内存：541MB，内存增加了 160MB 左右，每 1000 条数据的添加，内存会增加 20 MB 左右。因此，优化的重点在于第 2 个命令行脚本。如图12、图13

12、编辑 \console\controllers\CmcConsoleUserController.php、\console\controllers\ConfigColumnUserController.php，查看实际使用的内存量、系统分配总的内存量

13、运行第 1 个命令行脚本，日志如下：

14、运行第 2 个命令行脚本，日志如下：总结：与第 1 个命令行脚本的主要差异在于实际使用的内存量上，相差 17 MB 左右。

15、分析优化第 1 个命令行脚本，\console\controllers\CmcConsoleUserController.php，基于 unset() 实现，实际使用的内存量减少 2 MB 左右，系统分配总的内存量无变化

16、分析优化第 2 个命令行脚本，\console\controllers\ConfigColumnUserController.php，基于 unset() 实现，实际使用的内存量减少 9 MB 左右，系统分配总的内存量无变化

17、升级至开发环境，Docker 容器的 CPU：5.4%，内存：371MB，内存减少了 (541MB – 371MB) = 170MB 左右，证明基于 unset() 实现的方案是可行的。如图14

18、分析优化第 1 个命令行脚本，\console\controllers\CmcConsoleUserController.php，以减少执行时间为目标，从 30 分钟左右减少至 1 分钟左右。删除掉：addIMAccount() 相关的实现，其在遍历过程中，执行 HTTP 请求，消耗大量的时间。实际使用的内存量减少 0.09 MB 左右，系统分配总的内存量减少 0.002 MB 左右

19、升级至开发环境，Docker 容器的 CPU：5.4%，内存：280MB，内存减少了 (371MB – 371MB) = 0MB 左右，证明减少命令行的执行时间，对于内存的使用优化无意义。虽然在本地开发环境中，实际使用的内存量减少 0.09 MB 左右，系统分配总的内存量减少 0.002 MB 左右，减少的内存量很小。如图15

20、分析优化第 1 个命令行脚本，\console\controllers\CmcConsoleUserController.php，以数组形式获取数据，在查询方法前调用 asArray() 方法，来获取 PHP 数组形式的结果。实际使用的内存量减少 0.09 MB 左右，系统分配总的内存量减少 8.96 MB 左右

21、分析优化第 2 个命令行脚本，\console\controllers\ConfigColumnUserController.php，以数组形式获取数据，在查询方法前调用 asArray() 方法，来获取 PHP 数组形式的结果。实际使用的内存量减少 12.72 MB 左右，系统分配总的内存量减少 8.95 MB 左右

22、分析优化第 1 个命令行脚本，\console\controllers\CmcConsoleUserController.php，变量 $attributes 在每一次遍历中皆有定义，实际上在大部分遍历中皆未使用，因此，仅在有使用的情况下才定义。实际使用的内存量减少 0.0007 MB 左右，系统分配总的内存量无变化

23、升级至开发环境，Docker 容器的 CPU：0.04%，内存：283MB，内存减少了 (371MB – 283MB) = 90MB 左右，证明以数组形式获取数据，在查询方法前调用 asArray() 方法，来获取 PHP 数组形式的结果。优化的方案是可行的。如图16

24、分析优化第 1 个命令行脚本，\console\controllers\CmcConsoleUserController.php，基于 unset() 实现，实际使用的内存量减少 0.067 MB 左右，系统分配总的内存量无变化

25、分析优化第 1 个命令行脚本，\console\controllers\CmcConsoleUserController.php，得出结论，内存占用过大的根本原因在于 RedisCmcConsoleUser::find()。其在 8000 左右的 Redis AR 模型记录中查找出 8 条记录。

26、分析优化第 1 个命令行脚本，\console\controllers\CmcConsoleUserController.php，删除 RedisCmcConsoleUser::find()，以另外一种形式来获取租户ID列表。

27、分析优化第 1 个命令行脚本，\console\controllers\CmcConsoleUserController.php，删除 RedisCmcConsoleUser::find()，以另外一种形式来获取租户ID列表，实际使用的内存量减少 1.72 MB 左右，系统分配总的内存量减少 21.17 MB 左右

28、分析优化第 2 个命令行脚本，\console\controllers\ConfigColumnUserController.php，删除 RedisCmcConsoleUser::find()，以另外一种形式来获取租户ID列表，实际使用的内存量增加 0.37 MB 左右，系统分配总的内存量减少 19.39 MB 左右

29、升级至开发环境，Docker 容器的 CPU：92%，内存：435MB，CPU 增加了 (92% – 0.04%) = 91.96% 左右，内存增加了 (435MB – 283MB) = 152MB 左右。如图17、图18

 

30、分析具体原因，基于 Yii 2 的 HTTP 客户端扩展在 Linux 中必须添加：setData([])，否则响应 400，如图19、图20

 

31、解决了 响应 400 的 Bug 之后，升级至开发环境，Docker 容器的 CPU：0.04%，内存：341MB，CPU无变化，内存增加了 (341MB – 283MB) = 60MB 左右。证明实际使用的内存量增加，系统分配总的内存量减少，Docker 的内存占用是在增加的(主要受到实际使用的内存量的影响)。如图21、图22

 

32、延缓执行 60 秒，决定不再使用 sleep()，因为，在 sleep() 期间，内存一直处于占用中的，实际上延长了内存占用的时间。虽然可能降低了 CPU 的占用百分比。

33、分析优化第 1 个命令行脚本，\console\controllers\CmcConsoleUserController.php，设置同步标识的缓存，如果不存在，则同步，将数据在缓存中保留 60 秒。如果存在，则不同步(注：在同步成功后的 60 秒内，内存占用会很小，见第 2 个优化后的内存占用情况)。

34、分析优化第 2 个命令行脚本，\console\controllers\ConfigColumnUserController.php，设置同步标识的缓存，如果不存在，则同步，将数据在缓存中保留 60 秒。如果存在，则不同步(注：在同步成功后的 60 秒内，内存占用会很小，见第 2 个优化后的内存占用情况)。

35、升级至开发环境，Docker 容器的 CPU：16%，内存：486MB，CPU 增加了 (16% – 0.04%) = 15.96% 左右，内存增加了 (486MB – 341MB) = 140MB 左右，证明同步成功后的 60 秒内，避免再次同步。优化的方案是不可行的(与预期不相符)。如图23、图24

 

36、仔细对比与第 31 步骤上的差异，在于命令行每次执行快结束时，使用了 sleep()，决定在同步成功后的 60 秒内，使用 sleep()，在同步成功后的 60 秒内，仅会再执行一次命令行(且执行时间长度大于：60 秒)，而不会执行多次。查看 supervisord 运行状态，发现命令行执行的时间很短、频率很高，尤其是第 2 个命令行。如图25

37、升级至开发环境，Docker 容器的 CPU：0.04%，内存：283MB，CPU 无变化，内存减少了 (341MB – 283MB) = 60MB 左右。证明同步成功后的 60 秒内，避免再次同步。优化的方案是可行的。如图26、图27

 

38、决定再次降低同步的执行频率，同步成功后的 5 * 60 秒内，避免再次同步。查看 supervisord 运行状态，发现命令行执行的时间很长、频率很低。升级至开发环境，Docker 容器的监控数据无变化。证明当执行频率达到某个临界值之后，再次降低，优化的意义不大了的，顶多 CPU 的平均值更低一些(理论上)。如图28

39、避免在生产环境中，当租户数量过多时，一次同步所有租户下的用户，进而导致内存占用过大、运行时间过长，决定一次仅同步一个租户下的用户。

40、分析优化第 1 个命令行脚本，\console\controllers\CmcConsoleUserController.php，遍历租户ID列表时，break 结束当前 foreach 结构的执行，即命令行的每一次运行，仅同步成功一个租户下的用户列表。在 有 HTTP 请求，有同步 的情况下，实际使用的内存量增加 1.54 MB 左右，系统分配总的内存量减少 0.75 MB 左右

41、分析优化第 2 个命令行脚本，\console\controllers\ConfigColumnUserController.php，遍历租户ID列表时，break 结束当前 foreach 结构的执行，即命令行的每一次运行，仅同步成功一个租户下的用户列表。在 无 HTTP 请求，有同步 的情况下，实际使用的内存量减少 0.45 MB 左右，系统分配总的内存量无变化

42、升级至开发环境，Docker 容器的 CPU：0.07%，内存：283MB，CPU 增加了 (0.07% – 0.04%) = 0.03% 左右，内存减少了 (283MB – 276MB) = 7MB 左右。证明遍历租户ID列表时，break 结束当前 foreach 结构的执行，即命令行的每一次运行，仅同步成功一个租户下的用户列表。优化的方案是不可行的，意义不大。如图29、图30

43、查看 MySQL 的实例监控情况，内存占用：6166MB，参考价值不大，因为是与其他产品共享同一个数据库，如图31

44、查看 Redis 的实例监控情况，已使用容量：75MB，如图32

45、占用内存的减少实现方案，总结如下：

(1)数据量的增加，会导致内存的持续增加，后期当数据量达致一定的量级时，需要支持集群部署
(2)Docker 容器的 CPU：5.4%，内存：371MB，内存减少了 (541MB – 371MB) = 170MB 左右，证明基于 unset() 实现的方案是可行的
(3)Docker 容器的 CPU：5.4%，内存：280MB，内存减少了 (371MB – 371MB) = 0MB 左右，证明减少命令行的执行时间，对于内存的使用优化无意义。
(4)Docker 容器的 CPU：0.04%，内存：283MB，内存减少了 (371MB – 283MB) = 90MB 左右，证明变量仅在使用时才定义，以数组形式获取数据，在查询方法前调用 asArray() 方法，来获取 PHP 数组形式的结果。优化的方案是可行的。
(5)Docker 容器的 CPU：92%，内存：435MB，CPU 增加了 (92% – 0.04%) = 91.96% 左右，内存增加了 (435MB – 283MB) = 152MB 左右。HTTP 请求响应 400 时，命令行抛出异常时，CPU 与内存皆增加得很厉害
(6)解决了 响应 400 的 Bug 之后，升级至开发环境，Docker 容器的 CPU：0.04%，内存：341MB，CPU无变化，内存增加了 (341MB – 283MB) = 60MB 左右。删除 RedisCmcConsoleUser::find()，以另外一种形式(HTTP 请求)来获取租户ID列表，实际使用的内存量增加 0.37 MB 左右，系统分配总的内存量减少 19.39 MB 左右。证明实际使用的内存量增加，系统分配总的内存量减少，Docker 的内存占用是在增加的(主要受到实际使用的内存量的影响)
(7)Docker 容器的 CPU：16%，内存：486MB，CPU 增加了 (16% – 0.04%) = 15.96% 左右，内存增加了 (486MB – 341MB) = 140MB 左右，查看 supervisord 运行状态，发现命令行执行的时间很短、频率很高时，CPU 与内存皆增加得一般厉害
(8)Docker 容器的 CPU：0.04%，内存：283MB，CPU 无变化，内存减少了 (341MB – 283MB) = 60MB 左右。证明同步成功后的 60 秒内，避免再次同步。优化的方案是可行的
(9)决定再次降低同步的执行频率，同步成功后的 5 * 60 秒内，避免再次同步。当执行频率达到某个临界值之后，再次降低，优化的意义不大了的，顶多 CPU 的平均值更低一些(理论上)
(10)遍历租户ID列表时，break 结束当前 foreach 结构的执行，即命令行的每一次运行，仅同步成功一个租户下的用户列表。Docker 容器升级后，性能指标未变化。优化的意义不大了的，虽然命令行同步一次的运行时间大幅度减少(原因可能在于开发环境的租户数量不多，总的数据量不大，优化的意义未体现出来。当租户数量更多时，内存占用的优化意义才能够体现出来)