最新 | 最热门 | 最高评价
---

+0  一个Laravel队列引发的报警

Tag: Technical | Linux
老王 发于 2015年06月10日 17:43 | 点击: 889 | 展开摘要
一台服务器报警了，内存占用过高，奇怪的是集群里其它的服务器都没问题。不过从以往的经验来看：每一个匪夷所思的问题背后，都隐藏着一个啼笑皆非的答案。

首先通过「free -m」确认一下内存情况，发现用掉了 6893M，还剩 976M：

free

然后通过「top」查看一下哪些进程占用内存多，通过「shift + m」按内存排序：

top

虽然通过 free 命令我们能确认系统可用内存不足，但是通过 top 命令我们却没有发现有内存占用大户的进程，那么内存到底都去哪里了呢

查看全文: http://www.udpwork.com/item/14293.html
^..^

+0  记一次Auto Increment故障

Tag: Technical | MySQL
老王 发于 2015年05月30日 23:00 | 点击: 882 | 展开摘要
实际上本次故障的素材来自于朋友的朋友，虽然我并不是故障的亲身经历者，但即便只是作为旁观者，依然感觉有所收获，于是乎记录下来以馈读者。

故障的来龙去脉大致是这样的：在一个月黑风高的晚上，苦逼的程序员被一阵急促的报警短信声惊醒，原来是数据库的某个表出问题了，虽然查询操作都正常，但创建操作却都失败了，经过调试，发现原因是表被插入了一行问题数据，其自增字段的值被显式的设置为整型的最大值，导致后续缺省插入的数据不能获取到一个合法的主键值。

我们不妨创建一个测试表说明问题：

CRE

查看全文: http://www.udpwork.com/item/14249.html
---

+0  监控Netstat数据

Tag: Technical | Linux | PHP
老王 发于 2015年04月09日 14:33 | 点击: 1237 | 展开摘要
我的日常工作有很大一部分比重是处理各种网络问题。很多时候，面对突发故障，完全搞不清楚缘由，此时，一个完善的监控系统能起到事半功倍的效果。

一个好消息是「netstat -s」里的各种计数器包含了很多有用的信息；一个坏消息是计数器记录的通常都是一些硕大无比的绝对值，不够直观。以前，我写过一篇的文章来介绍如何监控相关数据，但写得并不完善；最近，浏览文章时偶然发现一个工具，可以很方便的实时查询计数器相对值的变化情况，可惜不能方便的对接到监控系统里。既然现有的轮子都不太合适我的需求

查看全文: http://www.udpwork.com/item/14076.html
^..^

+0  如何统计Redis中各种数据的大小

Tag: Technical | Redis
老王 发于 2015年03月25日 16:45 | 点击: 1847 | 展开摘要
如果 MySQL 数据库比较大的话，我们很容易就能查出是哪些表占用的空间；不过如果 Redis 内存比较大的话，我们就不太容易查出是哪些（种）键占用的空间了。

有一些工具能够提供必要的帮助，比如 redis-rdb-tools 可以直接分析 RDB 文件来生成报告，可惜它不能百分百实现我的需求，而我也不想在它的基础上二次开发。实际上开发一个专用工具非常简单，利用 SCAN 和 DEBUG 等命令，没多少行代码就能实现：

<?php

$patterns = arra

查看全文: http://www.udpwork.com/item/14027.html
^..^

+0  Nginx带宽控制

Tag: Technical | Nginx
老王 发于 2015年03月20日 17:28 | 点击: 1037 | 展开摘要
有个老项目，通过 Squid 提供文件下载功能，利用 delay_parameters 实现带宽控制，问题是我玩不转 Squid，于是盘算着是不是能在 Nginx 里找到类似的功能。

好消息是 Nginx 提供了 limit_rate 和 limit_rate_after，举个例子来说明一下：

location /download/ {
limit_rate_after 500k;
limit_rate 50k;
}

大概意思是：用户下载达到 500k

查看全文: http://www.udpwork.com/item/14007.html
---

+0  监控进程

Tag: Technical | Linux
老王 发于 2015年02月11日 16:08 | 点击: 1343 | 展开摘要
有时候，进程突然终止服务，可能是没有资源了，也可能是意外，比如说：因为 OOM 被杀；或者由于 BUG 导致崩溃；亦或者误操作等等，此时，我们需要重新启动进程。

实际上，Linux 本身的初始化系统能实现简单的功能，无论是老牌的 SysVinit，还是新潮的 Upstart 或者 Systemd 均可，但它们并不适合处理一些复杂的情况，比如说：CPU 占用超过多少就重启；或者同时管理 100 个 PHP 实现的 Worker 进程等等，如果你有类似的需求，那么可以考虑试试

查看全文: http://www.udpwork.com/item/13849.html
---

+0  记一次LVS/Nginx环境下的访问控制

Tag: Technical | LVS | Nginx
老王 发于 2015年01月23日 16:56 | 点击: 1313 | 展开摘要
偶然间，我发现 Graphite 显示服务器网卡流量呈锯齿状，于是查了一下 Nginx 日志，发现有人在周期性抓我们的接口数据。我这爆脾气自然不能容忍这种行径。

简单分析一下访问日志，很容易就能拿到了可疑的 IP 段，直接用 iptables 封杀：

shell> iptables -A INPUT -s x.y.z.0/24 -j DROP

本以为世界会就此清净，可没想到一点儿用都没有。莫非小偷已经突破锁头的限制？不能够啊！直觉告诉我问题应该和 LVS 有关，可

查看全文: http://www.udpwork.com/item/13795.html
---

+0  Request Header Or Cookie Too Large

Tag: Technical | AWK | Nginx
老王 发于 2014年12月31日 11:45 | 点击: 1244 | 展开摘要
运营反馈 Nginx 报 400 错误，具体点说：Request Header Or Cookie Too Large。其实随便搜搜就知道可以通过加大 client_header_buffer_size 和 large_client_header_buffers 来解决问题，不过这里面有一些细节值得讨论，正所谓：知其然，知其所以然。

首先，让我们想想为何 Nginx 不能用一个指令来搞定问题，而要用两个指令？为了搞清楚这个问题，我们不妨先看看官方文档的描述：

client

查看全文: http://www.udpwork.com/item/13701.html
---

+0  PHP优化杂烩

Tag: Technical | PHP
老王 发于 2014年12月25日 19:06 | 点击: 1244 | 展开摘要
讲 PHP 优化的文章往往都是教大家如何编写高效的代码，本文打算从另一个角度来讨论问题，教大家如何配置高效的环境，如此同样能够达到优化的目的。

pool

一个让人沮丧的消息是绝大多数 PHP 程序员都忽视了池的价值。这里所说的池可不是指数据库连接池之类的东西，而是指进程池，PHP 允许同时启动多个池，每个池使用不同的配置，各个池之间尊重彼此的主权领土完整，互不干涉内政。

pool

有什么好处呢？默认情况下，PHP 只启用了一个池，所有请求均在这个池中执行。一旦某些请求

查看全文: http://www.udpwork.com/item/13673.html
---

+0  Poor Man PHP Profiler

Tag: Technical | AWK | PHP | Shell
老王 发于 2014年11月14日 18:50 | 点击: 1205 | 展开摘要
说起 Profiler，老派的 PHP 程序员会选 XDebug，新派的 PHP 程序员会选 Xhprof，不过我们公司的服务器上都没装，于是我写了这个「Poor Man PHP Profiler」。

既然不用 XDebug 和 Xhprof，我们就要自己找 Profiler 的数据源才行。好在 PHP 本身支持慢日志，而且里面包含了调用栈信息，还包含了文件路径和具体的行号：

Slow

理论上不用写什么工具，把这个日志从前到后看一遍就能发现系统哪里慢，但我们人穷志不短，

查看全文: http://www.udpwork.com/item/13518.html
---

+0  关于FIN_WAIT1

Tag: Technical | Linux | TCP
老王 发于 2014年11月06日 18:32 | 点击: 1647 | 展开摘要
前些天，一堆人在 TCPCopy 社区里闲扯蛋，有人提了一个问题：FIN_WAIT1 能持续多久？引发了一场讨论，期间我得到斌哥和多位朋友的点化，受益良多。

让我们热热身，通过一张旧图来回忆一下 TCP 关闭连接时的情况：

TCP Close

看图可知，主动关闭的一方发出 FIN，同时进入 FIN_WAIT1 状态，被动关闭的一方响应 ACK，从而使主动关闭的一方迁移至 FIN_WAIT2 状态，接着被动关闭的一方同样会发出 FIN，主动关闭的一方响应 ACK，同时迁移

查看全文: http://www.udpwork.com/item/13483.html
^..^

+0  如何安装xsscrapy

Tag: Technical | Python
老王 发于 2014年10月30日 17:03 | 点击: 1578 | 展开摘要
我不想攻击别人，但我更不想被别人攻击。于是乎安全扫描变得格外重要，如此才能防患于未然，xsscrapy 就是这样一个漏洞检测工具。

既然这个工具是用 Python 写的，那么理论上安装应该是一件非常简单的事情：

shell> git clone https://github.com/DanMcInerney/xsscrapy
shell> cd xsscrapy
shell> pip install -r requirements.txt

不过我的服务

查看全文: http://www.udpwork.com/item/13449.html
|<<<1234567>>>| 一共12页, 135条记录