Ten bottlenecks related to system performance

 

The original Article link of a blog posted on the internet is as follows:

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

 

You need to flip the wall to open this link. As an IT technician, turning over the wall is a required skill. Some common performance-related bottlenecks are listed in this blog, but they are not described separately. However, each point is worth studying.

 

The specific list is as follows:

I. database:

1. Working size exceeds available Ram

2. Long & short running queries

3. Write-write conflicts

4. Large joins taking up memory

 

Ii. virtualisation:

1. Sharing a HDD, disk seek death

2. Network I/O fluctuations in thecloud

 

Iii. 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-cals, 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 specified screate 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-ubuntured andrewritten.

7. algorithm complexity

8. dependent services like dnslookups and whatever else you may block on.

9. Stack space

 

Iv. 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

 

V. OS:

1. fsync flushing, Linux buffercache filling up

2. TCP buffers too small

3. file descriptor limits

4. Power budget

 

6. 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.

 

VII. CPU:

1. CPU overload

2. context switches-> too manythreads on a core, bad luck w/the Linux scheduler, too using system CILS, 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

 

8. 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

 

9. Process:

1. Testing time

2. Development Time

3. team size

4. Budget

5. Code debt

 

10. 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

 

 

 

 

 

 

Bytes -------------------------------------------------------------------------------------------------------

Skype: tianlesoftware

QQ: tianlesoftware@gmail.com

Email: tianlesoftware@gmail.com

Blog: http://www.tianlesoftware.com

WEAVER: http://weibo.com/tianlesoftware

Twitter: http://twitter.com/tianlesoftware

Facebook: http://www.facebook.com/tianlesoftware

LinkedIn: http://cn.linkedin.com/in/tianlesoftware

 

 

------- Add a group to describe the relationship between Oracle tablespace and data files in the remarks section. Otherwise, reject the application ----

Dba1 group: 62697716 (full); dba2 group: 62697977 (full) dba3 group: 62697850 (full)

Super DBA group: 63306533 (full); dba4 group: 83829929 dba5 group: 142216823

Dba6 group: 158654907 dba7 group: 172855474 DBA group: 104207940