共 9 篇相关文章
作者将用了三年的 WordPress 博客迁移到了 Octopress。主要动机是 WordPress 太过臃肿，仅几个 PHP-FPM 进程和 MySQL 就占用了约 400MB 内存，对于访问量不高的博客来说资源消耗很不划算。Octopress 作为一个静态发布系统，以其配置简单、原生支持 Markdown 语法、模板美观等优点，迅速吸引了作者。 迁移过程主要参考了 Octopress 官方文档和几篇社区文章，几个小时内便完成了数据导出、导入和部分文章的润色，一个全新的静态博客就基本可用。不过作者也指出了 Octopress 不够完美的地方，例如插件生态较少，甚至缺少标签云这类基础功能。在迁移中还遇到了一个具体坑：更换正式域名后，生成的静态页面和 RSS 中的 URL 会新旧随机变化，导致 IFTTT 误认为文章全部更新而向 Twitter 发送了大量重复信息。清除缓存目录后问题得以解决。 总的来说，Octopress 虽不完美，但已能很好地满足作者对轻量、高效博客系统的需求。
这篇讲的是一次线上502故障的深度排查。作者从php-fpm进程数异常飙升入手，通过`pstack`命令分析进程堆栈，发现几乎所有进程都卡在申请APC互斥锁上，指向了死锁。 根因的追查过程很有价值。通过GDB调试，他们定位到互斥锁被一个已不存在的进程（11274）持有。结合php-fpm日志，最终确认是该进程因`hsf`扩展的内存错误（SIGSEGV）而异常退出，退出时未能释放它持有的APC锁，从而导致了整个进程池的级联阻塞。 解决思路清晰：一是彻底的方案，即根据APC维护者建议迁移到不再有此风险的`opcache`；二是针对性修复，参考PHP官方bug报告修改APC源码，在进程异常退出时强制释放锁。文章完整展示了一个由扩展缺陷引发的内存级死锁案例及其分析路径。
这篇讲的是，作者在配置Nginx的fastcgi_cache模块时，明明参数都设对了，缓存却一直不生效、状态始终是MISS的诡异经历。通过strace工具抓包后，他发现是Discuz论坛程序默认返回的 `Cache-Control: no-cache` 响应头，直接导致Nginx放弃了缓存。 作者没有停留在表面，而是深入到Nginx源码层面，找到了关键的判断逻辑。他总结出：当fastcgi响应头中包含 `Set-Cookie`、`Expires` 时间过早或 `Cache-Control` 指向不缓存时，即使配置了cache，Nginx也会直接跳过。文章清晰地展示了从“配置无误却不生效”到“抓包定位干扰源”，再到“查阅源码验证规则”的完整排查链路。 对于实际运维或开发人员，这提醒我们：缓存是一个“端到端”的决策过程，上游应用的“不缓存”响应头拥有最高优先级。文末附带的Nginx配置示例和缓存状态头调试方法，也为快速定位类似问题提供了实用工具。
这篇讲的是如何解决高并发下PHP服务器因频繁创建TCP短连接导致的端口耗尽问题。作者从观察到的真实案例切入——服务器因大量TIME_WAIT状态堆积，耗尽了可用端口，导致新建连接失败。常见的“缩短2MSL时间”的方案治标不治本，因此他引导读者思考更优的解法。 文章核心对比了Nginx与PHP-FPM之间的两种通信方式：默认的TCP socket和Unix Domain Socket（UDS）。作者结合一个WebGame的架构实例指出，当Nginx与PHP-FPM部署在同一台服务器时，使用TCP socket（尤其是短连接模式）会因经过完整的网络协议栈而产生不必要的系统开销，并引发上述的端口问题。相比之下，Unix Domain Socket绕过了TCP/IP层，直接在内核中通过文件套接字通信，大幅降低了连接建立与销毁的开销，从根本上避免了端口竞争。 文章最终给出的结论很明确：对于同机部署的Nginx与PHP-FPM，切换到Unix Domain Socket通常是更优的选择，它能提升效率并彻底解决因短连接导致的资源瓶颈。这对运维和后端开发人员优化本地服务通信有直接的参考价值。
这篇讲的是许多PHP网站默认会在响应头中暴露版本信息，比如`X-Powered-By: PHP/5.3.3`，这会带来不容忽视的安全风险。问题的根源在于PHP的默认配置，而隐患在于，这相当于向潜在攻击者“亮了底牌”，尤其是当使用存在已知漏洞的旧版本时。黑客可以利用这些公开信息进行批量扫描和针对性攻击，例如利用曾经流行的hash冲突漏洞入侵服务器。 解决方案并不复杂，只需在配置文件中调整一行设置或修改代码，就能移除这个头信息，让服务器在“隐蔽模式”下运行。文章的核心价值在于，它指出了一个常被开发者忽视的配置细节，并强调了这种主动的信息隐藏是构建纵深防御体系中简单而有效的一环。通过这样一个小调整，可以显著增加攻击者收集情报的难度，提升网站的基础安全水位。
这篇讲的是如何用一个轻量脚本解决服务器因swap耗尽而无响应的棘手问题。作者的实际困扰是，一台服务器上运行着一个历史遗留的、效率低下的PHP扩展，它不断吞噬内存导致swap扇区被占满，进而引发服务中断。由于暂时无法替换该扩展，作者采取了务实的“止血”方案：编写一个监控脚本，通过`crontab`每两小时执行一次，自动检测swap使用情况。一旦发现异常，脚本会尝试重启`php5-fpm`服务（只需替换文中对应命令即可），从而释放内存、恢复系统响应。这个方案的核心在于，它巧妙地在应用层（PHP扩展）无法根治的情况下，于系统层找到了一个自动化的、及时的恢复机制，让服务器重获平静，也终结了恼人的报警短信。对于同样受困于类似问题且需要临时缓解方案的运维人员，这个思路提供了一个直接可用的实践参考。
这篇讲的是在Linode VPS的CentOS系统上，通过yum工具搭建Web服务器环境的实战过程。作者从零开始，详细记录了nginx、PHP-FPM、eAccelerator缓存加速器以及MySQL这四个核心组件的安装与配置步骤。 整个过程体现了在特定发行版（CentOS）和云主机（Linode）环境下的典型配置思路。重点在于如何利用yum包管理器来简化安装，并协调这些服务之间的关系，比如让nginx通过PHP-FPM来处理动态请求，以及启用eAccelerator来提升PHP执行性能。文章不仅给出了操作流程，也隐含了对技术选型的思考——为什么选择这套特定的组合（nginx的高性能、PHP-FPM的进程管理、eAccelerator的缓存能力）来构建一个高效稳定的服务器环境。 最终，作者为我们呈现了一个可直接用于生产或学习参考的、配置完整的Web环境搭建范本。
这篇讲的是PHP-FPM 0.6版本编译时容易踩的坑。作者指出，虽然php-fpm 0.6早已发布，并且在应对如fix_pathinfo这类漏洞时比0.5系列更有优势，但不少开发者可能仍停留在旧版本。文章从实际编译经验出发，提醒大家升级到0.6时需要留意的特定问题。 具体来说，编译过程中可能会遇到配置参数的变化、依赖库版本不匹配，或是与现有PHP扩展的兼容性问题。作者通过梳理这些常见的“坑点”，帮助读者提前规避，确保平滑升级。对于仍在使用PHP-FPM 0.5，或计划尝试新版本的运维和开发人员来说，这些细节经验可以避免不必要的排错时间。
这篇讲的是一个挺特殊的部署场景：多个Nginx实例监听不同端口，但背后只跑一个PHP-FPM进程池。这在常规的“一对一”架构里不常见，通常是为了满足一些定制化的流量管理或资源隔离需求。 文章直接切入这种“变态需求”的背景，核心方案围绕FastCGI配置展开。作者解释了如何让不同的Nginx服务器都能正确地将PHP请求转发到同一个PHP-FPM后端，并且保证会话（session）等状态的一致性。关键点在于PHP-FPM的监听地址与端口配置、Nginx中fastcgi_pass指令的指向，以及处理好可能涉及的路径和用户权限问题。 这种配置最大的好处是减少了PHP-FPM的进程数量，节省内存资源，同时方便统一管理PHP运行时环境。对于需要在一个服务器上跑多个站点或服务，但PHP配置要求完全相同的场景，这个方法提供了清晰的实现思路。
