服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

可扩展性问题(龙卷风)。 无法弄清楚,举起发射

谢谢你们,任何想法/见解都会受到赞赏,因为这使我疯狂。 问题:在应用程序停止之前,只有大约3或4个用户可以同时使用服务器。 目前我们看到正常使用情况下CPU使用率的巨大峰值。 与真实用户相比,这比使用自动化脚本更容易复制,原因不明,但是脚本可能无法很好地模拟真实的使用情况。 我们的架构如下: 应用程序服务器(Tornado) – 单线程,具有asynchronousIO循环。 我们使用Tornado处理与长轮询相关的持久连接,并通过WSGI将所有基本的Web请求发送给Django。 Django ORM用于与数据库交互,尽pipe大多数SQL是手工编码的 MySQL数据库 Nginx提供静态媒体并将其他请求代理给Tornado 目前所有东西都安装在一个“Small”EC2实例上运行。 在机器之间分离服务器对性能没有明显的影响 有关服务器configuration的更多详细信息,请参阅EC2服务器规范: http : //aws.amazon.com/ec2/instance-types/ 。 注意:总而言之,这不是理想的和最可伸缩的设置,但它应该能够处理3个以上的用户! 运行顶部和查看日志显示以下内容: CPU峰值大部分归功于Tornado,每个活跃用户大约有25%的CPU使用率 低的“偷窃时间”,所以我们的CPU能力不会被EC2严重扼杀(再次) 数据库查询全部在0-200毫秒之间,当CPU没有峰值时,通常在峰值期间持续3秒或更长时间 内存使用率低,从不出现高峰 有些事情已经试图无济于事: configurationMySQL缓冲区大小,索引等。 我99%肯定这不是一个花园式的SQL /数据库优化问题 改善查询时间并以各种方式减less查询次数 将服务器放在单独的ec2实例上 多个应用程序服务器之间的代理(这显然是更大的可扩展性,但它不能解决每用户3个用户的问题) 升级EC2实例。 从“微”升级确实有帮助(由于CPU节stream问题),但只是稍微增加了我们的容量 部署在非EC2服务器(Slicehost)上 – 同样的问题 所有服务器都通过简单的testing用例单独进行了负载testing,并且都能够处理1000个同时连接