问题描述 最近有个活动放出去后，发现访问量非常大，导致服务器负载很高 和产品确认后，得知推送的用户并不多，大约6W，而nginx日志中的记录却有96W 排查流程2015.12.231234567891011121314151617181920212223241.top查看负载、cpu和内存如果发现高负载、低cpu和内存，那么可能是请求量过大的问题2.查看近几分钟的并发量，和上一日进行对比：cat

统计user_agent cat activity.access.log |awk -F ‘“‘ ‘{print $6}’|sort|uniq -c|sort -nrk1 一句话总结Chrome：一定有Chrome Safari：一定有Safari，一定没有Chrome Firefox：一定有Firefox IE：一定有MSIE

问题分析 zx域名服务器(200.105)早盘负载过高，经查看，发现有如下两个大的因素： 频繁执行的脚本，耗用CPU较高比如9:50左右，1分钟Load Average达到11： 12345root 16214 2.9 0.2 35456 22932 ? S 09:44 0:05 php /var/www/html/cate/cron/gjzg/Origina

问题描述205.235测试服务器之前为了调试，将mongodb的hosts指向了正式服务器，即/etc/hosts中配置了： 192.168.200.102 db_mongo_master 今天切换回测试地址(hosts改为192.168.205.233 db_mongo_master)后，访问页面，发现显示的数据仍然是正式服务器的数据。 调试过程1.刷新dns缓存，无

nagios是什么，适用于哪些监控场景？我理解为这是一个监控框架，类似程序框架一样(可以想象为ZF框架)，提供一个监控的规范，以及一些现成的监控插件，用户也可以自行编写符合nagios规范的插件，做一些自定义监控。 如何理解nagios的工作机制？监控的本质，就是搜集数据-分析数据-展示数据-预警，nagios也不例外。试想一下，如果由我们自己来做监控工具，我们会怎么做？ 以监控cpu的状态为例(

情景描述有个项目的数据表随着时间的推移，已经达到500多万行记录了，类似的情况在其他产品中也可能存在，当前期预估不足时，我们需要有个手段来检测后期的数据大小。 方案设计编写脚本，获取数据库中各个表的信息，对于超过预警值的，给予提示。另外，对于数据库规范(比如索引)的检测，也可以加入该脚本中。 代码123456789101112131415161718192021222324252627282930

1234我最近考虑了关于方案设计中“估时”这块，觉得自己估时也不是很准。 做项目中最难的点且最有价值的点在于 ：1.自己没碰到过且需要自己去探索的地方。这个地方估算时间是最难的。2.想往前走，走着走着感觉“水“好深，但往回退 又会浪费很多时间。--来自同事金鹏的感触 为什么我估时总是不准确？时间观念首先，我觉得时间观念在估时过程中，起到的作用是至关重要的。一个时间观念强的人，会把估时当成一种承诺

CPU信息查询几个cpu more /proc/cpuinfo |grep “physical id”|uniq|wc -l 每个cpu是几核（假设cpu配置相同） more /proc/cpuinfo |grep “physical id”|grep “0”|wc -lcat /proc/cpuinfo | grep proces

参考资料 http://www.letuknowit.com/post/19.html http://www.letuknowit.com/post/22.html 操作方式需要先添加EPEL(Extra Packages for Enterprise Linux) repository，添加方法如下，请根据Centos的版本和CPU自行选择，如果不清楚如何查看，请参考《Linux查看系统信息常

现象 205.233上面，一个存放日志的表，数据积累了很多，删除该表后，发现数据占用情况没有发生变更。 1234567891011121314151617181920212223> show dbs;admin (empty)local 0.078GBlogservice 17.945GB> use logserviceswitched to db log