最新 | 最热门 | 最高评价

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

Tag: Technical | Redis
老王 发于 2015年03月25日 16:45 | 点击: 1659 | 展开摘要
如果 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 | 点击: 992 | 展开摘要
有个老项目,通过 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 | 点击: 1286 | 展开摘要
有时候,进程突然终止服务,可能是没有资源了,也可能是意外,比如说:因为 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 | 点击: 1219 | 展开摘要
偶然间,我发现 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 | 点击: 1165 | 展开摘要
运营反馈 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 | 点击: 1187 | 展开摘要
讲 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 | 点击: 1159 | 展开摘要
说起 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 | 点击: 1551 | 展开摘要
前些天,一堆人在 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 | 点击: 1506 | 展开摘要
我不想攻击别人,但我更不想被别人攻击。于是乎安全扫描变得格外重要,如此才能防患于未然,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

+0  Where SLOW

Tag: Technical
老王 发于 2014年09月30日 15:12 | 点击: 647 | 展开摘要
前些天翻了翻「Wireshark数据包分析实战」,总结了一下汇聚成本文。

所谓慢,通常只是整体的主观感受,我们真正应该关心的是哪个环节最耗时?

Where Slow

判断原则按上图所示:

如果 TCP 握手或 ACK 耗时长,那么说明网络慢。

如果请求耗时长,那么说明客户端慢。

如果响应耗时长,那么说明服务端慢。

实战抓包按下图所示:

Package

对应结果依次是:正常、网络慢、客户端慢、服务端慢,如果使用 Wireshark,那么可能会发现时间显示格式有

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

+0  一次优化引发的血案

Tag: Technical | Linux
老王 发于 2014年08月13日 19:45 | 点击: 1136 | 展开摘要
前些天一个Nginx+PHP项目上线后遭遇了性能问题,于是打算练练手,因为代码并不是我亲自写的,所以决定从系统层面入手看看能否做一些粗线条的优化。

首先,我发现服务的Backlog设置过小,可以通过ss命令查询Send-Q来确认:

shell> ss -ln
Recv-Q Send-Q Local Address:Port Peer Address:Port
0 511 *:80

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

+0  简易云端Hosts的构建

Tag: Technical | DNS
老王 发于 2014年07月16日 09:33 | 点击: 1183 | 展开摘要
如果大家记忆力不太差的话,那么应该会记得前段时间发生的全国性DNS解析故障:很多顶级域名被解析到了IP地址 「65.49.2.178」,导致中国互联网瘫痪了几个小时。不过在那起事件里一些移动客户端应用得以幸免,其原因在于它们使用了云端Hosts。

所谓云端Hosts,就是把原本放在本地的Hosts放到了云端,如果用JSON的话类似:

{
"foo.com": "1.2.3.4",
"bar.com": "2.4.6.8"
}

客户端跳过DNS查询过程,直

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