常见的10种“瓶颈”

1 数据库
Working size超过可用内存
Working Size怎么理解？肯定不是指数据库的大小，应该是在保证业务指标——响应时间、QPS的情况下，数据库使用的内存大小。其超过可用内存后的直接影响就是系统开始使用“swap”，从而大大降低DB的性能。所以，DB服务器要有充足的内存。
长查询和短查询
指运行时间很长和很短的查询。运行时间很长的查询，要是么很消耗内存、CPU，比如联合查询，要么是很消耗磁盘I/O，比如没有用到索引的“遍历”——这应该算是“事故”。长查询对“DB性能”的影响是显而易见的。而短查询呢？
写冲突（需要用锁的场景）
写冲突的场景，通常会遇到“锁”，如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()分配内存变慢