在Zen And The Art Of Scaling - A Koan And Epigram Approach中，Russell Sullivan提出了一个非常有趣的总结：软件开发常见的20个传统的系统瓶颈，这听起来像是说有20个故事情节，并且依赖于你如何策划这些故事，或许都是真的，但唯有实践才知道它们带给我们的酸甜苦辣。
　　有一天，Aurelien Broszniowski给我发了一份电子邮件，把这些瓶颈用列表的方式展示出来。在接下来的交谈过程中，我又把该列表抄送给了Russell，Russell对此列表进行了整理。
　　Russell说：“我真希望在年轻时看到这样的一份列表”。伴随着经验的增长、项目的增多、解决各种不同类型的问题和不断总结各种经验教训，你会在这份列表上添加更多的东西。所以，当你在阅读该份列表时就像是在回顾一个个故事片段。
　　数据库
　　工作任务内存超过可用的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总是开始分配内存)
     咨询信息：QQ 707552864  谢老师