与系统 性能相关的 常见十个瓶颈 说明
2013-09-04 21:54
239 查看
在网上看到的一篇Blog,原文链接如下:
http://highscalability.com/blog/2012/5/16/big-list-of-20-common-bottlenecks.html
需要翻墙才能打开这个链接
具体的列表如下:
2. Long & short running queries
3. Write-write conflicts
4. Large joins taking up memory
2. Network I/O fluctuations in thecloud
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
2. Random disk I/O -> diskseeks
3. Disk fragmentation
4. SSDs performance drop once data written is greater than SSD size
2. TCP buffers too small
3. File descriptor limits
4. Power budget
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.
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
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
2. Development time
3. Team size
4. Budget
5. Code debt
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
http://highscalability.com/blog/2012/5/16/big-list-of-20-common-bottlenecks.html
需要翻墙才能打开这个链接
具体的列表如下:
一. Database:
1. Working size exceeds available RAM2. Long & short running queries
3. Write-write conflicts
4. Large joins taking up memory
二.Virtualisation:
1. Sharing a HDD, disk seek death2. 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 access2. 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 up2. 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 overload2. 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% CPU2. 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 time2. Development time
3. Team size
4. Budget
5. Code debt
十.Memory:
1. Out of memory -> killsprocess, go into swap & grind to a halt2. 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
相关文章推荐
- 与系统 性能相关的 常见十个瓶颈 说明
- 与系统 性能相关的 常见十个瓶颈 说明
- 与系统 性能相关的 常见十个瓶颈 说明
- 与系统 性能相关的 常见十个瓶颈 说明
- 与系统 性能相关的 常见十个瓶颈 说明
- JVM 性能调优实战之:一次系统性能瓶颈的寻找过程二
- 转载Linux系统下常见性能分析工具的使用(南非蚂蚁出品~~)
- 某系统响应时间慢TPS低性能瓶颈调优过程
- 系统性能优化的常见八大误区
- [置顶] JVM 性能调优实战之:一次系统性能瓶颈的寻找过程
- linux/unix系统时间相关的结构体及其说明
- 转:LoadRunner负载测试之Windows常见性能计数器,分析服务器性能瓶颈
- JVM 性能调优实战1:一次系统性能瓶颈的寻找过程
- 【转】基于GeoServer的电子地图系统说明(二):WebGIS相关的OpenGIS规范
- [56] 测试技术常见的十一种问题之四:什么是系统瓶颈?
- 软件开发中常见的十大系统瓶颈
- 系统性能瓶颈分析
- debian系统性能查看相关命令