常见的20种“瓶颈”（性能问题）

转自：http://www.bsdmap.com/2012/12/29/big-list-of-20-common-bottlenecks/

常见的20种“瓶颈”

本文原文来自 High Scalability——介绍了常见的20种“瓶颈”，取主要部分意释过来，加上自己的理解，算是一篇“读书笔记”。

常见的20种“瓶颈”如下所陈：

1 数据库

• Working size超过可用内存
  • Working Size怎么理解？肯定不是指数据库的大小，应该是在保证业务指标——响应时间、QPS的情况下，数据库使用的内存大小。其超过可用内存后的直接影响就是系统开始使用“swap”，从而大大降低DB的性能。所以，DB服务器要有充足的内存。
• 长查询和短查询
  • 指运行时间很长和很短的查询。运行时间很长的查询，要是么很消耗内存、CPU，比如联合查询，要么是很消耗磁盘I/O，比如没有用到索引的“遍历”——这应该算是“事故”。长查询对“DB性能”的影响是显而易见的。
  • 短查询，我可能理解有误，咨询了我们的DBA，认为大概是“短连接”的意思。DB的连接，也是消耗资源的，大约每个2M内存的样子，所以，Java使用“连接池”来避免频繁连接数据库。当短连接并发过多的时候，建议改用“长连接”来避免不必要的开销，提代高性能。
• 写冲突（需要用锁的场景）
  • 写冲突的场景，通常会遇到“锁”，如MyISA的“表锁”，与InnoDB的“行锁”，当遇上“锁”时，只能有一个“用户”在写，其他用户均需要等待。当有大量的冲突时，用户需要等待的时间就越长，“锁”机制会导致CPU的有效利用率大大下降——花在“获取锁”上的CPU时间变多，从而导致DB可用的有效CPU时间变少，性能下降。
• 大量的Join操作消耗内存
  • Join操作本身比较消耗内存和CPU，尽可能不用或少用。

2 虚拟化

• 共享磁盘，磁盘随机读严重
  • 虚拟化场景，使用共享磁盘（HDD），磁盘会成为瓶颈。磁盘差不多是计算机上最慢的设备了。随机I/O能力极差。
• 网络I/O波动
  • 因为虚拟化场景同一台物理机上的多个VM之间的网络是共享的，会互相影响。

3 程序

• 线程：死锁，与“事件驱动型”（方案）相比过重，debug，非线性扩展，等等
• 事件驱动编程：回调的复杂度，如何保存函数状态，等等
• 缺乏“profiling”、跟踪、日志机制。
• 耦合严重，单独故障，不可水平扩展，等等
• 有状态的应用（不易水平扩展）
• 糟糕的设计：开发都开发了一个程序，在自己的电脑上运行良好；到了生产环境，对于两三个用户，也运行良好。等到数月、数年过后，用户量上来以后，程序不能运行了，需要重构、重写。
• 算法复杂性
• 依赖其他服务，比如DNS查询以及其它，你可会被阻塞。
• 栈空间

4 磁盘

• 本地磁盘访问
• 随机磁盘I/O（引发大量磁盘寻道）
• 磁盘碎片（增加寻道机会和时间）
• 当写入数据量超过SSD空间量以后，SSD性能的下降

5 操作系统

• Fsync flushing, linux buffer cache filling up
• TCP Buffer过小
• 文件句柄限制
• 功率分配（CPU节能？）

6 缓存

• 不使用Memcached(数据库前端)
• HTTP：headers,etags，不压缩，等等
• 不充分利用浏览器的缓存
• 字节码缓存（比如PHP的APC）
• 处理器的L1/L2缓存：这是一个重要的“瓶颈”。保持重要的热数据在L1/L2缓存中。这个关系到方方面面太广，

7 处理器

• CPU超载
• 上下文切换->一个核上太多线程，这可能是因为“坏运气”或者是Linux调度器；太多系统调用，等等
• I/O等待->所有CPU以相同的速度在等待（同时等待）
• CPU缓存：未完……
• 主板能力（其它限制CPU性能的因素）

8 网络

• 网卡最大带宽，IRQ饱和，软中断用光CPU资源
• DNS查询
• 丢包
• 意外路由
• 网络磁盘访问（比如NFS, drbd）
• 共享SANs
• 服务故障->服务不响应

9 进程

• 测试时间
• 程序调试时间
• 团队大小
• 预算
• 代码“欠债”

10 内存

• OOM->杀进程，使用交换甚至导致死机
• OOM导致磁盘超负荷（因为swap）
• 内存管理库极限
• 内存碎片
  • Java中会导致GC停顿，速度变慢
  • C中，导致malloc()分配内存变慢