谁都知道监控系统很重要，但是要自己搭建一套好用的系统却不是一件简单的事情。国内已经有不少厂商提供类似的服务，比如：OneAPM、听云，其原理就是通过在服务器上部署一套探针，把数据汇总上报，但是问题却不像说起来这么简单，我曾经买过国内某个厂商高大上的 APM 服务，谁知道它监控的指标太多了，并且无法自定义，结果导致一上线，系统性能就下降百分之二十，最后无奈只好放弃。我想要的是一种对系统性能影响尽可能小的监控系统，它不需要监控太多指标，只要有 RPS、CPU、内存、响应时间等几个核心数据即可，而Pinba简直就是为此量身打造的：PINBA（PHP Is Not A Bottleneck Anymore）原本是 PHP 专用的，其工作原理大致是：在每个请求处理完成后，PHP 把相关数据通过 UDP 发送给 Pinba 自定义的 MySQL 引擎。因为数据是通过 UDP 传输的，所以对原有系统的性能影响很小。如果非要说说 Pinba 的缺点，那么它没有提供一个官方的 UI 算一个，好在Pinboard弥补了不足：Pinboard说到这，估计大家都迫不及待的想试试 Pinba + Pinboard 了，不过从我的经历来看，想把这套系统跑起来的话需要绕开很多坑，我前前后后搞了五六次才算成功，失败的主要原因在于各个软件更新频率不一样，依赖关系复杂，于是就出现所有软件都装了最新稳定版，但是整个系统 ...继续阅读 (24)

前些天，有朋友问我关于 FIN_WAIT2 的问题：如果主动关闭的一方在进入 FIN_WAIT2 状态后没有收到被动关闭的一方发送的 FIN 包，那么会怎样？让我们热热身，通过一张旧图来回忆一下 TCP 关闭连接时的情况：TCP Close按照正常的状态迁移路径，当 FIN_WAIT2 收到 FIN 包后会迁移到 TIME_WAIT 状态。如果没有收到 FIN 包，那么连接状态会如何迁移，我们不妨测试一下：#!/usr/bin/env python import socket import time s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind(('127.0.0.1', 1234)) s.listen(1) c, _ = s.accept() time.sleep(1000) c.close()如上是用Python实现的一个简单的 server 演示代码，需要注意的是我在 close 前设置了一个巨大的延迟时间，从而达到拖延服务端发出 FIN 包的目的。与之相对应的我们再实现一个简单的 client 演示代码，它没什么可说的，就是连上后直接关闭：#!/usr/bin/env python import socket import time s = socket.socket(socket.A ...继续阅读 (20)

我说的 GCC 版本可不是指的「gcc –version」，而是指的上到 Linux 内核，下到 PHP 之类的软件，是用哪个版本的 GCC 编译的。先看看如何判断 Linux 内核是用什么版本的 GCC 编译的？shell> cat /proc/version ... (gcc version 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) ) ...再看看如何判断 PHP 之类的软件是用什么版本的 GCC 编译的？shell> objdump -s --section .comment /usr/local/bin/php /usr/local/bin/php: file format elf64-x86-64 Contents of section .comment: 0000 4743433a 2028474e 55292034 2e342e37 GCC: (GNU) 4.4.7 0010 20323031 32303331 33202852 65642048 20120313 (Red H 0020 61742034 2e342e37 2d313129 00474343 at 4.4.7-11).GCC 0030 3a202847 4e552920 342e342e 37203230 : ...继续阅读 (19)

很多人感冒发烧的时候，往往会模仿神农氏尝百草的路子：先尝尝抗病毒的药，再试试抗细菌的药，甭管家里有什么药挨个试，什么中药西药，瞎猫总会碰上死耗子，如此做法自然是不可取的，正确的做法应该是去医院验个血，确诊后再对症下药。让我们回想一下我们一般是如何调试程序的：通常是在没有数据的情况下依靠主观臆断来瞎蒙，而不是考虑问题到底是什么引起的！毫无疑问，调优程序性能问题的时候，同样需要对症下药。好消息是Brendan D. Gregg发明了火焰图，可以一针见血的指出程序的性能瓶颈，坏消息是除了OpenResty社区，很少看到还有其他人使用火焰图。常见的火焰图类型有On-CPU，Off-CPU，还有Memory，Hot/Cold，Differential等等。下面给出某个 PHP 程序的 On-CPU 类型的火焰图例子：Flame Graph关于火焰图详细的介绍可以参考Blazing Performance with Flame Graphs，简而言之：整个图形看起来就像一团跳动的火焰，这也正是其名字的由来。燃烧在火苗尖部的部分就是 CPU 这在执行的操作，不过需要说明的是颜色是随机的，本身并没有特殊的含义，纵向表示调用栈的深度，横向表示消耗的时间。因为调用栈在横向会按照字母排序，并且同样的调用栈会做合并，所以一个格子的宽度越大越说明其是瓶颈。综上所述，主要就是看那些比较宽大的火苗，特别留意那些 ...继续阅读 (53)

昨晚和一位读者朋友一起讨论了一个问题：在一台多核 CPU 的 Web 服务器上，存在负载不均衡问题，其中 CPU0 的负载明显高于其它 CPUx，进一步调查表明 PHP-FPM 的嫌疑很大。话说以前我曾经记录过软中断导致过类似的问题，但是本例中可以排除嫌疑。让我们在一台四核服务器上采样分析一下数据确认一下是否存在负载不均衡问题：shell> mpstat -P ALL 1 10 CPU %usr %nice %sys %iowait %irq %soft ... %idle all 17.57 0.03 1.78 0.00 0.35 0.23 ... 80.04 0 43.17 0.00 4.12 0.00 1.41 1.00 ... 50.30 1 9.80 0.00 0.81 0.00 0.00 0.00 ... 89.39 2 9.31 0.00 1.20 0.00 0.00 0.00 ... 89.49 3 7.94 0.10 0.80 0.00 0.00 0.00 ... 91.16如上命令的含义是每秒运行一次 mpstat，一共采样 10 次，可以 ...继续阅读 (36)

MongoDB 之类的 NoSQL 之所以流行，很大程度上取决于相对自由的 schema 设计，不管数据量多大，可以随时在线上环境添加新字段来保存新数据，而这种能力恰恰是传统的关系数据库所欠缺的，不过别担心，传统关系数据库有自己的应对之道。我们今天就讨论一下其中最具代表性的两种方法，看看孰优孰劣。在讨论前，我们不妨虚拟一个业务场景：假设我们要做一个类似汽车之家的产品库，首当其冲的是如何保存汽车的各种属性，比如说：长度、宽度、高度、GPS 导航系统、倒车影像、上坡辅助、陡坡缓降等等，最传统的方法是每一个属性都用一个独立的字段来保存，不过这样有问题：汽车属性有可能非常多，如此一来我们的表需要创建几十甚至上百个字段，而且以后还可能想要不断的添加新字段。最要命的是不同的汽车拥有的属性大不相同，比如有的汽车有 GPS 导航系统、倒车影像，但是却没有上坡辅助、陡坡缓降，如果把这些属性统统作为字段存在的话，那么表就是稀疏的，存在很多空值。传统的 EAV 方法所谓EAV，实际上是 Entity–Attribute–Value 的缩写。它的核心思想是把原本按列保存的数据转换成按行保存。不同的项目设计在表结构上可能会有些许差异，不过核心通常就是 entity，attribute，value 三张表，下面看看采用 EAV 如何解决问题：CREATE TABLE eav_entities ( id ...继续阅读 (41)

几乎每一个 PHP 程序员都发布过代码，可能是通过 ftp 或者 rsync 同步的，也可能是通过 svn 或者 git 更新的。一个活跃的项目可能每天都要发布若干次代码，但是现实却是很少有人注意其中的细节，实际上这里面有好多坑，很可能你就在坑中却浑然不知。一个正确实现的发布系统至少应该支持原子发布。如果说每一个版本都表示一个独立的状态的话，那么在发布期间，任何一次请求只能在单一状态下被执行。如此称之为支持原子发布；反之如果在发布期间，一次请求跨越不同的状态，那么就不能称之为原子发布。我们不妨举个例子来说明一下：假设一次请求需要 include 两个 PHP 文件，分别是 a.php 和 b.php，当 include a.php 完成后，发布代码，接着 include b.php，如果处理不当的话，那么就可能会导致旧版本的 a.php 和新版本的 b.php 同时存在于同一个请求之中，换句话说就是没有实现原子发布。开源世界里有很多不错的发布代码工具，比如 ruby 社区的capistrano，其流程大致就是发布代码到一个全新的目录，然后再软链接到真正的发布目录。. ├── current -> releases/v1 └── releases ├── v1 │   ├── foo.php │   └── bar.php └── v2 ...继续阅读 (38)

说起「Partial Index」，估计很多人没听说过。在PostgreSQL中，它的含义是指：通过查询条件索引选定的行，而不是所有的行。虽然MySQL也有此概念，但是其更接近前缀索引的含义：比如你想索引一个 VARCHAR(255) 的字段，根据数据分布情况，你可以仅索引前面若干个字符，如此通过降低索引体积来达到提升性能的目的。例一：有一个 users 表，里面有一个 mobile 字段，缺省值为 null。用户可以不填写手机号，如果填写，每个手机号只能关联一个用户，怎么办？听起来这就是一个唯一索引，但是直接创建的话肯定会失败，因为字段里有空值，这个问题放到 MySQL 里就无解了，只能通过新建一个 users_mobiles 表来约束唯一性。下面看看在 PostgreSQL 中如何利用 Partial Index 来搞定：sql> CREATE UNIQUE INDEX on users (mobile) WHERE mobile IS NOT NULL;通过在创建索引的时候过滤掉无关的数据，从而实现创建唯一索引的目的。例二：有一个 questions 表，里面有一个 created_at 字段表示创建时间，一个 answer_count 字段表示答案数量，查询不同时间范围里答案数量大于 10 个的问题：sql> SELECT * FROM questio ...继续阅读 (36)

话说从前些天开始，我的某台服务器不时会出现外网访问响应速度变慢的情况，不过内网访问倒是一直正常。因为并不是核心服务器，所以一开始我便忽略了监控报警，但是随着服务器的可用性越来越差，我不得不腾出手来看看到底发生了什么。既然是网络问题，那么就在客户端用「mtr <IP>」检查一下网络情况：mtr既然丢包主要发生在最后一跳，那么就在服务器用「sar -n DEV」检查一下带宽：sar明显可见 TX 流量时不时便会到达一定的高峰，说明服务器在向外发送大量数据，导致触及了带宽阈值，那么到底是什么原因造成的呢？是时候祭出「iptraf」神器了，本例的服务器中，内网正常，其网卡是 eth0；外网异常，其网卡是 eth1：iptraf (General interface statistics)单独监控外网网卡发现大部分流量都集中在 UDP 协议之上：iptraf (Detailed interface statistics)按照端口监控发现流量主要集中在 UDP 的 53 端口上。不过需要说明的是这里的端口既可能是源端口，也可能是目标端口，并且 iptraf 缺省只监控 1024 以下的端口：iptraf (Statistical breakdowns)监控具体的流量包，发现本地端口在不停的往远程的端口发请求：iptraf (IP traffic monnitor)随便提一下，在上面 ...继续阅读 (43)

我已经用了一段时间的 Laravel 框架了，期间遇到了不少问题，有一些调试起来着实不太容易，本文筛选出几个，如果能让大家少走一些弯路，那我就算没白写。报错：「Can’t swap PDO instance while within transaction」通过查询 Laravel 源代码，可以确认异常是在 setPdo 方法中抛出的：<?php public function setPdo($pdo) { if ($this->transactions >= 1) { throw new RuntimeException(" Can't swap PDO instance while within transaction. "); } $this->pdo = $pdo; return $this; } ?>按字面意思理解，出现此错误是因为在开启了事务的情况下，切换了数据库连接。不过有时候，即便代码里没有显式的切换数据库连接，也有可能出现此错误。比如说在执行查询语句出错的时候，系统会通过 tryAgainIfCausedByLostConnection 方法判断问题是不是因为丢失连接导致的，如果是，那么系统会通过 reconnect 方法重新连 ...继续阅读 (30)

TCP 有很多连接状态，每一个都够聊十块钱儿的，比如我们以前讨论过TIME_WAIT和FIN_WAIT1，最近时不时听人提起 CLOSE_WAIT，感觉有必要梳理一下。所谓 CLOSE_WAIT，借用某位大牛的话来说应该倒过来叫做 WAIT_CLOSE，也就是说「等待关闭」，如果你还不理解其含义，可以看看 TCP 关闭连接时的图例：TCP Close不要被图中的 client 和 server 所迷惑，你只要记住：主动关闭的一方发出 FIN 包，被动关闭的一方响应 ACK 包，此时，被动关闭的一方就进入了 CLOSE_WAIT 状态。如果一切正常，稍后被动关闭的一方也会发出 FIN 包，然后迁移到 LAST_ACK 状态。通常，CLOSE_WAIT 状态在服务器停留时间很短，如果你发现大量的 CLOSE_WAIT 状态，那么就意味着被动关闭的一方没有及时发出 FIN 包，一般有如下几种可能：程序问题：代码层面遗漏或者死循环之类的，没有 close 相应的 socket 连接。响应太慢：对方已经 timeout 了，本方还忙于耗时逻辑，导致 close 被延后。BACKLOG 太大：队列堆积严重，导致多余的请求来不及消费就被关闭了。如果遭遇了 CLOSE_WAIT 故障，那么需要立刻通过「netstat」或者「ss」命令来判断 CLOSE_WAIT 连接是哪些进程引起的，如果是我们自 ...继续阅读 (68)

原本我是 MySQL 的忠实粉丝，后来命运使然，接手了一个 PostgreSQL 项目，一边用一边学，遇到了不少问题，本文说说其中的连接池问题。有人曾经问我「为什么 PostgreSQL 没有 MySQL 流行呢？」，我说是因为 PostgreSQL 没有服侍好 PHP。当然话有戏谑的成分在，不过仔细想想也不无道理，开发那些简单的增删改查程序，PHP 和 MySQL 是绝配，而 PHP 和 PostgreSQL 则明显不搭，其中最重要的一点是：PostgreSQL 连接是进程级的，而不是像 MySQL 那样是线程级的，也就是说，当一个请求过来时，PostgreSQL 需要 fork 出一个进程！于是乎，当你使用 PHP 和 PostgreSQL 的双象组合时，数据库连接池是终将面对的一个问题，目前主流的解决方案有Pgpool和PgBouncer，选择哪个好呢？不妨从它们各自的定位来判断，Pgpool 是一个整体解决方案，它不仅实现了连接池，还实现了负载均衡等等高级功能，而 PgBouncer 则仅仅专注于连接池。所以说，如果你除了连接池还需要负载均衡等功能，那么 Pgpool 通常是不错的选择，如果你只想要连接池功能，那么就和我一样使用小而美的 PgBouncer 吧。在安装前需要考虑的到底在哪安装 PgBouncer：Web 服务器还是 DB 服务器？通常安装在 Web 服务器上 ...继续阅读 (28)

如果说学院派的 Java 程序员骨子里都浸淫着学究范儿的话，那么游击队出身的 PHP 程序员则从头到脚洋溢着乡土气息。通常他们不太在意理论，一切以实现为先，虽然这样的做法在项目早期能获得不错的收益，但是随着项目的推进，复杂度的提升，缺乏理论基础的弊端终将显现。好在 PHP 社区没有裹足不前，比如说十几年前 Java 社区中流行的 IoC 概念，最近一两年终于被 PHP 社区所接纳。说起 IoC，其实是Inversion of Control的缩写，翻译成中文叫控制反转，不得不说这个名字起得让人丈二和尚摸不着头脑，实际上简而言之它的意思是说对象之间难免会有各种各样的依赖关系，如果我们的代码直接依赖于具体的实现，那么就是一种强耦合，从而降低了系统的灵活性，为了解耦，我们的代码应该依赖接口，至于具体的实现，则通过第三方注入进去，这里的第三方通常就是我们常说的容器。因为在这个过程中，具体实现的控制权从我们的代码转移到了容器，所以称之为控制反转。如果你看过 Martin Fowler 关于 IoC 的介绍，那么你就会知道 IoC 是一个宽泛的概念，具体点儿说有两种不同的实现方式，分别是：Dependency Injection和Service Locator。现在很多 PHP 框架都实现了容器，比如Phalcon(1)，Yii(1)(2)，Laravel(1)(2) 等。至于 Depende ...继续阅读 (45)

早些年，我特别喜欢下围棋，每天都会下几盘。那时候日本围棋不仅高手林立，而且风格迥异，比如：小林光一的地铁流，武宫正树的宇宙流等等，不过我最喜欢的棋手当属大竹英雄，他下棋时追求美感，如果棋形不漂亮，那么他宁可认输也绝不玷污棋盘。后来，我成为了一名程序员，每天都要写不少代码，可惜写了不少丑陋的代码，本文筛选了几个例子，希望大家看过之后都能写出更漂亮的代码来。在聊之前，我们不妨想想割裂到底是什么意思。其实所谓割裂，说白了就是指把原本应该在一起的东西分开了，比如两地分居的夫妻，亦或者留守儿童和父母。普通的语言描述总是苍白无力的，让我们看看有割裂感的代码到底长啥样：<?php $i = 0; while ($i <= 10) { echo $i; $i++; } ?>代码似乎很常见，如果你没有意识到割裂感的存在，请看看下面的改进版：<?php for ($i = 0; $i <= 10; $i++) { echo $i; } ?>怎么样？理解了吧！在我们的努力下，变量「i」的三口之家终于团聚了！当然，这只是命令式语言的写法，如果你想更酷一点，还可以用函数式语言的写法：<?php array_map(function($i) { echo $i; }, range(0, 10)); ?>接着看另一个例子，如果 ...继续阅读 (31)

早些年，如果你知道有个 strace 命令，就很牛了，而现在大家基本都知道 strace 了，如果你遇到性能问题求助别人，十有八九会建议你用 strace 挂上去看看，不过当你挂上去了，看着满屏翻滚的字符，却十有八九看不出个所以然。本文通过一个简单的案例，向你展示一下在用 strace 诊断问题时的一些套路。如下真实案例，如有雷同，实属必然！让我们看一台高负载服务器的 top 结果：top技巧：运行 top 时，按「1」打开 CPU 列表，按「shift+p」以 CPU 排序。在本例中大家很容易发现 CPU 主要是被若干个 PHP 进程占用了，同时 PHP 进程占用的比较多的内存，不过系统内存尚有结余，SWAP 也不严重，这并不是问题主因。不过在 CPU 列表中能看到 CPU 主要消耗在内核态「sy」，而不是用户态「us」，和我们的经验不符。Linux 操作系统有很多用来跟踪程序行为的工具，内核态的函数调用跟踪用「strace」，用户态的函数调用跟踪用「ltrace」，所以这里我们应该用「strace」：shell> strace -p <PID>不过如果直接用 strace 跟踪某个进程的话，那么等待你的往往是满屏翻滚的字符，想从这里看出问题的症结并不是一件容易的事情，好在 strace  可以按操作汇总时间：shell> strace -cp <P ...继续阅读 (39)

绝大多数程序员都听说过Unicode和UTF-8，但是清楚它们之间关系的人就不多了，关于这个问题，与其苍白的陈述它们的概念，不如举例子说明来得自然。我前些天碰到一个需求：随机生成几个汉字。原本我便对编码之类的问题发怵，所以完全搞不清楚状况，无奈之下我便上网搜索了一个 PHP 版本的实现：<?php $zh = ''; for($i = 0; $i < 3; $i++) { $zh .= '&#'. rand(19968, 40869) . ';'; } echo mb_convert_encoding($zh, 'UTF-8', 'HTML-ENTITIES'); ?>不过代码里的「19968」和「40869」是什么玩意？这又牵扯到 Unicode code points，为了更好的说明问题，我们需要把如上十进制转换成十六进制：shell> php -r 'echo dechex(19968);' 4e00 shell> php -r 'echo dechex(40908);' 9fcc在 Unicode 官方网站，我们能查到Unihan Grid Index，其中 CJK Unified Ideographs 部分包含了大部分的汉字，其 code points 恰恰是从 U+4E00 到 U+9FCC！单单上面一个例子还不足 ...继续阅读 (26)

在 Redis 里，所谓SETNX，是「SETifNot eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果，不过老实说，SETNX 有陷阱！比如说：某个查询数据库的接口，因为调用量比较大，所以加了缓存，并设定缓存过期后刷新，问题是当并发量比较大的时候，如果没有锁机制，那么缓存过期的瞬间，大量并发请求会穿透缓存直接查询数据库，造成雪崩效应，如果有锁机制，那么就可以控制只有一个请求去更新缓存，其它的请求视情况要么等待，要么使用过期的缓存。下面以目前 PHP 社区里最流行的PHPRedis扩展为例，实现一段演示代码：<?php $ok = $redis->setNX($key, $value); if ($ok) { $cache->update(); $redis->del($key); } ?>缓存过期时，通过 SetNX  获取锁，如果成功了，那么更新缓存，然后删除锁。看上去逻辑非常简单，可惜有问题：如果请求执行因为某些原因意外退出了，导致创建了锁但是没有删除锁，那么这个锁将一直存在，以至于以后缓存再也得不到更新。于是乎我们需要给锁加一个过期时间以防不测：<?php $redis->multi(); $redis->setNX($key, $value); $redis->ex ...继续阅读 (37)

昨天，项目的 ElasticSearch 服务挂了，我说的挂可不是进程没了，因为有 Supervisor 保护，而是服务不可用了。以前曾经出现过一次因为 ES_HEAP_SIZE 设置不当导致的服务不可用故障，于是我惯性的判断应该还是 ES_HEAP_SIZE 的问题，不过登录服务器后发现日志里显示大量的「Too many open files」错误信息。那么 ElasticSearch 设置的最大文件数到底是多少呢？可以通过proc 确认：shell> cat /proc//limits结果是「4096」，我们还可以进一步看看 ElasticSearch 打开的都是什么东西：shell> ls /proc//fd问题看上去非常简单，只要加大相应的配置项应该就可以了。此配置在 ElasticSearch 里叫做 MAX_OPEN_FILES，可惜配置后发现无效。按我的经验，通常此类问题多半是由于操作系统限制所致，可是检查结果一切正常：shell> cat /etc/security/limits.conf * soft nofile 65535 * hard nofile 65535需要说明的是新版 CentOS 里有一个额外的配置文件，用来限制用户打开的文件数：shell> /etc/security/limits.d/90-nproc.conf * sof ...继续阅读 (42)

因为我崇尚简单，所以我憎恨一切所谓的「重量级」框架，比如「Laravel」，有时候这种憎恨甚至到了偏执的程度，以至于如果我看到简历里写着诸如「精通 Laravel」之类的话，那么便会毫不犹豫的 PASS 掉候选人。不过现在我承认有点喜欢「Laravel」了，虽然性能依然是无法回避的短板，但是又有几个网站能触及其性能瓶颈呢？而它丰富的组件则实实在在的节约了开发者大把的时间，比如本文要说的队列。在 Laravel 里调用队列功能是非常简单的一件事情，详细介绍参考官方文档：php \Queue::pushOn('mail', new \App\Commands\Mail($data)); ?队列包含了多种驱动：比如 sync、database、redis、beanstalk 等等。其中 sync 乍一看会觉得很奇怪，不过实际上它在开发测试阶段超级方便，此外 database、redis 等方案更像是一种模拟，所以说 beanstalk 是目前最合适的选择。当然，beanstalk同nsq之类的队列相比，功能上明显差一个档次，但是，beanstalk 贵在简单易用。Laravel 队列的消费者有两种启动方式，分别是：queue:listen 和 queue:work，我建议你彻底忘记第一种方式，我甚至不理解它为什么存在，因为它不仅低效，而且可能会导致一些莫名其妙的问题，具体可以参考：一 ...继续阅读 (64)

不管你用什么编程语言，都会面临如何处理错误日志的问题。很多程序员对错误日志放任自流，直到出现故障了才追悔莫及，如果问我怎么办，我会推荐Sentry！Sentry 是一个错误记录和聚合的平台，只要看看它漂亮的界面就会喜欢上它：sentry关于如何安装 Sentry，官方文档里已经给出了详细的说明，建议大家仔细阅读，一般通过Virtualenv来安装 Sentry，具体可以参考：学习搭建Python环境。提醒：我在安装 7.5 的时候，测试有循环重定向，如果你也是可以安装 7.4：pip install sentry==7.4.3安装完毕后，假设我们要监控 PHP 错误日志，那么通常是在我们的业务代码里嵌入官方的PHP SDK，不过这样肯定会影响到性能，好在我们可以通过错误日志曲线救国，只要定期扫描错误日志，把新生成的数据发送给 Sentry 就好了。如何才能发现新生成的数据呢？需要记录扫描到了哪个位置，可以通过 Logcheck 中提供的 logtail 或者 logtail2 来实现这个功能，至于它俩的区别，可以参见 man 文档，简单点儿说，如果日志被 rotate 的话，logtail 可能会丢失旧日志中的数据，而 logtail2 不会。php require_once __DIR__ . '/raven-php/lib/Raven/Autoloader.php'; Ra ...继续阅读 (65)

一台服务器报警了，内存占用过高，奇怪的是集群里其它的服务器都没问题。不过从以往的经验来看：每一个匪夷所思的问题背后，都隐藏着一个啼笑皆非的答案。首先通过「free -m」确认一下内存情况，发现用掉了 6893M，还剩 976M：free然后通过「top」查看一下哪些进程占用内存多，通过「shift + m」按内存排序：top虽然通过 free 命令我们能确认系统可用内存不足，但是通过 top 命令我们却没有发现有内存占用大户的进程，那么内存到底都去哪里了呢？开头我们提到过，集群里只有一台服务器有问题，其它服务器皆正常，于是我们比较了一下问题服务器和正常服务器的进程列表，结果发现问题服务器多了几个进程：/usr/local/bin/php artisan queue:listen/usr/local/bin/php artisan queue:work经过确认，它们是 Laravel 队列，虽然直觉告诉我问题与其有关联，但是进程本身并没有占用多少内存，在不能立刻确诊原因的情况下，我们用排除法把队列换到另外一台正常的服务器上看看会不会重现问题，过了一会，果然再次出现同样问题。既然 free，top 之类的命令不能确认内存的去向，那么我们不妨看看「meminfo」：meminfo如上图所示，大量内存被 Slab 消耗了，更进一步讲是被 SReclaimable 消耗了，也就是说内存被一些 ...继续阅读 (45)

实际上本次故障的素材来自于朋友的朋友，虽然我并不是故障的亲身经历者，但即便只是作为旁观者，依然感觉有所收获，于是乎记录下来以馈读者。故障的来龙去脉大致是这样的：在一个月黑风高的晚上，苦逼的程序员被一阵急促的报警短信声惊醒，原来是数据库的某个表出问题了，虽然查询操作都正常，但创建操作却都失败了，经过调试，发现原因是表被插入了一行问题数据，其自增字段的值被显式的设置为整型的最大值，导致后续缺省插入的数据不能获取到一个合法的主键值。我们不妨创建一个测试表说明问题：CREATE TABLE IF NOT EXISTS `test` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(100) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB;然后插入一行问题数据：INSERT INTO test (id, name) VALUES (2147483647, 'x');结果导致不能执行正常的插入语句：INSERT INTO test (name) VALUES ('y');此时数据库会报错：#1062 – Duplicate entry ‘2147483647’ for key ‘PRIMARY’换句话说，InnoDB 表类 ...继续阅读 (61)

我的日常工作有很大一部分比重是处理各种网络问题。很多时候，面对突发故障，完全搞不清楚缘由，此时，一个完善的监控系统能起到事半功倍的效果。一个好消息是「netstat -s」里的各种计数器包含了很多有用的信息；一个坏消息是计数器记录的通常都是一些硕大无比的绝对值，不够直观。以前，我写过一篇的文章来介绍如何监控相关数据，但写得并不完善；最近，浏览文章时偶然发现一个工具，可以很方便的实时查询计数器相对值的变化情况，可惜不能方便的对接到监控系统里。既然现有的轮子都不太合适我的需求，那么我便有了充足的理由去重新造一个。解决问题前需要摸摸底，如下可见命令「netstat -s」的结果是一个层次化的结构：netstat -s我们需要把它转换成更利于使用的规范化结构。翠花，上代码：php function one_dimensional_array($values, $prefix = 'netstat') { $result = array(); foreach ($values as $key =$value) { $key = $prefix . '.' . $key; if (is_string($value)) { $result[$key] = $value; } else { ...继续阅读 (46)

如果 MySQL 数据库比较大的话，我们很容易就能查出是哪些表占用的空间；不过如果 Redis 内存比较大的话，我们就不太容易查出是哪些（种）键占用的空间了。有一些工具能够提供必要的帮助，比如redis-rdb-tools可以直接分析 RDB 文件来生成报告，可惜它不能百分百实现我的需求，而我也不想在它的基础上二次开发。实际上开发一个专用工具非常简单，利用SCAN和DEBUG等命令，没多少行代码就能实现：php $patterns = array( 'foo:.+', 'bar:.+', '.+', ); $redis = new Redis(); $redis-setOption(Redis::OPT_SCAN, Redis::SCAN_RETRY); $result = array_fill_keys($patterns, 0); while ($keys = $redis->scan($it, $match = '*', $count = 1000)) { foreach ($keys as $key) { foreach ($patterns as $pattern) { if (preg_match("/^{$pattern}$/", $key)) { if ( ...继续阅读 (36)

有个老项目，通过 Squid 提供文件下载功能，利用delay_parameters实现带宽控制，问题是我玩不转 Squid，于是盘算着是不是能在 Nginx 里找到类似的功能。好消息是 Nginx 提供了limit_rate和limit_rate_after，举个例子来说明一下：location /download/ { limit_rate_after 500k; limit_rate 50k; }大概意思是：用户下载达到 500k 后，便控制其速度在 50k 以内。坏消息是此控制是针对单个连接而言的。换言之，只能限制单个连接的带宽，不能限制总带宽。不过使用limit_conn模块的话，可以在一定程度上缓解问题：limit_conn_zone $server_name zone=servers:10m; server { location /download/ { limit_conn servers 1000; limit_rate_after 500k; limit_rate 50k; } }通过 limit_conn 限制了并发连接数，于是也就限制了总带宽。可惜这个解决方式并不完美，大家可以设想如下的例子：1000 个用户能够同时以 50k 的速度下载；那么在总带宽不变的情况下，2000 个 ...继续阅读 (27)

有时候，进程突然终止服务，可能是没有资源了，也可能是意外，比如说：因为 OOM 被杀；或者由于 BUG 导致崩溃；亦或者误操作等等，此时，我们需要重新启动进程。实际上，Linux 本身的初始化系统能实现简单的功能，无论是老牌的 SysVinit，还是新潮的Upstart或者Systemd均可，但它们并不适合处理一些复杂的情况，比如说：CPU 占用超过多少就重启；或者同时管理 100 个 PHP 实现的 Worker 进程等等，如果你有类似的需求，那么可以考虑试试Monit和Supervisor，相信会有不一样的感受。让我们看看Monit的用法，假设我们要监控 Nginx 进程，一旦其 CPU 使用率连续 5 次轮询周期里均超过 50% 的话，就重启进程，此时就可以按照如下方式设置：check process nginx with pidfile /var/run/nginx.pid start program = "/etc/init.d/nginx start" stop program = "/etc/init.d/nginx stop" if cpu is greater than 50% for 5 cycles then restartMonit 根据 pidfile 轮询对应的进程是否健在，满足条件就执行 start/stop 等操作。如果进程 ...继续阅读 (28)

偶然间，我发现Graphite显示服务器网卡流量呈锯齿状，于是查了一下 Nginx 日志，发现有人在周期性抓我们的接口数据。我这爆脾气自然不能容忍这种行径。简单分析一下访问日志，很容易就能拿到了可疑的 IP 段，直接用iptables封杀：shell> iptables -A INPUT -s x.y.z.0/24 -j DROP本以为世界会就此清净，可没想到一点儿用都没有。莫非小偷已经突破锁头的限制？不能够啊！直觉告诉我问题应该和LVS有关，可惜我对 LVS 的了解极其匮乏，唯一知道的线索就是项目用的是FULLNAT模式，那就以此为切入点开始挖掘：LVS FULLNAT所谓 FULLNAT 模式，是指当用户请求经由 LVS 转发给 RS 服务器的时候，其来源 IP 会从用户 IP 改成 LVS 内网 IP，目标 IP 会从 LVS 的 VIP 改成 RS 服务器的 IP；当 RS 服务器生成响应数据经由 LVS 返回给用户的时候，其来源 IP 会从 RS 服务器 IP 改成 LVS 的 VIP，目标 IP 会从 LVS 内网 IP 改成用户 IP。说明：关于 LVS 更详细的介绍请参考「从一个开发的角度看负载均衡和LVS」一文。对于 RS 服务器而言，实际上它看到的是 LVS。可我们明明在 Nginx 日志里看到了客户端的 IP，而不是 LVS 的 IP，这又是什么原因呢？原来 ...继续阅读 (42)

运营反馈 Nginx 报 400 错误，具体点说：Request Header Or Cookie Too Large。其实随便搜搜就知道可以通过加大client_header_buffer_size和large_client_header_buffers来解决问题，不过这里面有一些细节值得讨论，正所谓：知其然，知其所以然。首先，让我们想想为何 Nginx 不能用一个指令来搞定问题，而要用两个指令？为了搞清楚这个问题，我们不妨先看看官方文档的描述：client_header_buffer_size: Sets buffer size for reading client request header. For most requests, a buffer of 1K bytes is enough. However, if a request includes long cookies, or comes from a WAP client, it may not fit into 1K. If a request line or a request header field does not fit into this buffer then larger buffers, configured by the large_client_header_buffers direct ...继续阅读 (30)

讲 PHP 优化的文章往往都是教大家如何编写高效的代码，本文打算从另一个角度来讨论问题，教大家如何配置高效的环境，如此同样能够达到优化的目的。pool一个让人沮丧的消息是绝大多数 PHP 程序员都忽视了池的价值。这里所说的池可不是指数据库连接池之类的东西，而是指进程池，PHP 允许同时启动多个池，每个池使用不同的配置，各个池之间尊重彼此的主权领土完整，互不干涉内政。pool有什么好处呢？默认情况下，PHP 只启用了一个池，所有请求均在这个池中执行。一旦某些请求出现拥堵之类的情况，那么很可能会连累整个池出现火烧赤壁的结局；如果启用多个池，那么可以把请求分门别类放到不同的池中执行，此时如果某些请求出现拥堵之类的情况，那么只会影响自己所在的池，从而控制故障的波及范围。listen虽然 Nginx 和 PHP 可以部署在不同的服务器上，但是实际应用中，多数人都习惯把它们部署在同一台服务器上，如此就有两个选择：一个是 TCP，另一个是 Unix Socket。listen和 TCP 比较，Unix Socket 省略了一些诸如 TCP 三次握手之类的环节，所以相对更高效，不过需要注意的是，在使用 Unix Socket 时，因为没有 TCP 对应的可靠性保证机制，所以最好把 backlog 和 somaxconn 设置大些，否则面对高并发时会不稳定。pm进程管理有动态和静态之分。动态模式一般 ...继续阅读 (26)

说起 Profiler，老派的 PHP 程序员会选XDebug，新派的 PHP 程序员会选Xhprof，不过我们公司的服务器上都没装，于是我写了这个「Poor Man PHP Profiler」。既然不用 XDebug 和 Xhprof，我们就要自己找 Profiler 的数据源才行。好在 PHP 本身支持慢日志，而且里面包含了调用栈信息，还包含了文件路径和具体的行号：Slow理论上不用写什么工具，把这个日志从前到后看一遍就能发现系统哪里慢，但我们人穷志不短，能通过工具提升一点效率总是好的。工具写起来其实很简单，大概思路：扫描日志，把数据汇总，看看哪一个文件的哪一行出现的次数多，八成就是短板所在（当然要除去一些公共的入口文件）。下面就是源代码：#!/bin/bash usage() { echo "Usage: $0 --log=" } eval set -- $( getopt -q -o "h" -l "context:,log:,help" -- "$@" ) while true; do case "$1" in --context) CONTEXT=$2; shift 2;; --log) LOG=$2; shift 2;; -h|--help) usage; exit ...继续阅读 (42)