之前有过一篇linux上的流量监控脚本的博文，是利用procfs进行数据运算。但BSD上的procfs和linux有所不同，它只包含了进程的信息，没有系统的统计。所以只能通过其他方法。 linux上另一种获取网卡总流量的方法是ifconfig命令，这个命令其实也是读取proc；但是BSD上的ifconfig输出里也没有…… 不过BSD上倒不是没法查流量上，事实上另外有两个命令，在实时观测中更加好用，一个是systat -if 1，几乎就是一个无色版的iptraf；另一个是netstat -idbhI bce0 1。 解释一下，systat是bsd上用来查看系统信息的一个超级利器，-if是-ifstat的简写，类似还有-vmstat等等。netstat是专门用来显示网络状态的，最常用的就是-ant显示所有的TCP链接，这里用的idbhI，表示interface、drop、bytes、human，也就是用方便读取的格式输出某网卡的流量值。 但是这两个命令，都是持续输出，必须接到^C信号才会退出运行。在实时管理时很好用，在做监控脚本的时候，就弄巧成拙了…… 好在netstat参数多，调整一下，使用idbnf参数（family）即可输出网卡总流量值，然后按照linux上一样的思路进行计算了。 最终脚本如下： 继续阅读……

想把前端缓存几十台服务器的访问日志数据计入数据库中，以便核算各频道带宽。按照一般流量统计的惯例，在服务器上设定crontab每5分钟rotate一次access.log。但是想到一个问题——当A服务器select了数据库里的数据但还没来得及update时，B服务器也开始执行任务select数据来了，最后的结果就不准确了——我相信这个问题对coder来说很低级，不过我是op，搞不来…… 继续阅读……

需要给某台服务器加内存，准备关机的时候，却一直报错。考虑直接断电危害比较大，还是找找原因，报错如下： shutdown: timeout opening/writing control channel /dev/initctl init: timeout opening/writing control channel /dev/initctl 从messages日志里没有发现任何附加信息。只能求助百度。好在解答很多： 是原有的initscripts和SysVinit找不到了导致的。 传上去initscripts-8.45.19.EL-1.x86_64.rpm和SysVinit-2.86-14.x86_64.rpm两个包，rpm -ivh安装。 重新poweroff还是报错；但强制-f跳过shutdown过程后，成功了。稍后再启动设备，试着再敲一次poweroff，这次就不报错，成功关机了。 继续阅读……

简单的试试varnish和apache traffic server。跟squid进行一下对比。 介于varnish和ats都是出现不太久的东西（至少是开源流行不长），选择其最新开发版本测试，正巧都是2.15版。呵呵~ varnish配置文件，只修改了backend到具体某台nginx发布点上。其他都是反向代理缓存的标配。（可参考张宴博客http://blog.s135.com和varnish权威指南http://linuxguest.blog.51cto.com/195664/354889） ats说明更少，从目前的资料看，修改了records.config中的监听，cache.config遵循源站未改，remap.config添加了map一条，绑定域名到同一台nginx上。 注：varnish和ats都没有修改缓存路径，即分别为var/varnish/varnish.cache和var/trafficserver，都是磁盘。 继续阅读……

原文地址：http://linuxsysadminblog.com/2010/09/a-day-in-the-life-of-facebook-operations/ 顺便说一句，这个linuxsysadminblog.com确实不错。 文章是笔者在现场听Facebook系统工程师汤姆·库克在2010年的surge可扩展和性能大会上的讲演时记录下来的—— 这是到目前为止最火爆的讲座了，还没开始就只剩下点站着的空间…… Facebook运维需要支持多大的应用环境： 1、在facebook花上每个月7亿分钟（不太明白这个意思，一个月明明只有43200分钟） 2、60亿次内容更新； 3、30亿张图片； 4、实现100万连接； 5、5亿活跃用户。 基础设施建设的发展： 1、租用IDC达到瓶颈； 2、开始自建； 3、目前已为加利福尼亚和弗吉尼亚两州服务。 发展历程： 从LAMP起步，然后拆分负载均衡，web服务器，app服务器，memcached，数据库。 最早的Facebook是一个单纯的发布在apache上的php站点。但后来php不足以支持Facebook的访问了，现在，Facebook已经开始编译一些php功能成C++程序，这就是业界闻名的HipHop。 Facebook大概拥有世上最大的memcached集群，超过300TB的数据存储在memcached内存中。 使用flashcache来改善mysql性能。 已实现支持的服务： 新闻feed、搜索、缓存。 服务使用中的编程语言： C++、php（前台）、python、ruby、java、erlang（聊天室） 各种编程语言间如何交互数据？json？soap？都不是。Facebook专用一个为各编程语言开发服务的软件框架。所有的Facebook系统后面，都是统一的一个平台。 Facebook每天都在担心： 开发、监控、数据管理、代码上线。 Facebook使用centos操作系统！ 系统管理： 配置管理； 系统管理——用CFengine； 按需管理。 开发： 前台部分——每天都有新代码上线。代码统一协调，所有人都在IRC的频道里交流。每个人都可以知道发生了什么，而不单单是工程师自己。 1、程序推送按需分发； 2、代码分发通过BT的方式； 3、php是经过编译的，数百MB的二进制文件通过极小的BT种子迅速下发； 4、完成全网更新只需要1分钟。 后台部分——只有开发和运维。开发工程师写代码、测试、演示。 1、这样能迅速得到性能数据； 2、揭露各环节的真实交互（这里翻译的应该不对，看不懂……）； 3、没有所谓的“提交、退出”； 4、全面参与应用变成产品的过程； 5、运维被“嵌入”每个开发团队。 代码的每一处修改和推送，都必须详细记录。 Facebook的服务器性能指标在线监控 ganglia监控系统：快速、便捷、超过500万的监控指标、可以通过网格和池的方式进行规划。 自主的监控系统 nagios监控系统：用来给各团队发报警，最开始是用的email。 Scribe高性能日志系统：最开始用的是syslogd，同时在用hadoop和hive。 怎么运行的呢： 1、定义要明确的依赖关系； 2、固定的失败次数； 3、服务器是第一步，系统架构设计。 4、现在重点是搞集群。通过功能不同进行逻辑关系划分（web、db、feed等） 5、下一步是数据中心。尤其是灾备。 6、不断的沟通——信息永远在共享中。 7、IRC。 8、大量的自动化数据获取和设置。 9、内部新闻更新。 10、内部工具的’headers’； 11、变更日志。 12、团队要短小精悍。 一个有趣的数字：平均每台Facebook的服务器8分钟就升级一次。 一个有趣的事实：Facebook最忙的时候是万圣节后的那天。 继续阅读……

原帖地址：http://bbs.chinaunix.net/thread-1860259-1-1.html 刚看到帖子，试着自己做做，首先必须承认做的过程是重新去翻过资料了…… 继续阅读……

公司RT系统某工单页面无法打开。通过httpwatch发现是图片附件比较大，卡住了页面加载最终导致。 询问当事人后，决定把图片删除掉。 右键菜单查看图片url，是http://rt.domain.com/Ticket/Attachment/123456/654321/12.jpg这样的格式~ 于是在服务器的DocumentRoot下查找相关路径，发现Ticket/Attachment下只有一个文件dhandler，这是一段perl程序。 相关部分如下： 继续阅读……

一个小需求，某目录下有五万多个模板文件，其中大概两万个是链接文件。当碰到如下情况： lrwxrwxrwx 1 nobody nobody 59 Dec 27 15:06 10000053.mod -> /var/www/html/category/model/10000050.mod 就需要创建同名的另一个模板文件10000053.wap文件，指向10000050.wap。 怎么做？ 我用了如下命令： bash ls -l /var/www/html/category/model | awk '$1~/^l/ && $9~ /mod$/ {gsub(/mod$/,"wap",$9);gsub(/mod$/,"wap",$NF);system("rm -f "$9" && ln -s "$NF" "$9)}' 不过从效果来看，使用gsub函数后速度慢了不少，这5万个文件花了几分钟。 继续阅读……

上redhat官网看资料的时候想起来上面有RHCE报名前的技能水平测试（用来预估水平，省掉一些基础课程的）。然后做了一下试试。地址如右：http://www.redhat.com/explore/pre-assessment 结果如下： 继续阅读……

读百度UEO博客的文章《浏览器的加载与页面性能优化》，其中关于浏览器对单个域名连接数有一段描述，与一般的概述稍有差别。由此可见像百度这种级别的公司，对性能细节抓到什么程度——让我想起之前在腾讯大讲堂里看到的”页面代码大小要求是MTU倍数”。 继续阅读……

某应用系统有一个产品翻页浏览，为了利于搜索引擎，准备把/search.html?param=1-2-3-4-5做伪静态化，变成/search/1-2-3-4-5.html的url显示。 继续阅读……

N年没更新的ipvsadm终于在今年春节前更新了，正好手头有lvs的任务，赶紧试试。lvs上说的很清楚，ipvsadm的1.2.26版仅工作于linux kernel2.6.28以上版本。所以首先要把现有的2.6.18的linux kernel升级。 继续阅读……

一台xen虚拟机，root密码忘记了，必须进入single模式修改root密码。步骤很熟练，xm shutdown domain && xm create -c domain——但是出问题了——没出现grub的启动界面，直接进入系统启动过程了！ 继续阅读……

有需求对某应用的图片和页面内容进行拆分。计划进行的很顺利，存储设备上成功分成了/vol/html和/vol/image，然后分别挂载在应用服务器上发布为html.domain.com和image.domain.com。但在恢复应用运行后出现一个问题：新图片的上传总是提示失败。 继续阅读……

偶然和某人谈到日志处理。最简单常见的需求，日志中访问量最大的前十个IP及其访问次数。 继续阅读……

《程序员》2010年11月刊的86-89四页，刊登了F5售前技术顾问，原VIACDN(TOM的CDN部门，后来独立运营)架构师徐超的文章《基于动态内容的缓存加速技术——F5 Web Accelerator产品技术剖析》。 继续阅读……

和apache、nginx一样，resin也自带了一个比较简易的status模块，只需要在resin.conf里配置就行了。在里添加如下一段： 继续阅读……

开发同事需要在程序中调用一个“安全级别比较高”的url，起初没觉得有啥问题，我们wget或者curl的时候，按照标准url的格式（即’请求方法://用户名:密码@域名/文件路径’）写就完全OK了。不过很快同事转来了报错： 继续阅读……

mysqlreport是mysql性能监测时最常用的工具，对了解mysql运行状态和配置调整都有很大的帮助。找了一些mysql的资料，发现大多数是关于php+mysql开发的，服务配置基本就是固定的几条。干脆找上mysqlreport的官网，啃下来这篇指南。翻译都是随着我个人的语言习惯，对直接能用mysql命令上看到结果的英文则保留下来。方便以后查找： 继续阅读……

设想了很多方法来加快运算，比如舍弃awk改用perl来完成，如下： 继续阅读……

一台nginx+resin的应用服务器出现大量的ipv6下的CLOSE_WAIT。重启后十五分钟就累积到了1500+。 继续阅读……

对于squid等服务器，其日志中就含有响应时间。但是，这个时间只是服务器软件处理过程的时间，进程一旦交出去，在网卡等处的时间，它就管不着了。而percona出品一款迷你型小工具，叫做tcprstat，正好派上用场~ 继续阅读……

最近得知CDN方面默认配置了reload-into-ims，而我们的html因为采用了ssi的include方式的原因，是没有last-modified的。在这种情况下的处理结果，让人好奇~ 继续阅读……

在对网站内容是否更新进行测试时，最常用的两个工具就是wget和curl。不过两个工具之间还是有一些小区别，甚至很可能影响到测试结论的。记录一下： 继续阅读……

NetApp作为专业存储，用起来还是比较让人放心的，不过放心不代表放手不管，一些重要的监控还是要做的。比如基本的CPU负载、网卡流量、磁盘使用率，作为数据存储特别关注的IOPS、DiskIO（因为有cache的原因，所以NetIO和DiskIO是不同时的，单从网卡进出不能判定磁盘的真实读写）。 继续阅读……