与系统 性能相关的 常见十个瓶颈 说明

在网上看到的一篇Blog,原文链接如下:

http://highscalability.com/blog/2012/5/16/big-list-of-20-common-bottlenecks.html

需要翻墙才能打开这个链接

 

具体的列表如下:

  

一. Database:

1.       Working size exceeds available RAM

2.       Long & short running queries

3.       Write-write conflicts

4.       Large joins taking up memory

 

二.Virtualisation:

1.       Sharing a HDD, disk seek death

2.       Network I/O fluctuations in thecloud

 

.Programming:

1.       Threads: deadlocks, heavyweightas compared to events, debugging, non-linear scalability, etc...

2.       Event driven programming:callback complexity, how-to-store-state-in-function-calls, etc...

3.       Lack of profiling, lack oftracing, lack of logging

4.       One piece can't scale, SPOF,non horizontally scalable, etc...

5.       Stateful apps

6.       Bad design : The developerscreate an app which runs fine on their computer. The app goes into production,and runs fine, with a couple of users. Months/Years later, the applicationcan't run with thousands of users and needs to be totally re-architectured andrewritten.

7.       Algorithm complexity

8.       Dependent services like DNSlookups and whatever else you may block on.

9.       Stack space

 

.Disk:

1.       Local disk access

2.       Random disk I/O -> diskseeks

3.       Disk fragmentation

4.       SSDs performance drop once data written is greater than SSD size

 

.OS:

1.       Fsync flushing, linux buffercache filling up

2.       TCP buffers too small

3.       File descriptor limits

4.       Power budget

 

六.Caching:

1.       Not using memcached (databasepummeling)

2.       In HTTP: headers, etags, notgzipping, etc..

3.       Not utilising the browser'scache enough

4.       Byte code caches (e.g. PHP)

5.       L1/L2 caches. This is a hugebottleneck. Keep important hot/data in L1/L2. This spans so much: snappy fornetwork I/O, column DBs run algorithms directly on compressed data, etc. Thenthere are techniques to not destroy your TLB. The most important idea is to havea firm grasp on computer architecture in terms of CPUs multi-core, L1/L2,shared L3, NUMA RAM, data transfer bandwidth/latency from DRAM to chip, DRAMcaches DiskPages, DirtyPages, TCP packets travel thruCPU<->DRAM<->NIC.

 

.CPU:

1.       CPU overload

2.       Context switches -> too manythreads on a core, bad luck w/ the linux scheduler, too many system calls,etc...

3.       IO waits -> all CPUs wait atthe same speed

4.       CPU Caches: Caching data is afine grained process (In Java think volatile for instance), in order to find theright balance between having multiple instances with different values for dataand heavy synchronization to keep the cached data consistent.

5.       Backplane throughput

 

八.Network:

1.       NIC maxed out, IRQ saturation,soft interrupts taking up 100% CPU

2.       DNS lookups

3.       Dropped packets

4.       Unexpected routes with in thenetwork

5.       Network disk access

6.       Shared SANs

7.       Server failure -> no answeranymore from the server

 

九.Process:

1.       Testing time

2.       Development time

3.       Team size

4.       Budget

5.       Code debt

 

.Memory:

1.       Out of memory -> killsprocess, go into swap & grind to a halt

2.       Out of memory causing DiskThrashing (related to swap)

3.       Memory library overhead

4.       Memory fragmentation

5.       In Java requires GC pauses

6.       In C, malloc's start takingforever

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值