这种事需要你提供一个运行测试的报告,一切就解决了。
在用户反应慢的时候,给一份全天运行的硬件负载其实已经很够了,用户看不懂报告的话,派一个人去解释说明每一项都可能影响哪些软件性能,同时你要反过来给用户建议,让软件开发商提供完美运行的配置需求,此外建议建议用户使用一些性能测试工具去压软件测试负载情况。
运行反应慢有很多可能,cpu,内存,带宽的负载都很低的时候,软件方面的问题还可能是:连接请求失败太多、数据库查询太慢或者程序处理太慢,看给出的配置,应该是windows系统,找一个性能测试方面的人,简单配置一下系统的监控项目,出一个运行报告,在运行的时候监控报告应该给出这些指标:
硬件方面
内存使用数
cpu占用率
硬盘读写速度
网络带宽负载
网络请求封包数
软件方面
web 请求数量
web并发连接数量
web 请求成功与失败比率
web 请求平均响应时间
数据库请求 *** 作数
数据库并发连接数
数据库缓存命中率
数据库 *** 作响应时间
数据库进程负载情况
web server (IIS、Apache、Nginx)进程负载情况
有了这些指标你才能给用户足够的说服力证明在软件负载很大的时候,硬件资源占用还是很低。其中最重要的指标应该是数据库 *** 作响应时间和web平均响应时间,这两个如果在硬件负载不高的时候很慢,绝对就是软件方面原因,至于具体原因要看颗粒度更细的测试报告才能清楚,不过那应该属于软件开发商的事情了。
可以出这种报告的软件很多,系统自带的performent monitor ,LoadRunner,WebLoad,JMeter,MSACT。找一个熟悉性能测试的人出个方案即可,涉及到这些复杂系统应用的事情,上线前没有做过任何可用性/性能测试吗。
软件系统开发常见的十大瓶颈
J2EE核心是一组技术规范与指南,其中所包含的各类组件、服务架构及技术层次,均有共同的标准及规格。下面是我整理的关于软件系统开发常见的十大瓶颈,欢迎大家参考!
数据库
工作任务内存超过可用的RAM内存
长/短查询
写入冲突
大连接(join)占用内存
虚拟化
共享一个HDD、磁盘寻死(disk seek death)
在云端网络I/O波动
编程
线程:死锁、调试、非线性扩展等
事件驱动编程:callback()过于复杂、如何在函数调用中存储有状态等
缺乏调优、跟踪、日志等
单模块不可扩展、单点故障(SPOF:Single Point Of Failure)、非横向扩展等
有状态应用程序
设计问题:开发的.应用程序只在自己的机器行运行正常,或者只是在几个人测试的时候正常(没有经历压力测试)。
算法过于复杂
相关服务,例如DNS查找以及其他可能屏蔽的服务
堆栈空间
磁盘
访问本地磁盘
随机访问磁盘I/O
磁盘碎片
当SSD写入的数据大于SSD容量时,性能会下降
OS
Fsync饱和,Linux缓冲区填塞(Fsync flushing, linux buffer cache filling up)
TCP缓冲区太小
文件描述符限制
功率分配(Power budget)
缓存
没使用memcached(数据库崩溃)
HTTP中:headers、etags、没有使用gzip压缩等。
没有充分利用浏览器缓存
字节码缓存(如PHP)
L1/L2缓存:这是个令人头疼的大瓶颈。把关键并且经常访问的数据存储在L1/L2中。这涉及到很多:snappy网络I/O,列数据库直接在压缩数据上运行算法等。利用一些技术不销毁你的TLB。最重要的思想是紧紧的抓住计算机的体系结构,涉及多核CPU,L1/L2,共享的L3,NUMA RAM,从DRAM到芯片数据传输带宽/延迟,DRAM缓存的DiskPages,DirtyPages,流经CPU<->DRAM<->NIC的TCP包。
CPU
CPU过载
内容切换—>单核上开启的线程过多、Linux调度器、系统调用太多等
IO等待—>所有的CPU在同速等待
CPU缓存:缓存数据是一个细粒度进程,为了在多个实例与不同的值数据之间找到正确的平衡,来保持缓存数据的一致性和繁重同步。
底板吞吐量(Backplane throughput)
网络
NIC刷爆、IRQ饱和、软中断占用掉了100%CPU
DNS查询
数据包丢失
网络中存在预期外的路由
访问网络磁盘
共享SAN
服务器故障—>无法从服务处得到响应
进程
测试时间
开发时间
团队规模
预算
代码债务
内存
内存不足—>杀死进程,切换到swap,挂起
内存不足导致磁盘交换(与swap相关)
记忆库开销过大(Memory library overhead)
内存分片(在Java中需要会因为内存回收而停顿在C中,malloc总是开始分配内存)
//SQL语句12 var_dump($sql)
13 $res = mysql_query($sql)
14 $arr = array()
15 //吧结果存入数组 并记录数组长度
16 $count = 0
17 while($data = mysql_fetch_array($res)){
18 $arr[$count] = $data
19 $count++
该参数值一直很高,且如果在 Physical Disk 计数器中,只有%Disk time 比较大,其他值都比较适中,硬盘可能会是瓶颈。若几个值都比较大, 那么硬盘不是瓶颈。若数值持续超过80%,则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值(Processor%Privileged Time)也一直很高, 则考虑使用速度更快或效率更高的磁盘子系统。 Disk sec/Transfer 一般来说,该数值小于15ms为最好,介于15-30ms之间为良好,30-60ms之间为可以接受,超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)