搜索到
113
篇与
的结果
-
PHP-FPM进程假死问题处理思路 进程假死其实就是进程还在，但是不干活了。用ps命令看，进程确实存在，但就是不处理请求。PHP-FPM作为FastCGI进程管理器，负责管理PHP进程池。当它出现假死时，表现就是：进程存在但不响应新请求CPU使用率可能很低或者异常高内存占用可能持续增长日志可能停止更新或者出现异常快速定位和解决进程假死问题,关键是要：建立完善的监控体系，及时发现问题熟练掌握各种排查工具的使用针对常见场景做好预防措施特别要重视磁盘IO问题，这个经常被忽略但影响很大保持冷静，按照既定流程逐步排查磁盘IO问题特别值得重视，因为它往往比较隐蔽，不像CPU或内存问题那么明显。很多时候系统看起来资源充足，但就是响应慢，这时候就要想到是不是磁盘IO的问题了。快速判断是否为进程假死看进程状态ps aux | grep php-fpm正常情况下的输出如下：如果看到进程状态是D（不可中断睡眠）或者Z（僵尸进程），那基本就是有问题了。STAT: 进程状态码S: 睡眠状态s: 会话领导者l: 多线程+: 前台进程组R: 运行中D 状态的进程通常是在等待 I/O 操作完成，如磁盘读写Z 状态 (僵尸进程)，僵尸进程是已经终止但父进程尚未调用 wait() 获取其退出状态的进程检查进程响应# 查看PHP-FPM状态页面（需要先配置） curl http://localhost/status # 或者直接测试PHP页面响应 curl -w "@curl-format.txt" -o /dev/null -s "http://your-site.com/test.php"如果curl一直卡住不返回，或者返回时间特别长，那就很可能是假死了。观察系统资源# 查看CPU使用情况 top -p `pgrep php-fpm | tr '\n' ',' | sed 's/,$//'` # 查看内存使用 free -h # 查看磁盘IO iostat -x 1深入分析假死原因strace可以实时查看进程在做什么系统调用：# 找到问题进程PID ps aux | grep php-fpm | grep -v master # 追踪系统调用 strace -p 进程PID -f -e trace=all查看进程调用栈如果strace信息太多看不过来，可以用gdb查看调用栈gdb -p 进程PID (gdb) bt (gdb) info threads (gdb) thread apply all bt分析PHP-FPM慢日志PHP-FPM有个很有用的功能就是慢日志，可以记录执行时间超过阈值的请求：在php-fpm.conf中配置 slowlog = /var/log/php-fpm/slow.log request_slowlog_timeout = 5s慢日志会记录详细的调用栈，比如： [26-Oct-2024 15:30:45] [pool www] pid 12345 script_filename = /var/www/html/index.php [0x00007f8b8c0c8000] curl_exec() /var/www/html/api.php:45 [0x00007f8b8c0c8100] api_call() /var/www/html/index.php:23 通过慢日志能很快定位到是哪个函数卡住了。常见的假死场景和解决方案数据库连接问题这个真的太常见了。数据库连接池满了，或者网络抖动，都可能导致PHP进程卡在数据库操作上。解决方案：设置合理的数据库连接超时时间使用连接池，避免频繁建立连接监控数据库连接数设置MySQL连接超时 $pdo = new PDO($dsn, $user, $pass, [ PDO::ATTR_TIMEOUT => 5, PDO::MYSQL_ATTR_INIT_COMMAND => "SET SESSION wait_timeout=30"外部API调用超时调用第三方API时没设置超时，对方服务挂了你也跟着挂。我见过太多这种情况了，一个支付接口的问题导致整个网站瘫痪。#使用curl时一定要设置超时 $ch = curl_init(); curl_setopt($ch, CURLOPT_TIMEOUT, 10); curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 5);文件锁竞争多个进程同时操作同一个文件，可能导致死锁：#使用flock时要注意超时 $fp = fopen('data.txt', 'w'); if (flock($fp, LOCK_EX | LOCK_NB)) { // 获得锁，执行操作 fwrite($fp, $data); flock($fp, LOCK_UN); } else { // 获取锁失败，记录日志或者返回错误 error_log('Failed to acquire file lock'); } fclose($fp);磁盘IO问题导致的假死这个问题特别隐蔽，经常被忽略。磁盘IO性能差或者磁盘故障，会导致进程卡在文件读写操作上。#快速检测磁盘IO问题 # 查看磁盘IO使用率 iostat -x 1 5重点关注这几个指标：%util - 磁盘使用率，接近100%说明磁盘很忙await - 平均等待时间，超过20ms就要注意了svctm - 平均服务时间案例：服务器磁盘的%util一直在99%以上，但是通过top看CPU使用率很低。后来发现是磁盘坏道导致的，读写特别慢。找出占用IO的进程 # 安装iotop工具 apt install iotop -y # 实时查看IO使用情况 iotop -o -d 1 # 或者使用pidstat pidstat -d 1iotop的输出类似这样：Total DISK READ : 0.00 B/s | Total DISK WRITE : 12.34 M/s Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 15.67 M/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 1234 be/4 www 0.00 B/s 10.23 M/s 0.00 % 85.67 % php-fpm: pool www如果看到某个PHP-FPM进程的IO使用率特别高，那就要重点关注了。分析具体的文件操作# 使用lsof查看进程打开的文件 lsof -p 进程PID # 或者查看进程的文件描述符 ls -la /proc/进程PID/fd/案例：PHP程序在写日志时没有正确关闭文件句柄，导致同一个日志文件被打开了几千次，磁盘IO直接爆炸。磁盘空间不足的问题# 检查磁盘使用情况 df -h # 查找大文件 find /var/log -type f -size +100M -exec ls -lh {} \; # 查看目录大小 du -sh /var/log/*磁盘空间不足时，写操作会变得特别慢，甚至失败。PHP-FPM进程可能会卡在日志写入或者临时文件创建上。内存泄漏导致的假死PHP进程内存使用过多，触发系统的OOM机制，进程就卡住了。可以通过以下方式监控：# 查看进程内存使用 cat /proc/进程PID/status | grep VmRSS # 或者用ps ps -o pid,vsz,rss,comm -p 进程PID应急处理方案重启PHP-FPM服务# CentOS/RHEL systemctl restart php-fpm # Ubuntu/Debian systemctl restart php7.4-fpm # 或者直接kill掉重启 pkill php-fpm /usr/sbin/php-fpm -D不过重启会中断正在处理的请求，生产环境要慎重。平滑重启PHP-FPM支持平滑重启，不会中断现有连接：# 发送USR2信号进行平滑重启 kill -USR2 `cat /var/run/php-fpm.pid` # 或者使用systemctl systemctl reload php-fpm预防措施监控日志记录开启详细的日志记录，方便问题排查：php-fpm.conf log_level = notice access.log = /var/log/php-fpm/access.log access.format = "%R - %u %t \"%m %r\" %s %f %{mili}d %{kilo}M %C%%"定期重启一些老项目可能存在内存泄漏问题，可以设置定期重启# 添加到crontab，每天凌晨3点重启 0 3 * * * /usr/bin/systemctl reload php-fpm注意事项不要随便kill -9很多人遇到进程假死第一反应就是kill -9，但这样可能会导致数据不一致。最好先尝试kill -TERM让进程优雅退出。注意PHP-FPM版本差异不同版本的PHP-FPM配置参数可能不一样，升级时要注意兼容性。我就遇到过从PHP 7.2升级到7.4后，原来的配置不生效的情况。监控指标要合理设置监控阈值时不要太敏感，否则会产生很多误报。我之前设置响应时间超过1秒就告警，结果每天收到几十条告警消息，后来调整到5秒才比较合理。磁盘IO监控容易被忽略很多人只关注CPU和内存，忽略了磁盘IO。其实磁盘IO问题导致的服务假死非常常见，特别是那些有大量文件操作的应用。建议在监控系统中加入这些磁盘相关的指标：磁盘使用率（%util）平均等待时间（await）磁盘空间使用率inode使用率日志轮转PHP-FPM的日志文件会越来越大，一定要配置logrotate进行日志轮转，否则磁盘满了又是另一个问题。# /etc/logrotate.d/php-fpm /var/log/php-fpm/*.log { daily missingok rotate 7 compress delaycompress notifempty postrotate /bin/kill -USR1 `cat /var/run/php-fpm.pid 2>/dev/null` 2>/dev/null || true endscript }临时文件清理PHP会在/tmp目录下创建临时文件，如果程序异常退出，这些临时文件可能不会被清理。时间长了会占用大量磁盘空间和inode。# 定期清理PHP临时文件 find /tmp -name "php*" -type f -mtime +1 -delete # 清理session文件 find /var/lib/php/session -name "sess_*" -type f -mtime +1 -delete可以把这些命令加到crontab里定期执行。高级排查技巧使用perf分析性能对于复杂的性能问题，可以使用perf工具进行深入分析：# 安装perf工具 yum install perf -y # 对指定进程进行采样 perf record -p 进程PID -g -- sleep 30 # 查看报告 perf reportperf可以告诉你进程把时间都花在哪里了，对于定位性能瓶颈很有帮助。使用systemtap进行动态追踪systemtap是个更强大的工具，可以动态插入探针：# 监控文件IO操作 stap -e 'probe syscall.read, syscall.write { if (pid() == target()) printf("%s: %s\n", name, argstr) }' -x 进程PID不过systemtap比较复杂，一般情况下用strace就够了。分析core dump文件如果进程崩溃了，可以通过core dump文件分析崩溃原因：# 启用core dump ulimit -c unlimited echo '/tmp/core.%e.%p' > /proc/sys/kernel/core_pattern # 使用gdb分析core文件 gdb /usr/sbin/php-fpm /tmp/core.php-fpm.12345 (gdb) bt (gdb) info registers -
系统诊断工具lsof详解 在Linux系统中，网络连接是文件，设备是文件，管道也是文件，一切皆文件。而lsof的全称是"list open files"，即列出打开的文件。因此lsof就像是系统的"透视镜"，能让你看到系统内部正在发生什么。哪个进程打开了哪些文件，哪个端口被哪个程序占用，哪些文件被删除了但还在被进程使用着，这些信息lsof都能告诉你。基础用法最简单的用法就是直接输入lsof，不过这样会输出所有打开的文件，信息量太大了，一般不会这么用。输出的每一行代表一个打开的文件，包含了这些信息：COMMAND：进程名称PID：进程IDUSER：用户名FD：文件描述符TYPE：文件类型DEVICE：设备号SIZE/OFF：文件大小或偏移量NODE：inode号NAME：文件名或网络连接信息网络相关用法查看端口占用情况# 查看80端口被哪个进程占用 lsof -i:80 # 查看所有TCP连接 lsof -i tcp # 查看所有UDP连接 lsof -i udp # 查看指定IP和端口的连接 lsof -i@192.168.1.100:22查看网络连接状态# 查看所有网络连接 lsof -i # 查看指定状态的连接 lsof -i -sTCP:LISTEN # 查看监听状态的TCP连接 lsof -i -sTCP:ESTABLISHED # 查看已建立的TCP连接 #这个在排查网络问题的时候特别有用。比如怀疑某个服务连接数过多，就可以用这个命令来确认。进程相关的用法查看进程打开的文件 # 查看指定PID打开的文件 lsof -p 1234 # 查看指定进程名打开的文件 lsof -c nginx # 查看指定用户打开的文件 lsof -u www-data查看文件被哪些进程使用# 查看指定文件被哪些进程打开 lsof /var/log/nginx/access.log # 查看指定目录下的文件被哪些进程使用 lsof +D /var/log/文件系统相关找出被删除但未释放的文件 经常遇到这种情况：明明删除了大文件，但是df显示磁盘空间没有释放。这通常是因为文件被删除了，但还有进程在使用这个文件。# 查找被删除但未释放的文件 lsof | grep deleted # 或者更精确的查找 lsof +L1查看挂载点使用情况# 查看指定挂载点被哪些进程使用 lsof /mnt/data # 查看所有挂载点的使用情况 lsof -f -- /dev/sda1案例分享排查文件句柄泄漏 某个Python应用运行一段时间后就会报"Too many open files"的错误。怀疑是文件句柄泄漏。# 先找到进程PID ps aux | grep python_app # 查看进程打开的文件数量 lsof -p 12345 | wc -l # 查看具体打开了哪些文件 lsof -p 12345发现进程打开了大量的临时文件，而且数量一直在增长。最后定位到是代码里创建临时文件后没有正确清理。磁盘空间异常问题 服务器磁盘使用率突然飙升到95%，但是找不到大文件。后来用lsof发现有个日志轮转脚本有问题。排查发现有个进程打开了一个几GB的文件，但是这个文件在文件系统里找不到，原来是被删除了但进程还在写入。# 查找大文件 lsof | awk '$7 ~ /^[0-9]+$/ && $7 > 1000000 {print $2, $7, $9}' | sort -k2 -nr高级用法和技巧组合条件查询 lsof支持多种条件的组合，默认是OR关系，可以用-a参数改为AND关系。# 查看用户www-data打开的网络连接（OR关系） lsof -u www-data -i # 查看用户www-data打开的网络连接（AND关系） lsof -a -u www-data -i输出格式控制# 不显示主机名，直接显示IP lsof -n -i # 不显示端口名，直接显示端口号 lsof -P -i # 组合使用 lsof -nP -i:80这个在脚本里特别有用，因为解析主机名和端口名会比较慢。持续监控# 每2秒刷新一次 lsof -r 2 -i:80 # 监控到没有输出就退出 lsof +r 1 -i:80这个功能在调试网络连接问题的时候很有用，可以实时看到连接的变化。性能优化lsof虽然强大，但是在大型系统上运行可能会比较慢，特别是不加任何参数的时候。有几个优化技巧：尽量使用具体的参数，避免全量扫描使用-n和-P参数避免DNS和端口名解析在脚本中使用时，考虑缓存结果# 这样比较快 lsof -nP -i:80 # 这样会很慢 lsof | grep :80常见问题和注意事项使用lsof的时候有几个坑需要注意：权限问题：有些信息需要root权限才能看到系统负载：在高负载系统上运行lsof可能会影响性能输出解读：要理解各个字段的含义，特别是FD字段FD字段的含义比较复杂：cwd：当前工作目录txt：程序代码mem：内存映射文件数字：文件描述符号r、w、u：读、写、读写模式lsof的输出信息比较敏感，包含了很多系统内部的信息。在分享排查过程或者截图的时候，记得做好脱敏处理，避免泄露重要的系统信息。
-
TB级大文件处理脚本 #!/bin/bash # 处理TB级别日志文件的技巧 process_huge_file() { local file=$1 local chunk_size=${2:-1000000} # 默认100万行一个块 echo "处理大文件: $file ($(du -h "$file" | awk '{print $1}'))" # 方法1: 分块处理 split -l "$chunk_size" "$file" "chunk_" for chunk in chunk_*; do echo "处理块: $chunk" # 并行处理每个块 { awk '{ # 你的处理逻辑 ip_count[$1]++ } END { for (ip in ip_count) { print ip, ip_count[ip] > "result_'$chunk'.txt" } }' "$chunk" rm "$chunk" # 处理完立即删除 } & # 控制并发数 (($(jobs -r | wc -l) >= 4)) && wait done wait # 等待所有后台任务完成 # 合并结果 echo "合并结果..." awk '{sum[$1] += $2} END { for (ip in sum) print ip, sum[ip] }' result_chunk_*.txt | sort -k2 -nr > final_result.txt rm result_chunk_*.txt } # 方法2: 流式处理 (内存占用最小) stream_process() { local file=$1 # 使用管道流式处理，内存占用恒定 cat "$file" | \ awk '{ # 每处理10万行输出一次中间结果 if (NR % 100000 == 0) { print "处理进度:", NR > "/dev/stderr" } # 你的处理逻辑 ip_count[$1]++ # 定期清理内存 (保留热点数据) if (NR % 1000000 == 0) { for (ip in ip_count) { if (ip_count[ip] < 10) delete ip_count[ip] } } } END { for (ip in ip_count) { print ip, ip_count[ip] } }' | sort -k2 -nr }
-
数据库连接问题排查脚本 #!/bin/bash # 数据库连接问题排查脚本 echo "=== 数据库连接分析 ===" # 分析应用日志中的数据库错误 echo "数据库连接错误统计:" grep -i "database\|mysql\|connection" /var/log/myapp/error.log | \ grep -E "(timeout|refused|failed|error)" | \ sed 's/.*\[\([0-9-]*\).*/\1/' | \ sort | uniq -c | \ awk '{printf "%s: %d次错误\n", $2, $1}' # 分析慢查询日志 echo "慢查询TOP 10:" if [ -f /var/log/mysql/slow.log ]; then grep "Query_time" /var/log/mysql/slow.log | \ awk '{print $3}' | \ sort -nr | head -10 | \ awk '{printf "查询时间: %.2f秒\n", $1}' fi # 检查连接池状态 echo "当前数据库连接数:" mysql -e "SHOW STATUS LIKE 'Threads_connected';" 2>/dev/null | \ awk 'NR==2 {print "活跃连接:", $2}'
-
分布式处理脚本 #!/bin/bash # 分布式日志处理脚本 SERVERS=("server1" "server2" "server3") LOG_FILE="/var/log/nginx/access.log" distribute_process() { local total_lines=$(wc -l < "$LOG_FILE") local lines_per_server=$((total_lines / ${#SERVERS[@]})) echo "总行数: $total_lines, 每台服务器处理: $lines_per_server 行" for i in "${!SERVERS[@]}"; do local server="${SERVERS[$i]}" local start_line=$((i * lines_per_server + 1)) local end_line=$(((i + 1) * lines_per_server)) echo "分发给 $server: 行 $start_line - $end_line" # 提取对应行数并发送到远程服务器处理 sed -n "${start_line},${end_line}p" "$LOG_FILE" | \ ssh "$server" " awk '{ip_count[\$1]++} END { for (ip in ip_count) print ip, ip_count[ip] }' > /tmp/result_$i.txt " & done wait # 收集结果 echo "收集结果..." for i in "${!SERVERS[@]}"; do scp "${SERVERS[$i]}:/tmp/result_$i.txt" "result_$i.txt" done # 合并最终结果 awk '{sum[$1] += $2} END { for (ip in sum) print ip, sum[ip] }' result_*.txt | sort -k2 -nr > distributed_result.txt rm result_*.txt }
