Workerman 不支持 worker_priority 配置,需通过 Linux 进程级命令(nice/renice/chrt)调整优先级,并配合 limits.conf 权限设置与 systemd 管控才能生效。

Workerman 进程无法通过 worker_priority 调整优先级
Workerman 是 PHP 应用层框架,它本身不支持 worker_priority 指令——这个配置只存在于 Nginx 的全局块中,对 Workerman 完全无效。你如果在 Workerman 的 start.php 或配置文件里写 worker_priority,PHP 解释器会直接报错或静默忽略。
真正生效的 Linux 层调度控制方式
要提升 Workerman 主进程(如 php start.php start -d 启动的守护进程)的 CPU 调度权重,必须绕过框架限制,直接操作 Linux 进程级参数:
- 启动时用
nice设置初始 nice 值:nice -n -5 php start.php start -d - 运行中用
renice动态调整:renice -n -5 -ppgrep -f "start.php start" - 若需实时调度(极谨慎),可用
chrt切换策略:chrt -f 50 php start.php start -d(但 Workerman 非实时任务,SCHED_FIFO易导致系统卡死)
注意:负值需 root 权限;普通用户只能设 ≥0 的值。
必须同步配置系统级权限与限制
仅执行 nice 或 renice 不保证生效,以下三项缺一不可:
Linux 安全审计工具,检查 SSH 配置、开放/监听端口、防火墙规则(ufw/iptables/nftables)、失败登录尝试、sudoers 权限...
-
/etc/security/limits.conf中为运行 Workerman 的用户添加:www-data soft priority 10www-data hard priority 15(替换www-data为你实际用户) - 确保 Workerman 进程以该用户启动,且未被 systemd、supervisord 等中间层覆盖 nice 值
- 验证是否落地:
ps -o pid,ni,comm -C php | grep start.php——ni列必须等于你设置的值,否则说明 limits 或权限未生效
比调优 nice 更有效、更安全的替代方案
在多数 Web 场景下,单纯压低 nice 值收益有限,且易引发 SSH 卡顿、监控失联等副作用。推荐优先落地以下措施:
- 绑定 CPU 核心:
taskset -c 0-3 php start.php start -d,避免跨核缓存失效 - 用 systemd 统一管控(若使用):在
/etc/systemd/system/workerman.service.d/override.conf中写:[Service]Nice=-5CPUAffinity=0-3CPUQuota=80% - 关闭 Workerman 的
daemonize,改用 systemd 管理,才能真正继承Nice=和资源限制
真正容易被忽略的是:Workerman 默认开启 reactor 多线程模型,但 Linux 调度单位是线程(LWP),ps 查到的主进程 ni 值 ≠ 所有 reactor 线程的优先级;若需全链路保障,应统一用 chrt 或 taskset 启动整个进程树。










