在 CentOS 上跑 PHP 服务时，日志往往是最容易被忽略的一块：平时看起来只是多写几个文件，真正到了高并发或磁盘 I/O 紧张时，才会发现 PHP-FPM 的响应速度也被拖慢了。要把这件事处理好，关键不是“彻底少记日志”，而是把该保留的错误信息留下来，把无效写入、超大文件和阻塞式 I/O 降下来。下面按几个最常见、也最容易落地的环节来拆解。
先从日志级别下手，减少无效写入
很多线上环境的问题，不是没有日志，而是日志记得太多。像 DEBUG、INFO 这类调试信息如果长期留在生产环境里，写入频率会非常高，日志文件也会很快膨胀。对大多数线上 PHP 应用来说，更实用的做法是只保留真正影响运行的级别，例如 ERROR、WARNING 和 PARSE。
可以先在 php.ini 里把错误报告范围收紧，同时确认日志功能已经开启：
error_reporting = E_ERROR | E_WARNING | E_PARSE
# 仅记录错误、警告和解析错误
log_errors = On
# 开启日志记录如果你的站点通过 PHP-FPM 运行，也可以在对应池配置里单独指定错误日志位置，例如 /etc/php-fpm.d/www.conf：
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on这一步的价值很直接：日志文件体积会下降，写入次数也会减少。对于 I/O 本来就紧张的服务器，这通常是最先见效的一项调整。
日志写入为什么会拖慢请求：同步与缓冲的差别
日志性能问题里最隐蔽的一类，是同步写入带来的阻塞。每次请求在记录日志时，如果都要立刻把内容刷到磁盘，PHP 进程就得等待 I/O 完成。单次看上去不明显，但日志量一旦上来，请求延迟就会被不断累加。
这类场景更适合用带缓冲能力的日志组件。文中给出的做法是使用 Monolog 的 BufferHandler：先把日志暂存在内存里，攒到一定数量后再批量写盘，从而减少频繁的小 I/O。
use MonologLogger;
use MonologHandlerStreamHandler;
use MonologHandlerBufferHandler;
// 创建日志通道
$logger = new Logger('app');
// 使用BufferHandler实现批量异步写入（缓冲100条或1秒后写入）
$handler = new BufferHandler(
new StreamHandler('/var/log/php/app.log', Logger::WARNING),
100,
Logger::WARNING
);
$logger->pushHandler($handler);
// 记录日志（不会立即写入磁盘）
$logger->warning('This is a warning message');这里要注意，示例的核心事实是：日志先进入缓冲区，再以批量方式写入 /var/log/php/app.log，并且只处理 Logger::WARNING 及以上级别。对于访问量较大、错误日志又比较集中的业务，这种方式比每条都立即落盘更稳妥。
从运维角度看，异步或缓冲写入并不是为了“完全不写日志”，而是把日志写入从请求主路径里尽量挪开。这样主线程承担的额外成本更低，高并发时更容易维持稳定响应。
把日志文件管住：轮转、压缩和存储方式一起做
即使日志级别已经收紧，如果文件长期不轮转，依旧会出现另一个老问题：单个日志文件越来越大。文件大到几百 MB 甚至几个 GB 后，不仅写入效率会受到影响，日常排查也会变得笨重。
在 CentOS 这类环境里，最常用的处理方式就是交给 logrotate。它可以按天轮换、保留固定数量的历史文件，并自动压缩旧日志。示例配置如下，文件路径为 /etc/logrotate.d/php-fpm：
/var/log/php-fpm/*.log {
daily # 每天轮换
missingok # 忽略缺失文件
rotate 7 # 保留最近7天的日志
compress # 压缩旧日志（节省空间）
notifempty # 空日志不轮换
create 640 root adm # 新日志文件权限
}这套设置的重点很明确：每天切分、保留 7 天、旧文件压缩、空文件不轮换，同时新建文件权限为 640 root adm。对大多数常规站点来说，这已经能把日志膨胀问题控制在一个可维护范围内。
除了轮转，存储介质和写入方式也会影响性能：
- 如果条件允许，把日志目录放到 SSD 上，通常能明显优于 HDD。
- 尽量减少“一条日志一次写入”的模式，能批量写就批量写。
- 当日志规模已经超过单机本地文件适合承受的范围，可以把查询和分析迁到集中式日志系统。
例如，批量写入可以直接用下面这类方式，把 100 条日志合并成一次 file_put_contents：
$logData = [];
for ($i = 0; $i < 100; $i++) {
$logData[] = "Log entry {$i}";
}
file_put_contents('/var/log/php/batch.log', implode(PHP_EOL, $logData) . PHP_EOL, FILE_APPEND);如果业务日志量继续增长，本地磁盘就不应该再承担全部分析任务。把日志发送到 ELK Stack、Graylog 这类集中式系统，本地只保留短期缓存，通常更适合长期运行的生产环境。
禁掉没价值的日志，避免后台持续空转
有些日志开关默认存在，但平时并不产生业务价值，留着反而会制造额外 I/O。排查这类“噪声日志”时，可以优先看三个方向。
关闭不需要的扩展调试日志
例如 OPcache 的调试日志，如果当前并不在定位 OPcache 自身问题，就没必要常年保留：
; opcache.error_log = /var/log/opcache_errors.log评估慢查询日志是否真的要长期开启
如果数据库层当前没有慢 SQL 监控需求，MySQL 的 slow_query_log 长期开启也会持续写文件。这个点虽然不属于 PHP 本身，但最终消耗的仍然是同一台机器的 I/O 资源。
过滤第三方库的低价值输出
不少框架或依赖库会输出大量非关键日志。对于线上环境，应该只保留真正影响业务可用性的内容，把噪声尽量压掉，否则写得越多，后续检索和排障反而越低效。
最后再看 PHP-FPM 与系统参数，别让日志拖垮整体资源
日志优化做到后面，往往就不是单一文件写入的问题了，而是要回到 PHP-FPM 和系统资源本身。因为即使日志量已经下降，如果进程数过多、缓存没开、文件描述符太紧，整体表现依旧不会理想。
按机器容量调整 PHP-FPM 进程参数
像 pm.max_children、pm.start_servers 这类参数，要结合服务器内存和负载来设。原文给出的示例如下：
pm.max_children = 50 # 根据服务器内存调整（每个子进程约消耗10-20MB内存）
pm.start_servers = 10 # 启动时的子进程数这里最值得关注的是备注信息：每个子进程约消耗 10-20MB 内存。也就是说，日志写入只是表层压力，真正的稳定性还取决于 PHP-FPM 进程模型是否和机器资源匹配。
开启 OPCache，减少脚本重复解析
日志优化和执行效率优化并不冲突。打开 OPCache 后，PHP 脚本编译结果可以复用，能减少重复加载与解析带来的额外时间：
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000这部分不会直接减少日志数量，但能降低请求整体执行成本，给高并发场景留出更多余量。
提高文件描述符上限
当日志文件打开频率高、同时存在多个 PHP-FPM 进程或其他服务竞争文件句柄时，系统默认限制可能不够。可以在 /etc/security/limits.conf 中增加：
* soft nofile 4096
* hard nofile 8192然后执行：
ulimit -n 4096这一步的意义是给高频文件操作留出更宽松的上限，避免在日志写入高峰期出现额外的资源瓶颈。
综合来看，提升 CentOS 上 PHP 日志性能，核心不是依赖某一个“神配置”，而是同时控制日志量、写入方式、文件生命周期和运行资源。先收紧级别，再处理缓冲与轮转，最后回头检查 PHP-FPM 和系统参数，通常就能把日志对性能的拖累降到比较低的水平。
