每天积累一点，一年后你会发现，自己变化很大

1，调用ad系统36ms

joeyon@linux:~$ sudo jstat -gcutil 23441  1000 100 [sudo] password for zqgame:   S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT     0.00   0.00  36.74  11.26  17.24   8251

iostat -t 1 10 Linux 3.2.0-23-generic (zfc-website2) 08/27/2014 _x86_64_ (16 CPU)08/27/2014 10:22:40 AMavg-cpu: %user %nice %system %iowait %steal %idle 0.11 0.00 0.01

10:24:39 AM CPU %user %nice %system %iowait %steal %idle10:24:40 AM all 11.68 0.00 0.69 0.06 0.00 87.5710:24:39 AM IFACE rxpck/s txpck

一些基本的管理命令：一步启动Erlang node和Rabbit应用：./rabbitmq-server在后台启动Rabbit node：./rabbitmq-server -detached关闭整个节点（包括应用）：./rabbitmqctl stop 怎样仅仅关闭应用而不关闭整个节点呢？因为rabbitmq-server一起启动了节点和应用，

前：111.09 次/秒 450.078 ms/次后: 112.8 次/秒  443.281 ms/次

这篇文章的目的是让你知道怎么了解你正在运行的Mongdb是否健康。mongostat详解mongostat是mongdb自带的状态检测工具，在命令行下使用。它会间隔固定时间获取mongodb的当前运行状态，并输出。如果你发现数据库突然变慢或者有其他问题的话，你第一手的操作就考虑采用mongostat来查看mongo的状态。它的输出有以下几列：inserts/

1,iostat -xawait：每一个IO请求的处理的平均时间（单位是微秒）。这里可以理解为IO的响应时 间，一般地系统IO响应时间应该低于5ms，如果大于10ms就比较大了。%util:接近100%,表明I/O请求太多,I/O系统已经满负荷，磁盘可能存在瓶颈,一般%util大于70%,I/O压力就比较大，读取速度有较多的wait（当然如果是多磁盘，即使%util是100%，因 为磁盘的

系统优化是一项复杂、繁琐、长期的工作，优化前需要监测、采集、测试、评估，优化后也需要测试、采集、评估、监测，而且是一个长期和持续的过程，不 是说现在优化了，测试了，以后就可以一劳永逸了，也不是说书本上的优化就适合眼下正在运行的系统，不同的系统、不同的硬件、不同的应用优化的重点也不同、 优化的方法也不同、优化的参数也不同。性能监测是系统优化过程中重要的一环，如果没有监测、不清楚性能瓶颈在哪里，怎么优

1、安装依赖包yum install -y gcc gcc-c++ ncurses-devel make wget2、下载Nloadwget http://www.roland-riegel.de/nload/nload-0.7.4.tar.gz3、安装Nloadtar zxvf nload-0.7.4.tar.gzcd nload-0.7.4./con

1,Linux的load average的含义$ uptime11:12:26 up 3:44, 4 users, load average: 0.38, 0.31, 0.19上面的输出，load average后面分别是1分钟、5分钟、15分钟的负载情况。数据是每隔5秒钟检查一次活跃的进程数，然后根据这个数值算出来的。如果这个数除以CPU的数目，结果高于5的时候就表明系统在超

Node.js 与Nginx之间也可以稍作比较。通过我们的线下测试，发现Nginx的性能比Node.js的HTTP模块要好很多。但Nginx考量的是面向客户端， 后端业务方面依然是受具体业务影响。而Node.js则可以利用异步I/O来实现业务并行，以提升效率。从这点看，Nginx没有Node.js灵活。此 外，Node.js后来的发展方向不再单独是一个Web服务器，而是一个面向网络的平台，它甚至可

关于系统性能瓶颈的定位，今天搬来一实例。希望和广大网友沟通分享 使用场景：        Nginx对外提供接口服务，本文以Nginx的状态页（stub_status）为例。 需要解决的问题：        定位性能瓶颈，并调优 测试方法        使用约40台测试机向一台Nginx服务器并发访问 服务器配

records 100w  / 1k sizesendmsmq     11kactivemq 6.5krabbitmq 12kkafka    35kzeromq   240kreceivemsmq     7kactivemq 6.5krabbitmq 12kkafka    20k zeromq   88k

简单的压力测试采用Apache ab，500并发用户，10w的请求总数。  总耗时(s)TPS(#/sec)LVS-NAT22.4804448.34LVS-TUNNEL10.7079339.80LVS-DR10.177

nginx耗时 业务耗时57.96------>437.05--->440.27--->360.80--->3

n/c (100000/500)f5        15klvs-tr    10klvs-nat   4.5kha(4层)   4.5knginx     1kapache    0.7klighttpd  0.15k1lvs=2ha=10nginx=20apache=100lighttpd

Oracle对云计算的支持力度，说明Oracle这个大象也可跳舞，而且还挺灵活的。官方对Fabric的介绍主要是它提供了MySQL的HA和Sharding方案，本文主要讨论Fabric在MySQL HA方面的表现以及搭建部署流程。我的团队试着搭建了一下，简直无法再简单了，这对于DBA来说绝对是一个大福音，这个产品在接下来的几年中必然会被大量应用到生产环境中去，我的团队对这个产品的未来充满信心。

测试环境: 服务器配置: 4 x Intel(R) Xeon(R) CPU E5405  @ 2.00GHz， 4G内存, 操作系统: CentOS 5.3 x86_64nginx前端 + 4 tornado(0.2) web processtornado: http://www.tornadoweb.org (已被墙)测试场景: http get请求，服务器端直接返回"h

1，以上测试并不完善，只是一个开始，比如没有测试小数据（以数字作为key，100字节Value），没有测试较大的数据（20K左右）；没有测试在命中情况下的性能；没有测试并发读写的性能，据闻MongoDB的并发读写效率不是特别出色，MongoDB的特色在于支持的查询语言非常强大2，TC/TT在mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。T

1KW数据单机：mongodb 插入：1秒5000  更新：5000 查询：10000mysql   插入：1秒2000 更新：1500 查询：9000Mongodb的insert及update性能大约是Mysql的2~3倍，select方面MongoDB与Mysql相当。

1,memcache是基于内存的分布式缓存，分布式是客户端基于key的hash做均匀。服务端用c开发。value不能大于1m。主要用来存储非可靠的只读数据。支付12w左右并发。单机tps 1k， tps 分布式 3w2，redis是用c开发的类memcache的kv存储系统。api丰富。支持10w的并发。基于内存，再定时同步到文件。可以当数据库使用，也可以作为持久层的缓存。不会

从事IDC数据中心业务多年，和无数的企业技术网管打过交道，在带宽单位的问题上，80%的技术都有典型误解。本人特针对此问题在QQ上详细阐明，希望对网管人员进行网络基础扫盲。 一般在书写带宽单位的时候，我们会写网络带宽是10M，很多网管误以为最大下载流量可以达到每秒下载10M的文件。其实是10/8 =1.25M。 原因：带宽的单位和硬盘的单位是不一样的。 容易误解的技术概念：Kb是否等于KB