本文介绍在 linux 服务器环境下，如何准确获取单个 laravel 进程（而非整个系统）的实时内存与 cpu 使用量，并提供轻量级、可集成、生产友好的实践方案。
本文介绍在 linux 服务器环境下，如何准确获取单个 laravel 进程（而非整个系统）的实时内存与 cpu 使用量，并提供轻量级、可集成、生产友好的实践方案。
Laravel 应用本质上是运行在 PHP-FPM 或 Apache/NGINX + PHP SAPI 模式下的多个 PHP 进程集合。你当前代码中调用 free 和 sys_getloadavg() 获取的是整个操作系统的内存与平均负载，这无法反映“当前请求所触发的 Laravel 实例”或“PHP-FPM 工作进程”的真实资源消耗——正如 Windows 任务管理器按进程显示 RAM/CPU，我们需要定位到具体的 PHP 进程。
✅ 正确思路：按进程维度监控，而非系统维度
Linux 提供了完善的进程级资源统计接口。对于 Laravel 应用，最可靠的方式是：
- 识别当前 PHP 进程 ID（PID）：使用 getmypid() 获取正在处理该 HTTP 请求的 PHP 进程 PID；
- 读取 /proc/{pid}/statm 和 /proc/{pid}/status：获取该进程的内存占用（单位 KB）；
- 计算 CPU 时间占比（需两次采样）：结合 /proc/{pid}/stat 中的 utime 和 stime 字段，配合时间差估算 CPU 使用率（注意：单次请求内 CPU 占比极低，更适合长期运行的 Artisan 命令或队列 worker 监控）。
✅ 示例：获取当前 Laravel 请求进程的内存使用（KB → MB）
// 在路由或中间件中
Route::get('/process-stats', function () {
$pid = getmypid();
$statmPath = "/proc/{$pid}/statm";
if (file_exists($statmPath)) {
$statm = file_get_contents($statmPath);
$parts = explode(' ', trim($statm));
// $parts[0] = total pages (4KB/page), so * 4 → KB, / 1024 → MB
$rssInMB = round(($parts[0] * 4) / 1024, 2);
// 更精确的 RSS（实际物理内存）来自 /proc/{pid}/status
$status = file_get_contents("/proc/{$pid}/status");
if (preg_match('/^VmRSS:\s+(\d+) kB/m', $status, $matches)) {
$rssInMB = round($matches[1] / 1024, 2);
}
return response()->json([
'pid' => $pid,
'memory_rss_mb' => $rssInMB . ' MB',
'peak_memory_usage_mb' => round(memory_get_peak_usage(true) / 1024 / 1024, 2) . ' MB'
]);
}
return response()->json(['error' => 'Process stats unavailable'], 500);
});
? memory_get_peak_usage(true) 返回的是当前 PHP 脚本分配的内存（含 Zend 内存管理器开销），属于应用层视角；而 /proc/{pid}/status 的 VmRSS 是操作系统视角的真实物理内存占用，两者互补——前者便于 Laravel 内部优化（如避免大数组缓存），后者用于容量规划与异常检测。
Laravel 13.2.0下载PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
⚠️ 注意事项与生产建议
- Web 请求生命周期短：单次 HTTP 请求中，进程内存波动小、CPU 时间极短（毫秒级），/proc/{pid}/stat 的 CPU 时间字段难以体现瞬时负载。因此，不推荐在 Web 路由中计算 CPU 使用率；更适合监控长时间运行的 php artisan queue:work 或 horizon 进程。
- 权限限制：Web 服务器用户（如 www-data）默认可读 /proc/{own_pid}/*，但不可读其他用户进程。确保 PHP 进程以独立用户运行（如 php-fpm pool 配置 user = laravel），避免跨应用干扰。
-
不要替代专业监控：此方法适用于调试、开发验证或轻量级健康检查。生产环境应使用：
- htop / ps aux --sort=-%mem：快速定位高内存 PHP-FPM 子进程；
- Prometheus + Node Exporter + cAdvisor：采集进程级指标（通过 process-exporter）；
- Grafana Dashboard：可视化 Laravel 队列 worker、API 响应延迟与对应进程资源关联分析。
✅ 补充：监控 PHP-FPM 池整体内存趋势（推荐用于运维）
若需掌握 Laravel 应用整体资源画像，启用 PHP-FPM 状态页（需 Nginx/Apache 配置代理），访问 http://your.app/fpm-status?full，可查看每个 active process 的 start time, requests, memory（RSS）等字段，再聚合统计——这才是真正贴近“一个 Laravel 应用”的资源视图。
总之，脱离进程上下文谈“Laravel 内存用量”没有意义；精准监控始于 getmypid()，成于 /proc 文件系统，稳于专业可观测性栈。从单次请求诊断，到服务级长期观测，分层施策，方为正解。
