Category Archives: 经验分享

Nginx+Tomcat偶现502分析

问题

业务为了负载均衡，前面放了个 Nginx，但最近 502 报警有点频繁，影响了 SLA，因此对这个问题做了较深入的研究。

502 Bad Gateway

简单来说就是 Nginx 找不到一个可用的 upstream，可能的原因有：

  1. 压根是配置错误
  2. 连接 upstream server 发生错误/超时
  3. upstream server 到了处理瓶颈

还有一个重点是轮询了 upstream server 后任然没有一个可用的。但是不管什么原因，都能在 Nginx 的 error log 中找到报错详情。

upstream prematurely closed connection

在 Nginx 中找到错误日志（开了 debug）：

看了下 Nginx 代码，发现是 c->recv(); 读到的内容为 0，日志中也有显示 recv: fd:65 0 of 4096，说明没有获取到 response

同时也查了 Tomcat access 日志，请求还没到 Tomcat。看情况就像日志里面说的，连接被断掉了。

一开始怀疑是网络原因导致连接断掉了，但出现较频繁，期间内网也无网络故障，应该和网络无关。

再看日志发现报错前后有很多 keepalive 信息，尝试关掉 keepalive，502 就没了，但这会对性能有一定影响，感觉有点因噎废食了，还得继续研究。

keepalive

HTTP 持久连接（HTTP persistent connection，也称作 HTTP keep-alive 或 HTTP connection reuse）是使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，而不是为每一个新的请求/应答打开新的连接的方法。

一般 Nginx 会配置 keepalive 以提高性能：

Syntax: keepalive connections;

Activates the cache for connections to upstream servers.

The connections parameter sets the maximum number of idle keepalive connections to upstream servers that are preserved in the cache of each worker process. When this number is exceeded, the least recently used connections are closed.

可以配置每个 worker 对 upstream servers 最大长连接数量。同时这个长连接受 keepalive_requests（默认100） 和 keepalive_timeout（默认60s）配置的影响。

但 keepalive 也有缺陷，会加重 webserver 的负担，因为需要绑定一定数量的线程或者进程来维持长链接。注意 keepalive 并没有连接复用（即同一时间窗口不能处理多个请求，这个在 HTTP/2 中才实现），仅节省了新建/关闭连接的开销，类似连接池了。所以 webserver 一般都有类似 nginx 的 keepalive_requests、keepalive_timeout 配置，让空闲的连接断掉。

查看了 upstream(tomcat) 配置的 timeout 是20s，lighttpd 的 requests 是16，timeout 是 5s，都远小于 nginx 的配置。

原因就清楚了，upstream servers 先断了 keepalive 的长连接，但 nginx 仍使用了这个已经断掉的连接。

至于 nginx 为什么不主动检测一下连接是否可用呢？猜测应该是性能原因，一直检查连接池中的连接是否可用没必要，keepalive 协议本身也没业务心跳啥的。PS：商业版的 ngx_http_upstream_hc_module 可以主动监测（世界加钱可及）。

proxy_next_upstream

那么 Nginx 如何保证高可用呢？答案是重试。这就涉及另一个重要配置 proxy_next_upstream，在什么情况下进行重试，默认为 error timeout。按理说我们这个场景应该会重试，但没有重试。这是因为 Nginx 较新版本（1.9.13）多了个 non_idempotent 配置，默认 POST, LOCK, PATCH 等请求不重试，因为这些操作是非幂等操作，会对服务端数据造成影响（比如发消息接口，重试可能会重复发消息）。日志中也发现 502 的全都是 POST 请求。

要完全解决这个问题就需要对 proxy_next_upstream 配置簇深入看看，我们先做个测试。 Continue Reading...

phpMyAdmin浏览数据页面卡死

我们使用phpMyAdmin经常是一进去就直接展开数据库，点击表名查看数据，这样可以清楚的了解表的结构方便写 SQL。默认情况下是显示 25 条数据，即使有几亿行也很快。

但最近我换了一个 read 账号登录，点击表名的时候直接卡死了

应该是查询卡住了，命令行连上数据库，show full processlist发现有个查询确实卡住了：

一开始只关注到状态是`Creating Sort Index`，再结合使用 write 账号登录打开却很快的现象，认为是 read 账号没有 create 权限，导致卡着了（没有权限的话应该是直接报错的）。但是查了下 read 账号其实给的就是全部权限，一度陷入了僵局。

调整心态，回到原点，还是从「使用 write 账号登录打开却很快」的现象出发，查看日志，发现 write 账号进入的话点击表名浏览数据使用的 SQL 没有`ORDER BY`，那就是自动加的，查了下，phpMyAdmin 会自动保存上一次对字段排序的操作，再次操作字段能取消排序，但问题是我现在已经无法进入浏览页面了。

那考虑是不是能在哪里设置，关闭这个。页面上有个浏览模式设置，但这个试了下好像没啥用。

还是看下官方文档吧，找到了设置项，需要把`$cfg['Servers'][$i]['table_uiprefs']`和`$cfg['RememberSorting']`设置为false。这个功能还是好的，但在多人使用同一账号，数据量又比较大的情况下，还是关闭比较好，关闭也不影响排序功能，只是排序的操作不会保存下来。

Since release 3.5.0 phpMyAdmin can be configured to remember several things (sorted column $cfg['RememberSorting'], column order, and column visibility from a database table) for browsing tables. Without configuring the storage, these features still can be used, but the values will disappear after you logout.

然后还得把已经保存的设置项清除掉，位置在数据库：phpmyadmin（默认）表：pma__table_uiprefs，把这个表清空即可又回到之前丝滑的感觉了。

参考资料

https://stackoverflow.com/questions/33809816/phpmyadmin-automatically-adding-order-by-to-browse

https://docs.phpmyadmin.net/en/latest/config.html#cfg_Servers_table_uiprefs

tomcat设置remote JVM debug后stop失败

最近突然出现执行 tomcat/bin/shutdown.sh 停止 tomcat 失败的情况，报错如下：

看了一下 catalina.sh: line 365 就是 stop 那里执行失败了，然后调用系统的 kill -15 杀死进程

再仔细看看报错，发现有端口被占用、`dt_socket failed to initialize` 等提示，觉得应该是加了 debug 命令的原因，去掉就好了。

但这个感觉也不太好，不能因噎废食呀。搜了下相关情况，发现是 JAVA_OPTS 用的不对，应该用 CATALINA_OPTS，因为 CATALINA_OPTS 变量在 stop 的时候不会被使用（如上图）。

所以最优的做法是使用 CATALINA_OPTS 变量设置 remote debug 相关参数。

 

参考资料

解决tomcat shutdown时的地址被占用问题，https://my.oschina.net/u/1770666/blog/370620

https://stackoverflow.com/questions/11222365/catalina-opts-vs-java-opts-what-is-the-difference

WordPress通用优化策略及常用插件推荐

WordPress 安装很方便，可以说是开箱即用。但是随着文章增多，访问量增大，会发现 WordPress 很“慢”。这是 WordPress 本身的 PHP 运行机制导致的，每篇文章都要去数据库读取，而且 WordPress 为了支持各种功能，现在已经非常臃肿，每次请求都要加载很多东西。但正是 WordPress 的功能强大，让我们也能很方便的做各种优化。

0x1 使用最新版本的 PHP 和 MySQL

毫无疑问升级基础运行环境是提高性能最好的方式之一。特别的 PHP7 和 MySQL 5.7 较之前的版本性能提升很大。还可以根据服务器配置适当调整 PHP-FPM 和 MySQL 参数。

0x2 使用缓存

这里的缓存有两层意思，一是 PHP 层面的运行数据缓存，二是文章页面静态化。这里推荐几个插件来解决这个问题：

Redis Object Cache

一款持久对象缓存插件。其实 WordPress 本身带有对象缓存功能，但是是把序列化的对象缓存在文件中，效果不是很好。这个插件通过重写 object-cache.php 文件，把对象缓存到 Redis。直观的感受就是不光前台页面加载速度快了，而且后台响应速度提升更大。

Cache Enabler

keycdn 公司开发的一款页面静态化缓存的插件。相比 wp-supercache 等插件更加简洁和强大。建议按照官方说明进行增强设置，官方的配置有一点小问题，当你的永久链接格式设置为 xxx.html 时 $cache_uri（默认是 $request_uri）没有后面的 / 拼凑的文件路径不对（xxx.htmlindex.html），需要改成 ${cache_uri}/index.html，这样虽然访问首页时中间会多个 / 但也不影响。

我使用的是 Nginx，除了正常设置 gzip 外还开启了 gzip_static 参数，让 Nginx 在读取文件的时候优先读取带 gz 后缀的静态文件，不用再做 gzip 压缩。

顺带推荐一个 gzip 检查网站：https://www.giftofspeed.com/gzip-test/

不过使用高级设置后需要把缓存有效期设置为 0（永不失效），可能会造成缓存不会被更新（正常情况下更新文章缓存会被更新）。这里我是通过删除缓存文件然后访问自己 sitemap 中的链接来刷新缓存：

https://gist.github.com/iyaozhen/53e6a57a2f7e945ba1161953959a7cb2

Nginx open_file_cache

上一步我们已经将网站静态化，访问一般的文章页面，其实相当于打开 html 文件，但文件打开关闭也是有开销的，这个能否优化呢？答案是可以的，nginx 提供了 open_file_cache 功能，简单配置即可

此配置是让 nginx work 保持最常访问的文件句柄，不是缓存文件内容（nginx 发送文件是内核态直接发送的，不用应用层用户态保持文件内容），对于中小站点很实用，我们可以通过 sudo lsof -p pid 查看进程打开的文件句柄。这一通骚操作后，TTFB 能降到 10ms 以下。

0x3 使用 CDN 和图片压缩

用户有时候感觉网站慢，更多的是静态资源加载慢。页面上的 JS、CSS、图片等都需要消耗服务器带宽。而且中国地域辽阔，跨地区、跨运营商更是问题。这时就需要 CDN 了。现在国内各个云都在相互竞争，CDN 比较便宜，免费的也有很多。我之前使用的是七牛云，不过自从服务器迁到腾讯云之后， CDN 也换到了腾讯（免费12个月）。这里推荐同为 keycdn 出的 CDN Enabler 插件，能将页面中的链接替换为 CDN 链接。同时推荐使用 WP Smush、Compress JPEG & PNG images 压缩图片（有条件的还可以付费开启 webp），还有使用 BJ Lazy Load 实现图片懒加载（显著提高首屏加载速度）。最后不要忘记站点和 CDN 都配置一下防盗链。

0x4 升级到 HTTP2

HTTP2 支持请求复用，能提高50-70%的加载速度。首先要配置 HTTPS，再简单的配置下就能支持 HTTP2 了。当然静态资源使用的 CDN 最好也要支持 HTTP2，目前国内厂商基本都支持。

0x5 配置`dns-prefetch`、`preconnect`和`prerender`等资源加载参数

Continue Reading...

WordPress 国内优化

众说周知 WordPress 是全球使用量第一的开源博客系统，本博客就是基于此搭建的。但是 WordPress 在国内有些水土不服，有些地方没有考虑中国的国情（GFW），需要做一些小优化。以下代码直接添加在主题或者子主题的模板函数 (functions.php)文件中即可，此文件可在后台直接编辑（外观->编辑）。

1. 移除 Google CDN 字体。英文博客使用 web-font 还是很不错，各个平台使用同一种字体，极大地提升了用户体验，但是中文博客基本用不上，而且 Google CDN 被墙，还会极大影响页面加载速度，所以还是直接去掉吧。

2. Gravatar 地址替换。WordPress 默认使用的几个 Gravatar 头像地址都被墙了，建议替换为 V2ex 提供的 CDN 地址（支持 HTTP2）。注意，官方地址路径为 /avatar，V2ex 的 CDN 为 /gravatar。

3. 使用最新的 jQuery 以及使用 CDN（BootCDN，支持 HTTP2）。需要注意测试，可能有些插件会有兼容问题。

4. 移除自动 dns-prefetch。WordPress 4.6 增加了 dns-prefetch 功能，他会分析页面注入的 js 等脚本然后，加入 DNS 预加载列表。wp-includes/general-template.php：

当然这个功能出发点是好的，但是有些域名解析很慢，预加载可能会拖慢速度，而且我也不需要使用 emoji 和 Google 字体（默认预加载了这两项）。

建议使用插件 instant-articles 来手动设置 DNS 预加载。

目前本博客只进行了这几点国内环境的特色优化，若其它小伙伴还有什么黑科技欢迎交流。当然除了中国特色，也有一些很有效的通用优化策略：WordPress通用优化策略及常用插件推荐。

参考资料：

最近针对 V2EX 的 Gravatar 头像加载做了一个优化，https://www.v2ex.com/t/141485

http://www.wpbeginner.com/wp-themes/replace-default-wordpress-jquery-script-with-google-library/

https://wordpress.org/support/topic/remove-the-new-dns-prefetch-code/

一个诡异的 Chrome 视频播放（加载）问题

今晚上线了一个新的 web 页面，主要多了一个背景视频功能，大概是这样：http://thenewcode.com/samples/polina.html 。但上线后遇到一个问题，HTTPS 下背景视频很大概率不播放。线下测试的时候遇到过类似的问题，是因为 webserver 没有在 mime.types 文件添加`video/mp4    mp4 mp4v mpg4`浏览器不能识别的原因，但线上确定不是这个原因。

Chrome 抓包发现是视频文件请求 412 了，单独访问这个视频文件也是 412 偶现不能访问，但 http 下却没有这个问题。查了下 412 是连接建立先决条件失败，第一次遇到这个错误码，直接看状态码定义，看不出个所以然。看起来自己一时半会儿解决不了呀，马上把这个问题抛到公司的群里，一会儿得到了几个大神的回复：很大可能是 If-Match 和 ETag 对不上的问题。仔细看了下 412 的请求 headers 部分确实是这个现象。

可以看到，Chrome 在加载一个视频的时候是分段加载，当某一个请求 412 的时候会造成整个视频加载失败。群里的璐神给了一些参考资料，里面有一段说明：

在大型多 WEB 集群时，使用 ETag 时有问题,所以有人建议使用 WEB 集群时不要使用 ETag，其实很好解决,因为多服务器时, INode不一样，所以不同的服务器生成的 ETag 不一样，所以用户有可能重复下载(这时 ETag 就会不准)，明白了上面的原理和设置后，解决方法也很容易，让 ETag 后面 二个参数，MTime 和 Size 就好了。只要 ETag 的计算没有 INode 参于计算,就会很准了。

觉得这个说得很有道理，决定改一下 Apache 服务器试试。看配置文件的时候发现，http 的配置下有一行 `FileETag -INode -MTime Size` 的配置，但是 https 下没有，把这一行也加到 https 的配置文件中果然就行了。

虽然问题是解决了，但是感觉还是没有找到根本原因的样子。看了下 Apache 的文档发现 FileETag 默认使用 MTime 和 Size 两个参数，因为集群部署代码时是串行的，且会改变文件的时间（OP 部署系统的锅，中间有一步进行了 cp 操作），所以应该是 MTime 不一样造成了每台服务器上应该是同一个文件的 ETag 不一样，而每个分片请求落在了不同的机器上，造成If-Match和`ETag`对不上，不是之前猜测的 INode 问题。但感觉还是哪里不对，为什么If-Match和`ETag`对上了的请求就没问题了，按照理解ETag是用来做缓存的，对不上很正常，web server应该返回完整内容呀。下班回家又仔细想了一下，觉得这个问题应该反过来思考，因为 Chrome 是分段加载视频，需要保证这个视频在加载过程中是没有变动的，这样才有意义，所以需要每次请求都对比 ETag。那么为什么其它浏览器没这个问题了，抓包发现 IE 没有分段下载功能，是当一个文件都加载完成后才播放。FireFox 没有带上 `If-Match` 的请求头：

Safari 也没有使用 `If-Match` 的请求头，因此就 Chrome 下有这个问题。If-Match 的说明也验证了我的猜想：

For GET and HEAD methods, used in combination with an Range header, it can guarantee that the new ranges requested comes from the same resource than the previous one. If it doesn't match, then a 416 (Range Not Satisfiable) response is returned.

当然我这个案例中错误码是 412（通常用作 PUT 方法更新资源出错时），不过这是一个意思，符合预期。

ETag 工作流程和生成算法补充：当客户端第一次向服务器请求资源时，服务器会返回资源并根据资源的一些信息生成 ETag 返回给客户端，客户端不需要了解 ETag 是如何生成的，只需缓存下 ETag 当下次请求时带上（If-None-Match: ETag）。表示如果这个资源的 ETag 和我请求的不一样则返回数据，一样则返回 304。

不同个 webServer 生成 ETag 的算法可能不一样，比如上面提到的 Apache 使用的是 INode MTime Size 三个文件属性计算而得：

参考资料：

Apache配置Etag详解 http://www.yudouyudou.com/jiaochengheji/wangzhanjianshe/262.html

https://httpd.apache.org/docs/2.4/mod/core.html#fileetag

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Match

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn

http://stackoverflow.com/questions/44937/how-do-you-make-an-etag-that-matches-apache

Ubuntu 16.04 上安装 MySQL 5.7 的一些细节

最近腾讯云折扣力度比较大，在加上之前 DigitalOcean 上的 VPS 访问不是太顺畅，就把服务器迁回了国内。重装了一把 MySQL，遇到了一些细节上的问题，觉得很有意义，记录下。

首先使用 MySQL 官方的源安装，这个在一年前的《Ubuntu 平滑升级 MySQL 到 5.7》中描述过，具体过程不再赘述。说一些细节上的东西：

1. Ubuntu 16.04 要求 2017.01.01 后所有的源必须使用 SHA2 以上版本的摘要签名算法（https://wiki.debian.org/Teams/Apt/Sha1Removal）。目前来说具体表现是在执行`sudo apt-get update`时会显示一个警告“W: http://repo.mysql.com/apt/ubuntu/dists/xenial/InRelease: Signature by key A4A9406876FCBD3C456770C88C718D3B5072E1F5 uses weak digest algorithm (SHA1)”。访问一下网址确实看见使用的是 SHA1 签名，这个只能等待官方修复。

2. 安装过程中会要求设置 root 密码，这里你可以你直接回车（设置空密码），但实际上是给你创建了一个 auth_socket 的 root 用户，并不是空密码。

这时你登录的话需要使用 socket 方式连入：`sudo mysql --protocol=socket --socket=/var/run/mysqld/mysqld.sock`，注意这里需要用 root 权限运行，保证有足够权限读取 sock 文件，不然会默认使用当前用户进行传统的 ip+port 登录，这样肯定是登录不上的。登录上去就可以改 root 密码了，正常执行`ALTER USER 'root'@'localhost' IDENTIFIED BY 'test';`后发现密码并没有被改变（会报 warning），观察上面的截图会发现 root 账号的认证插件用的是`auth_socket`，我们需要这样执行命令`ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'test';`。就能回到传统的账号密码认证了。

3. 细心的同学可能已经发现了，多了一个`mysql.sys`的用户，按照官方的说法这是给 DBA 使用的，防止直接使用 root 账号带来的重命名和误删账号的问题。这个用户默认有一个初始密码，但在日志里面没找到（源码编译 MySQL 5.7 后 mysql_install_db –initialize 时会把密码记录到日志中）。这里索性重新设置一个密码（ALTER USER 'mysql.sys'@'localhost' IDENTIFIED BY 'test';）。

到这儿基本上已经安装完成了，但若你细心的话会发现在启动日志里面会有一些警告：

1. TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 这个是说`explicit_defaults_for_timestamp`缺省值已经废弃了，需要显式的在 my.cnf 设置 explicit_defaults_for_timestamp = 1

2. [Warning] Could not increase number of max_open_files to more than 5000 (request: 65535) 这是个常见的错误，一般修改 /etc/security/limits.conf 即可，但改了之后好像不奏效。这是因为在 /lib/systemd/system/mysql.service 配置中还有参数 LimitNOFILE 限制，把这里也修改了就可以了。

3. 还有日志中时间的时区和系统的不一致，看日志不方便。这是 5.7 新加的参数`log_timestamps`（http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_log_timestamps），在 my.cnf 设置为 log_timestamps = SYSTEM 即可。

全部搞定后建议执行`sudo mysql_secure_installation`命令，做一些安全设置，比如禁止root远程登录、删除匿名用户、验证密码安全级别等。

最后介绍一个比较好用的命令：mysql_config_editor，解决命令行登录MySQL便捷性和安全性的问题。我们为了本地登录MySQL方便经常会写一些一键登录的小脚本。基本上都是直接执行 mysql -uroot -p'test' 命令，这样会带来一个问题，执行的命令会被记录在bash_history中，当然你也可以禁用bash_history的功能，但这样会失去一些便捷性，也不大方便追查历史的问题命令。而且在新版本中直接使用这种方式登录会有警告信息。

这时我们就可以使用 mysql_config_editor 来创建一个 login-path，登录时直接使用`mysql --login-path=xxx`即可。一个典型的创建指令：mysql_config_editor set --login-path=xxx --host=localhost --user=root --port=3306 --password，然后输入密码。这里需要注意一下，如果粘贴的密码中有特殊字符会有问题，需要加上引号。比如你的密码是 test!@#，需要复制文本 'test!@#' 进行粘贴。创建的文件默认在 `~/.mylogin.cnf`，不过这是个二进制文件，看不出来啥（比较安全）。我们可以使用 `mysql_config_editor print --all` 命令来看看已经创建的 login-path：

这里也能看见密码是加密存储的，在一定程度上保证了安全。而且 .mylogin.cnf 文件可以分发给使用同一个MySQL-client的用户，提高了安全性也方便运维管理。很实用的功能，强烈推荐使用。

MySQL 每个版本都有很多安全性和性能的改进，值得去学习、研究。而且 MySQL 8（现在都流行跳版本）也快出来了，前景更是一片大好。

 

参考资料：

Change user password in MySQL 5.7 with “plugin: auth_socket”, https://www.percona.com/blog/2016/03/16/change-user-password-in-mysql-5-7-with-plugin-auth_socket/

Where is the MySQL 5.7 root password?, https://www.percona.com/blog/2016/05/18/where-is-the-mysql-5-7-root-password/

Do I need to change the mysql.sys password, http://askubuntu.com/questions/824139/do-i-need-to-change-the-mysql-sys-password

Can not increase max_open_files for Mysql max-connections in Ubuntu 15, http://stackoverflow.com/questions/30901041/can-not-increase-max-open-files-for-mysql-max-connections-in-ubuntu-15

一个css选择器的小坑

之前博客主题中的有序列表显示有点问题，列表标记位置会在正文左边突出一部分，所以设置了 padding 值来解决此问题：

但有发现无序列表也有这个问题：

2016-05-10_015434

所以想当然的在之前的位置后面把 ul 标签加上：

然后就悲剧了，页面上其它位置的 ul 也 padding-left: 20px 了：

2016-05-10_020412

好久没写 css 了，百思不得其解，试过 .article-content > ol, ul、.article-content section > ol, ul 都不行，甚至怀疑同级标签也有继承的关系。后来发现其它地方会把 class 标签写两次才恍然大悟，应该是逗号「,」优先级更高一点，把选择器解析成了 .article-content ol 和 ul 两部分，所以选择器写成 .article-content ol, .article-content ul 就可以了。

不用就会忘，随便改点东西就踩坑了。Orz!

Nginx+PHP-FPM 500 504错误简析

最近新配置的 Nginx + PHP-FPM 环境遇到了几次 Nginx 500（Internal Server Error） 和 504（gateway timeout） 错误。就索性把配置修改的过程记录下来，已备后查。

先说一下 500 错误，这个一般是 PHP 代码错了，看一下 PHP 的 error 日志就清楚了。但有时候是 Nginx 和 PHP-FPM 配置不当导致的，比如说上传文件的场景。我们都知道 php.ini 文件里面 post_max_size 和 upload_max_filesize 两个配置项决定了文件上传的大小。但上调配置后发现大文件上传还是会 500，原来是因为 Nginx 也会限制上传文件的大小，有 client_max_body_size 配置项决定。这里还有一个比较重要的参数：client_body_buffer_size。为了节省资源 Nginx 不会把 request body 里面的数据一口气读到内存中，而是分片处理，这个参数就是设置缓存区的大小（一般也不用改），大于缓冲区大小的数据会以一个个小文件（buffer_size）形式存储到 client_body_temp_path，为了避免高并发下缓存文件冲突和一些文件系统限制（比如 ext3 磁盘格式文件夹下一级文件个数限制为 3.2w 个）以及提高性能可根据业务需要设置多级子目录。还需特别注意的是路径要有被 Nginx 进程写的权限，不然又会 500 错误了。

然后是 504 错误，除了业务代码本身超时更多是配置问题。还是先说 PHP 的配置，很多人都知道 PHP 脚本有执行时间限制（php.ini 中的 max_execution_time），但在 PHP-FPM 却是 php-fpm.conf 中的 request_terminate_timeout 配置项控制的。还有就是 max_input_time 配置项，值比较小的话在接收大文件或大数据量 POST 请求的时候可能会超时，一般不用做改动，因为大部分场景都是上游 web server 接收好数据后传给 PHP-FPM 进程的，传输的非常快，几乎不会超时，但也不能一概而论，要看具体业务场景。然后就是 Nginx 的锅了，刚也说到是 Nginx 接收好（或者说是转发）数据后传给下游，在这个承上启下的环节很容易超时。几个比较重要的配置项：fastcgi_send_timeout 控制向下游（这里是 PHP-FPM）发送数据的超时时间，与之对应的一个配置项是 fastcgi_read_timeout，表示读取下游 response 的超时时间，这里需要注意的是要和前面说的 request_terminate_timeout 保持一致（或大于）。还有一个配置项 fastcgi_connect_timeout，表示和下游 FastCGI 建立连接的超时时间，不过这个值就不用设置的太长了，不然下游某个节点挂了就会夯住 Nginx 的处理线程，影响业务。

我所遇到的场景就是上面这些，可能还有其它一些情况，具体问题具体分析应该也很好解决。

参考资料：

http://nginx.org/en/docs/http/ngx_http_core_module.html

http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html

《PHP-CGI 进程 CPU 100% 与 file_get_contents 函数的关系》 http://zyan.cc/tags/request_terminate_timeout/1/

《PHP超时处理全面总结》 https://segmentfault.com/a/1190000000313184

《PHP file upload affected or not by max_input_time?》 http://stackoverflow.com/questions/11387113/php-file-upload-affected-or-not-by-max-input-time

一个 MySQL 用户名长度的坑

今天使用 PHP 连接一个 MySQL 数据库的时候连不上，提示无权限。

因为 MySQL 是在另外一个机房，首先想到的是防火墙的原因，但使用 MySQL-cli 却能正常连接，遂排除这种可能。

又怀疑是 PHP 框架的问题，写了一个简单的测试脚本，主要语句：mysqli_connect()，并打印出错误。运行一下还是不行，错误如下：

真是奇了怪了，这个用户创建时指定的是通配符 '%'，而且在别的机器都可以连接。又把测试脚本放在以前一直运行的环境（PHP 7）中，能运行通过。

看来是是环境问题（PHP 5.4）了，回过头来看那句报错，发现用户名好像被截断了（应该是xxx_user），是不是显示的问题，随便改一个用户名试试，同样报错，用户名却没有截断。这时又想了想是不是 MySQL 的版本太高（5.7.10）了。找了个 MySQL 5.5 的环境，创建相同的用户却发现报错了：String 'xxx_user' is too long for user name (should be no longer than 16)。查询 MySQL 文档发现：MySQL user names can be up to 32 characters long (16 characters before MySQL 5.7.8). http://dev.mysql.com/doc/refman/5.7/en/user-names.html

这样看来应该是老版 PHP 的 mysqli 扩展内部限定了用户名的长度，但新版的 MySQL 却可以创建更长的用户名了。知道原因了就很好办了，创建一个短用户名 OK 了。其实也是阴差阳错，因为新库是多应用共有，所以用户名创建的比较长。_(┐「ε:)_