上线网站后cpu一直占满，请教性能问题
由 sbicrgw 发布于 2014年06月04日无人欣赏。
之前我们做的都是企业信息管理项目，对互联网项目没有经验，今年开始创业做比特币交易平台之类的项目，因为受到攻击，所以遇到了些困难，各种攻击不断，中国互联网太乱了吧！现在有些疑惑，希望论坛大神帮忙解答一下：
- 我查看网站的连接数在300个的时候cpu就100%，网站就卡死了。我们是用tomcat部署的，请问300个连接数是怎么样的概念，还是我们程序性能也太差了？（我们用的服务器是阿里云8核16G内存的）
- 因为我们确实没有高访问网站的运营经验，请教一下我们应该往哪方面做奴隶，或者有什么资料或者书籍方面推荐一下吗？
- 你的所有请求直接进入tomcat？如果是这样的话，前端最好加一个nginx之类的服务器做反向代理，为静态资源和请求加上cache，不过看来你的静态资源已经上了cdn，那就给部分没有实时性要求的请求加上cahce吧。tomcat直接处理外网300多个连接，其实没有必要的。
- 这东西不是一两本书能教你的，在你城市里头找个熟悉互联网业务的人，请人吃几顿饭帮你看看吧。
- 我觉得你们是不是需要一个懂运维的人？
好吧，我很闲。今天来帮Tony老师撑场子。
服务器上去跑命令，看一下ESTABLISHED的连接有多少。 netstat -antp
如果连接过多不正常，那就是一次四层的攻击，也就是所有ip都是真实的。写个shell：
#!/bin/sh
do
for i in `netstat -an | grep -i ':80 '|grep 'EST' | awk '{print $5}' | cut -d : -f 1 | sort | uniq -c | awk '{if($1 > 50) {print $2}}'`
echo $i
echo $i >> /tmp/banip
/sbin/iptables -A INPUT -p tcp -j DROP -s $i
done
定时跑，5分钟一次。差不多就好了。
- 连接数是通过netstat -na | grep ESTAB | grep 80 | wc -l这个命令查看的，这个数量是可以代表并发量吗？
- 交易平台就几个页面，基本都是实时性非常高的，所以nginx是没用了，高防cdn只是用来挡攻击用的。
- 我看到cpu都是tomcat占用的，有其他办法更新的查看是tomcat那个算法导致的吗？
从Tony的帖子看到销售机会。。。。 我觉得没有运维经验的团队来玩互联网，首先应该考虑用PaaS而不是IaaS，所以推荐一下我们高大上的PaaS产品，搜狐云景 cloudscape.sohu.com, 目前处于邀请试用状态，我的手机是 139-1017-7625，or mailto:qiuyingbo#sohu-inc.com
先排除是否自己程序问题，用各种性能工具压下自己的网站,ab,siege.看下性能瓶颈在哪里？哪些页面比较慢。 是否有访问数据库，文件,io等比较慢。能用redis等高速缓存的尽量用起来。正式环境可以考虑用btrace跟踪下每个方法，每个业务逻辑的访问速度。然后tomcat改成nginx,最好做个负载均衡，nginx可以做，LVS也可以。当然nginx更简单些。 以上单页面的访问qps 最好能在200-300，响应时间在0.5秒内。像你这个硬件配置应该问题不大。CDN加速各种图片，CSS都用上。前端优化能做的做起来。 如果的确是访问量大，那就按性能测试的情况加机器吧。
我的8核 2.50G 16G linux随便能抗住400并发,4500 qps,87.322 ms 每个响应。一个没业务逻辑的jsp页面
你先确认是被人四层ddos了。（不过以你的问题来看你这个都确认不了……）
首先来看，你问的问题可能性太多，在论坛上可能找不到合适的答案。 找个技术专家或者安全专家帮你看下吧。首先定位问题。说句老实话，你现在可能连问题都没定位对。
#!/bin/sh
do
for i in `netstat -an | grep -i ':80 '|grep 'EST' | awk '{print $5}' | cut -d : -f 1 | sort | uniq -c | awk '{if($1 > 50) {print $2}}'`
echo $i
echo $i >> /tmp/banip
/sbin/iptables -A INPUT -p tcp -j DROP -s $i
done
这个代码的意思是不是将80端口上连接数超过50的ip交给iptables封掉？
CDN是不存储动态内容的，你动态内容多的话其实起不到太大作用。。。没做过tomcat的项目不过以前接触过lamp的项目，初期也是晚上高峰时段15分钟就挂，但我们的问题不在cpu上，因为cpu占用一直很低，我们当时的问题在查询优化，和session读写目录优化上。开了慢查询记录，一堆>100s的查询请求，把这些挨个排除掉解决了大部分问题，最后。。。我们那个项目程序员辩称他以前写java的，对php＋mysql不熟。。。