转自http://www.csdn.net/article/2012-11-08/2811571-Big-List-Of-20-Common-Bottlenecks
数据库
- 工作任务内存超过可用的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总是开始分配内存）