您现在的位置：首页
--> 火丁笔记
一台Redis服务器在很短的时间里消耗了几十个G的内存，最终因为SWAP而宕机。因为这台服务器的社会背景比较复杂，所以一时无法判断犯罪嫌疑人到底是谁。 最开始的直觉是认为肯定有人保存了大体积的数据，于是问题就变成了找出哪些键占用的空间比较大，DBA同事用了redis-rdb-tools等工具来分析数据文件。可惜的是虽然找到了一些大体积的键，但最终都排除了嫌疑，问题似乎陷入了僵局。
• 浅谈TCP优化
很多人常常对TCP优化有一种雾里看花的感觉，实际上只要理解了TCP的运行方式就能掀开它的神秘面纱。Ilya Grigorik 在「High Performance Browser Networking」中做了很多细致的描述，让人读起来醍醐灌顶，我大概总结了一下，以期更加通俗易懂。
前些天发现XEN虚拟机上的Nginx服务器存在一个问题：软中断过高，而且大部分都集中在同一个CPU，一旦系统繁忙，此CPU就会成为木桶的短板。
前些天，移动端的同事跑来问：某些API需要传输大数据，Nginx服务器能否支持Gzip请求？一方面可以节省移动端流量；另一方面还可以加快传输速度，提升用户体验。对于Apache来说，利用SetInputFilter，可以很轻松的实现这个功能，那么Nginx如何做呢？ 既然移动端发送的是Gzip请求，自然需要想想如何在服务端解压缩。
Nginx缺省激活了accept_mutex，是一种保守的选择。如果关闭了它，可能会引起一定程度的惊群问题，表现为上下文切换增多(sar -w)或者负载上升，但是如果你的网站访问量比较大，为了系统的吞吐量，我还是建议大家关闭它。
何为敏感信息？简单点来说就是你不想让别人知道的信息，比如说数据库的地址，用户名，密码等等，此类信息往往知道的人越少越好。
写了好多年的PHP代码，不免有些许的厌倦，是时候学一门新语言了，这就好比对男人来说，家里的女人看得久了，新鲜感荡然无存，自然想纳几房小妾，不过对于身处河东狮吼险境的我而言，此等美梦注定遥不可及，还是老老实实学编程吧，想当年我还像模像样的学过Python，可惜没坚持下来，希望这次能行。
某项目使用CDN做文件下载服务，最近不时有网友反馈下载出错，因为CDN是第三方提供的，且节点众多，所以诊断起来有点麻烦，必须想想招儿。 首当其冲的问题是如何确认CDN有哪些节点？ 幸运的是通过阿里测提供的服务，我们能拿到这个IP列表，当然这个IP列表不可能百分百完整，不过应该包含了大部分的节点，有兴趣的可以参考百度的JQuery CDN例子。
我发现很多人的服务器上都运行着一些诸如每天切分Nginx日志之类的CRON脚本，大家似乎遗忘了Logrotate，争相忙着发明自己的轮子，这真是让人沮丧啊！就好比明明身边躺着现成的性感美女，大家却忙着自娱自乐，罪过！ Logrotate的流程 显而易见，Logrotate是基于CRON来运行的。
今天碰到一个替换问题：需要把全部接口中出现的一个链接改成另一个链接。虽然链接地址是保存在数据库中的，但是由于某些原因，不能直接修改数据库中的内容，只能在渲染结果的时候再进行替换。 如果有很好的逻辑封装的话，这个问题并不是什么难事儿，可恰恰代码一团乱，搞不清楚到底哪些接口需要修改。我本打算依靠蛮力挨个文件查，但试了试发现工作量实在太大了，没办法只能想想别的招儿。
神器：Wireshark，可以通过它来可视化分析tcpdump生成的日志文件：排查过程中陷入了僵局，看来瞎蒙是没戏了，只好硬着头皮用tcpdump了，说硬着头皮是因为我这个山寨OPS对TCP协议实在是不熟悉，但是为了解决问题，只能赶鸭子上架了，找一个客户端重现故障，然后在服务端用户tcpdump监听。
最近公司服务器不太稳定，总是在凌晨某个时段突发高负载情况，因为客观环境比较复杂，所以很难猜测出到底是哪个进程出现了问题，加之故障发生时，通常我在睡觉，无形中增加了解决问题的难度，于是我便写了一个Shell来替我搞定这个问题。 实际上解决问题的思路非常简单：通过CRON每分钟运行一个Shell，查询系统负载，一旦发现异常，就通过「ps」命令保存进程快照，也可以进一步保存负载，内存等相关的数据，但通常没有必要，因为通过「sar」命令很容易拿到。
所谓「HTTP Keep-Alive」，在维基百科里称为「HTTP Persistent Connection」，说白了就是复用HTTP连接，如此一来理论上客户端的用户体验会更流畅，但是与之相对服务端不得不维持大量的连接。开启还是关闭，这是个问题。
开始程序运行的非常稳定，稳定到我想送所有说HGETALL是个坑的人一个字：呸！此时的我就像温水里的青蛙一样忘记了危险的存在，时间就这样一天一天的过去，突然有一天需求变了，我不得不把HASH数据的内容从十几个字段扩展到一百多个字段，同时使用了Pipelining一次性获取上百个HGETALL的结果。于是我掉坑里了：服务器宕机。
为什么会这样？Redis是单线程的！当它处理一个请求时其他的请求只能等着。通常请求都会很快处理完，但是当我们使用HGETALL的时候，必须遍历每个字段来获取数据，这期间消耗的CPU资源和字段数成正比，如果还用了Pipelining，无疑更是雪上加霜。
为了规避内存碎片问题，Memcached采用了名为SlabAllocator的内存分配机制。内存以Page为单位来分配，每个Page分给一个特定长度的Slab来使用，每个Slab包含若干个特定长度的Chunk。实际保存数据时，会根据数据的大小选择一个最贴切的Slab，并把数据保存在对应的Chunk中。如果某个Slab没有剩余的Chunk了，系统便会给这个Slab分配一个新的Page以供使用，如果没有Page可用，系统就会触发LRU机制，通过删除冷数据来为新数据腾出空间，这里有一点需要注意的是：LRU不是全局的，而是针对Slab而言的。
• SWAP的罪与罚
说个案例：一台Apache服务器，由于其MaxClients参数设置过大，并且恰好又碰到访问量激增，结果内存被耗光，从而引发SWAP，进而负载攀升，最终导致宕机。 正所谓：SWAP，性能之大事，死生之地，存亡之道，不可不察也。 哪些工具可以监测SWAP 最容易想到的就是free命令了，它指明了当前SWAP的使用情况......
通常，Gearman被用来分发任务，以便实现异步操作。下面捋捋如何管理Gearman。
客户端和服务端的交互有推和拉两种方式：如果是客户端拉的话，通常就是Polling；如果是服务端推的话，一般就是Comet，目前比较流行的Comet实现方式是Long Polling。 注：如果不清楚相关名词含义，可以参考：Browser 與 Server 持續同步的作法介紹。 先来看看Polling，它其实就是我们平常所说的轮询，大致如下所示： 因为服务端不会主动告诉客户端它是否有新数据，所以Polling的实时性较差。虽然可以通过加快轮询频率的方式来缓解这个问题，但相应付出的代价也不小：一来会使负载居高不下，二来也会让带宽捉襟见肘。 再来说说Long Polling，如果使用传统的LAMP技术去实现的话，大致如下所示： 客户端不会频繁的轮询服务端，而是对服务端发起一个长连接，服务端通过轮询数据库来确定是否有新数据，一旦发现新数据便给客户端发出响应，这次交互便结束了。
火云邪神语录：天下武功，无坚不破，唯快不破！Nginx的看家本领就是速度，Lua的拿手好戏亦是速度，这两者的结合在速度上无疑有基因上的优势。 最先将Nginx，Lua组合到一起的是OpenResty，它有一个ngx_lua模块，将Lua嵌入到了Nginx里面；随后Tengine也包含了ngx_lua模块。至于二者的区别：OpenResty是Nginx的Bundle；而Tengine则是Nginx的Fork。值得一提的是，OpenResty和Tengine均是国人自己创建的项目，前者主要由春哥和晓哲开发，后者主要由淘宝打理。
在程序设计中，递归（Recursion）是一个很常见的概念，合理使用递归，可以提升代码的可读性，但同时也可能会带来一些问题。 下面以阶乘（Factorial）为例来说明一下递归的用法，实现代码为PHP： 如果安装了XDebug的话，可能会遇到如下错误： Fatal error: Maximum function nesting level of ’100′ reached, aborting! 注：这是XDebug的一个保护机制，可以通过max_nesting_level选项来设置。
近3天十大热文
-
[3998] QR码分析 -
[71] Twitter/微博客的学习摘要
-
[67] android 开发入门
-
[67] IOS安全–浅谈关于IOS加固的几种方法
-
[67] Go Reflect 性能
-
[64] 流程管理与用户研究
-
[64] 【社会化设计】自我（self）部分――欢迎区
-
[64] 如何拿下简短的域名
-
[63] Oracle MTS模式下 进程地址与会话信
-
[62] find命令的一点注意事项
赞助商广告
