搜索到
36
篇与
的结果
-
系统诊断工具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的输出信息比较敏感，包含了很多系统内部的信息。在分享排查过程或者截图的时候，记得做好脱敏处理，避免泄露重要的系统信息。 -
Linux常用系统监控工具介绍 在服务器管理和系统运维的日常工作中，实时监控系统资源使用情况是一项基础且关键的任务。除了比较基础的top命令外，比较常用的还有以下这些：htop：top命令的增强版glances：提供更全面的系统监控，包括网络、磁盘IO等atop：专注于长期性能监控和记录btop++：htop的现代替代品，提供更华丽的界面和更多功能iotop：专门监控磁盘IO使用情况nmon：IBM开发的系统监控工具，提供更多性能数据下面重点介绍一下htop命令。htop是一款功能强大且易于使用的Linux系统监控工具，它通过直观的界面和丰富的交互功能，大大提升了系统管理员监控和管理进程的效率。从基本的系统资源监控到复杂的进程管理，从简单的排序过滤到自定义显示配置，htop几乎能满足所有与进程监控相关的需求。在日常运维工作中，掌握htop的使用技巧不仅能帮助你快速定位系统问题，还能提高工作效率，减少排障时间。无论是处理高CPU负载、内存泄漏，还是需要快速终止失控进程，htop都能提供直观且高效的解决方案。htop界面详解运行htop时会看到一个分为上下两个部分的界面。顶部区域顶部区域显示系统的整体资源使用情况，包括：CPU使用率 每个CPU核心都有独立的使用率条，不同颜色代表不同类型的进程蓝色：低优先级进程绿色：普通用户进程红色：内核进程黄色/橙色：IRQ时间洋红色：软中断时间灰色：IO等待时间内存使用情况 显示物理内存和交换空间的使用百分比和具体数值绿色：已使用内存蓝色：缓冲区黄色/橙色：缓存负载平均值 显示1分钟、5分钟和15分钟的系统负载平均值正常运行时间 系统启动至今的运行时间任务统计 显示总进程数、运行中的进程数等信息底部区域底部区域显示系统中运行的进程列表，默认按CPU使用率排序。每个进程显示以下信息：PID：进程IDUSER：进程所有者PRI：进程优先级NI：nice值VIRT：虚拟内存大小RES：常驻内存大小SHR：共享内存大小S：进程状态（R=运行，S=睡眠，Z=僵尸等）CPU%：CPU使用百分比MEM%：内存使用百分比TIME+：进程运行时间Command：命令名称和参数htop操作技巧基本操作上下左右键：在进程列表中导航F5：切换树形视图，显示进程父子关系F6：选择排序字段F9：向进程发送信号（如终止进程）F10或q：退出htop进程管理htop最强大的功能之一是其直观的进程管理能力：终止进程：选中进程后按F9，然后选择要发送的信号（如SIGTERM或SIGKILL）调整进程优先级：选中进程后按F7（降低nice值）或F8（提高nice值）追踪进程系统调用：选中进程后按s，启动strace（需要安装strace工具）查看进程打开的文件：选中进程后按l，启动lsof（需要安装lsof工具）搜索功能在htop中，按下/键可以搜索特定进程。输入关键字后，htop会高亮显示匹配的进程。这在系统运行大量进程时特别有用。过滤功能 按下\键可以激活过滤功能，输入过滤条件后，htop只会显示符合条件的进程。例如，输入"apache"将只显示与apache相关的进程。自定义显示列 htop允许你自定义显示哪些进程信息列：按F2进入设置菜单选择"Columns"选项使用空格键选择或取消选择要显示的列F10保存并退出设置自定义配色方案如果你不喜欢默认的颜色方案，可以在设置菜单中进行更改：按F2进入设置菜单选择"Colors"选项选择预设的配色方案或自定义各元素的颜色F10保存并退出设置使用示例场景一：系统资源异常高，定位问题进程 当服务器CPU或内存使用率异常高时，可以通过以下步骤快速定位问题：启动htop，查看顶部的CPU和内存使用情况按F6，选择按CPU%或MEM%排序观察排在顶部的进程，这些通常是资源消耗最大的如果发现异常进程，可以进一步分析或终止它场景二：监控多核CPU的负载均衡情况在多核服务器上，理想情况下工作负载应该均匀分布在各个CPU核心上：启动htop，观察顶部的CPU使用率条检查各个核心的使用率是否平衡如果发现某个核心长期满负荷而其他核心空闲，可能表明应用程序不支持多线程或存在配置问题场景三：内存泄漏排查对于疑似内存泄漏的情况，可以使用htop进行初步排查：启动htop，按F6选择按MEM%排序记录可疑进程的内存使用情况定期观察这些进程的内存使用是否持续增长而不释放如果确认某进程存在内存泄漏，可以重启该进程作为临时解决方案，并进一步分析根本原因
-
-
php容器的时区设置问题 {callout color="#f0ad4e"}背景说明：如今国内开源可用的docker镜像站越发稀少，很多镜像站关闭或不在提供服务。而搭建一个网站只用到少数的几个容器如nginx、php-fpm、mysql，没必要浪费资源买一台香港服务器去拉取这些镜像。解决办法是使用了目前还算稳定的 毫秒镜像 提供的镜像服务。 在1ms.run上搜索php-fpm容器的最新版本时，发现没有官方版本，于是使用了bitnami开源组织上传的镜像bitnami/php-fpm：latest。{/callout}在bitnami提供的php-fpm镜像中，容器使用的是UTC时间，也就是协调世界时（全球时间的基准），但我们使用的CST时区（UTC+8），这里就会出现一个问题：博客的发布时间与我们所处的时区有8小时的差距。因此需要修改php-fpm的默认时区设置。进入php-fpm容器查看时区设置情况#创建一个临时容器 docker run -itd --rm docker.1ms.run/bitnami/php-fpm #进入容器查看时区设置 root@f7f574667670:/app# echo $TZ root@f7f574667670:/app# date Thu Mar 6 01:24:24 UTC 2025 #发现容器使用的是UTC时间，且没有设置TZ环境变量第一个思路，修改compose文件php-fpm容器的环境变量，设置TZ的值为Asia/Shanghaivim compose.yaml …… php8.2: container_name: php8.4 image: docker.1ms.run/bitnami/php-fpm:latest environment: - TZ=Asia/Shanghai volumes: ……为了方便验证，不用每次都去容器里面进行查看时区情况，让deepseek写了一个简单的php脚本，只要浏览器访问这个脚步就可以得到容器的时区信息。<?php // 获取当前时间和时区 $current_time = date('Y-m-d H:i:s'); // 格式化当前时间 $current_timezone = date_default_timezone_get(); // 获取当前时区 // 输出结果 echo "当前时间：$current_time\n"; echo "当前时区：$current_timezone\n"; ?> 修改完配置信息，使用浏览器验证时发现php-fpm返回的仍然是UTC时间，问题出在哪里？再次进入php容器，查看环境变量设置是否生效root@f7f574667670:/app# echo $TZ Asia/Shanghai这里发现我们设置的环境变量是生效了的，但是php-fpm返回的时间却又是UTC的，那么下一步我们就去php的配置文件中查看有没有相关设置。修改php配置，使时区设置生效查看php.ini文件时，可以发现如下默认配置项。[Date]; Defines the default timezone used by the date functions; http://php.net/date.timezone;date.timezone = UTC这里可以看到默认的时区设置，以及这个时区设置被用于date函数。因此这里的设置优先级高，可以影响到php中时间类函数获取的值。#使用php --ini命令可快速获取php配置文件的位置 #查找配置信息中含有timezone字段的配置文件 root@f7f574667670:/app# find / -maxdepth 8 -name '*.conf' -o -name '*.ini' | xargs grep timezone /opt/bitnami/php/etc/php.ini:; Defines the default timezone used by the date functions /opt/bitnami/php/etc/php.ini:; https://php.net/date.timezone /opt/bitnami/php/etc/php.ini:date.timezone = UTC /opt/bitnami/php/lib/php.ini:; Defines the default timezone used by the date functions /opt/bitnami/php/lib/php.ini:; https://php.net/date.timezone /opt/bitnami/php/lib/php.ini:date.timezone = UTC这里发现在php.ini中有一条生效的配置信息：date.timezone = UTC修改这个配置文件，把UTC修改成我们需要的时区。这里需要注意的是，如果直接把UTC改为CST，php会报错。#直接修改为CST sed -i /^date\.timezone/s/UTC/CST/ /opt/bitnami/php/lib/php.ini #让php重新加载配置 kill -USR2 $(pgrep php-fpm) #查看时区信息 php -r 'echo date_default_timezone_get();' PHP Warning: PHP Startup: Invalid date.timezone value 'CST', using 'UTC' instead in Unknown on line 0重新修改配置文件，把CST改为"Asia/Shanghai"sed -i '/^date\.timezone/s/CST/\"Asia\/Shanghai\"/' /opt/bitnami/php/lib/php.ini 或 sed -i /^date\.timezone/s%CST%\"Asia/Shanghai\"% /opt/bitnami/php/lib/php.ini #重新加载配置文件 root@f7f574667670:/app# kill -USR2 $(pgrep php-fpm) root@f7f574667670:/app# php -r 'echo date_default_timezone_get();' Asia/Shanghairoot@f7f574667670:/app# root@f7f574667670:/app# php -r "echo date('Y-m-d H:i:s');" 2025-03-06 10:44:58root@f7f574667670:/app#把php.ini文件拷贝出来，在compose文件中写入映射关系，重启php容器即可。{dotted startColor="#ff6c6c" endColor="#1989fa"/}关于php.ini-production和php.ini-development：这是php给的两个初始配置的模版，区别如下：开发环境：追求调试便利性，牺牲部分安全性。生产环境：追求安全与性能，牺牲调试信息。始终根据实际需求调整配置，两个模板文件只是起点。配置项php.ini-developmentphp.ini-production目标场景本地开发、调试环境线上生产环境错误报告显示所有错误（方便调试）隐藏错误（避免信息泄露）性能优化默认配置，无激进优化启用 opcache 等性能优化日志记录可选开启详细日志强制记录错误到日志文件安全限制较为宽松严格限制（如文件上传、执行权限）主要区别项目参数名称developmentproduction说明zend.exception_ignore_argsOffOn开启后，异常堆栈跟踪中不再显示参数的具体值，仅保留参数的类型和数量zend.exception_string_param_max_len150控制异常堆栈信息中 字符串类型参数的最大显示长度error_reportingE_ALLE_ALL & ~E_DEPRECATED前面报告所有错误，后面忽略部分警告display_errorsOnOff是否直接在页面上显示错误display_startup_errorsOnOff是否显示PHP启动过程中发生的错误mysqlnd.collect_memory_statisticsOnOff启用或禁用统计 MySQL 操作相关的内存使用数据zend.assertions1-1启用或禁用断言注：1 断言生效，检查条件并触发错误（如条件不满足）。0 生成断言代码，但不执行检查（类似注释，无性能损耗）。-1 不生成断言代码（完全忽略 assert()，性能最优，生产环境推荐）。断言（Assertion） 是开发阶段用于验证代码逻辑的调试工具
-
