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 -p <code>pgrep -f "start.php start" - 若需实时调度（极谨慎），可用
chrt切换策略：chrt -f 50 php start.php start -d（但 Workerman 非实时任务，SCHED_FIFO易导致系统卡死）
注意：负值需 root 权限；普通用户只能设 ≥0 的值。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
必须同步配置系统级权限与限制
仅执行 nice 或 renice 不保证生效，以下三项缺一不可：
-
/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 启动整个进程树。
