寫在前面
其實誰也不敢保證自己管理的系統（系統平臺）性能是否極好
關於很多對系統性能優化的資料都在表達一個問題：怎樣在業務高度增長的同時儘可能的合理優化資源的消耗？如何保證用戶的響應速度和服務質量？如何使有限的計算機系統資源爲更多的用戶服務？這似乎是一個矛盾的集合，然而矛盾的關鍵就在於“合理優化”上。
一套完整的信息系統平臺我認爲重點涉及到數據庫、操作系統、網絡 三個方向
下面我根據並不豐富的工作經驗談談我對 系統性能優化的理解（僅針對在線系統環境）。
數據庫優化方面
如何保證數據庫運行在最佳狀態，個人覺得在系統開發之前就該提前想到數據庫的優化策略，比如一張表達到T級，邏輯備份時間超過檢修窗口規定時間。這就是一個典型的例子。
對於數據庫的優化策略大概包括，數據庫參數調整，網絡性能調整 應用程序sql語句分析設計等幾個方面。（還有很多方面此處略）
關於數據庫指標性的問題大概分爲數據庫吞吐量、數據庫用戶響應時間。
數據庫用戶響應時間=系統服務時間+用戶等待時間。所以解決用戶的響應時間問題的基本兩個方向即：
1減少系統服務時間，也就是提高數據庫的吞吐量。
2是減少用戶的等待時間，也就是減少用戶訪問同一個資源的衝突率。
數據庫性能上的優化具體細節可以概括成下面幾個設計方向：
1.調整數據結構的設計，比如提前考慮是否使用分區表，對於經常訪問的數據是否需要建立索引
2.調整sql語句設計， 應用程序執行最終將變爲數據庫中的sql語句執行，所以sql語句的執行效率也就決定了數據庫的性能
3.程序設計，這部分的工作應該在開發系統之前就應該完成，比如我們要考慮應用程序使用什麼樣的體系結構，是傳統的C/S還是 B/W/D，因爲不同的應用程序體系結構要求的數據庫資源是不一樣的
4.系統內存分配設計，這部分應該是在系統運行過程中不斷的優化，比如根據數據庫運行的狀況不僅可以調整數據庫系SGA的數據緩衝區 日誌緩衝區和共享池的大小，當然大小作爲DBA會根據經驗判斷到底給多大合適，例如小庫200M，中庫200-400，大庫400-700M，一般shard_pool_size 設置不到1G （實際環境參數設置是不一樣的）
5.調整硬盤I/O 比如在系統上線之前我們可以把組成同一個表空間的數據文件放在不同的磁盤上，實現硬盤之間的I/O負載均衡
6.調整OS的系統參數 比如可以調整UNIX數據緩衝區的大小,每個進程能使用的內存大小等參數
實際生產中 數據庫性能惡化從用戶的角度上看，基本表現爲用戶響應時間過長（太卡），需要用戶等待很長的時間，典型例子12306。但是造成惡化的原因卻是多種多樣，有時是多種因素共同造成
在我看來數據庫應該關注兩個重點指標：速度和吞吐量，即儘可能地縮短響應時間和同等吞吐量的基礎上儘可能的提高負載能力
具體措施：
1.如果設計完善，可以避免很多優化問題，例如儘量減少不必要的表連接，這樣可以大大的提高應用程序可用性
2.磁盤規劃,對磁盤性能的監控非常重要，前提是在系統上線之前就對數據量進行預判，目的是使恢復時間更短，數據訪問更快
3.對新添加的應用程序進行跟蹤監控，新上線的模塊會導致數據庫工作量發生變化，性能問題也會隨之而來
4.對在線系統運行過程中的優化，比如定期查看報表，可以根據累計的報表數據和系統平臺上線之前的設計思路很容易找出業務增長規律，主要爲了找到性能瓶頸，要麼提前預防要麼加以解決，典型反面教材又是12306
以上措施針對的細節舉例如下：
僅列舉我能想到的問題
性能調優的問題：
1、壞的回話管理，比如一次查詢多次連接，會消耗資源
2、壞的遊標的管理，防止同一個sql進行不同的書寫方式 比如綁定變量的用途
開發階段的調優：
1、調節設計是否合理
2、檢查sql語句是否正確，寫的好不好
3、調節內存
4、調節 I/O
5、調節熱點塊
投產的系統階段的調優：
1、定義問題（現象的產生，例如CPU暴漲）
2、收集操作系統和oracle的指標（sql命中率，buffer cache比例等）
3、考慮常見的性能錯誤（這是經驗活）
4、假定一個概念，就是猜想問題的根源（在測試庫上實驗）
5、嘗試去解決問題 （測試庫上實驗）
6、檢查這個解決問題的方式是否合適（長期觀察）
調優的經驗：
1、檢查日誌
2、檢查參數是否正確
3、查看系統的I/O和內存的利用率，確定那個進程佔用做多
4、檢查那個sql語句大量的佔用cpu和i/o （比如模塊設計不合理）
如果用戶感覺時間很慢 （觀察statspack）
1、要分明白具體幹活的時間和等待資源的時間那個慢
2、檢查那部分事件佔用時間最多
3、把每隔事件在進一步細化
系統的安全性和性能的平衡度
1、如果控制文件很多會導致性能下降，但是會很安全。
2、redo成員多個
3、頻繁的產生檢查點
4、備份數據文件的時候
5、alter system switch logfile（影響很大,數據量越大延遲越大）
6、用戶事物的併發量
關於安全性和性能的取捨oracle常見的例子比如，利用DG實現的容災，要麼就犧牲兩倍日誌寫速度採用maximum protection模式換來安全，要麼擔着不能絕對保證數據完全一致的風險選擇maximum availability模式換來容災上的性能提升，然而生產環境完全根據實際情況而定，無法兼得。
針對數據庫方面的優化遠不止這些，所以在未來的工作中會有大量的可預測及不可預測的問題出現
操作系統方面的優化（僅根據以往接觸的工作進行闡述）
有一句話比較贊同，假設通過對系統的調優使其性能提升了50%（或者更高）那麼可以基本判斷當初設計這個系統的時候就存在非常大的問題。系統問題最直接的表現爲“運行遲緩”但是產生運行遲緩的原因多種多樣，不過大體概括問幾個方面
1.進程太多，操作系統可能僅僅只是同時運行了太多的應用程序，或者正在運行CPU 密集型的操作。或者是服務器超負荷運行，也可能是某一個進程耗盡了大量的系統資源等等，典型例子比如又是12306，其前端設計被罵了無數次
2.活動內存太多，假設某一個進程使用了大量的內存，那麼系統可能會從磁盤換入大量的頁面並將大量的頁面換出到磁盤，這意味着系統花費在內存交換上的時間比真正使用內存的時間更多，又一次彰顯了緩存服務器的重要性
3.硬件故障，有時候會碰到莫名其妙的硬件故障導致其他服務器組件工作不正常導致系統花費很長的時間等待信息，舉一個曾經遇到的問題，HA高可用集羣跑在vmware虛擬平臺上,但是無論如何CMAN也無法啓動，光處理這個問題就花費了大量的時間和精力。
針對以上問題用到的工具
vmstat工具來監視虛擬內存統計信息
top觀察活動的進程、負載以及內存統計信息
uptime觀察平均負載
ps 觀察相關進程
Nagios 自動化運維必不可少的工具,可以對進程 cpu 負載 硬盤進行監控 並可自行設置閥值進行報警,優勢不言而喻
出現問題的系統很可能和採集到的統計信息之間並不存在直接關係，但收集的統計信息越多，對問題的定位就越精確。（經驗活）
網絡方面的優化（ISP方面）
僅根據自身經驗進行闡述，網絡性能問題直接影響到出口鏈路，可以比喻成數據還沒進家門就死外面了...
每一個針對業務的數據機房想必都遇到過以下問題
網絡核心應用如何保障？
如何進行業務優先級劃分？
實際環境中整個帶寬應用，P2P下載+網絡電視+WEB視頻流量超過80%以上（ISP運營商與校園業務類似基本如此）。而在覈心網運維的過程中，主要面臨的問題如下：
交付延遲：應用交付的響應超時，數據損失
網絡帶寬：對於終端用戶和應用程序遠遠不夠實際需求，併發請求往往超過出口鏈路的承載能力。
應用程序：不斷增加的應用程序搶佔有限的帶寬資源，成倍增長的數據量已給核心業務交付帶來困境。
傳統管理的方式：
1.無法瞭解寬帶網絡應用和用戶習慣，無法建立流量模型。網絡出口升級頻繁，卻趕不上流量增長速度。導致網絡出口升級毫無科學依據（間接的表現就是運營成本大幅度增加也無法滿足業務需求）。
2.P2P、病毒和垃圾郵件以及不良信息充斥網絡中，無法避免帶寬濫用。並且成本高昂。
根據當前網絡寬帶業務的發展趨勢，用戶的行爲越來越多樣化並且難以控制，越來越多的應用開始搶佔帶寬：如P2P ，PPLIVE QQlive等視頻點播業務。這甚至讓傳統的瀏覽網頁的應用也受到了嚴重影響。
針對以上面臨的問題採取的優化措施：
單純通過網絡層面的控制（數據包控制）已經完全無法滿足實際問題 比如大多數路由器都有的CBQ隊列緩存機制（實際上作用不大，基本控制不住P2P氾濫）
所以針對面臨的實際問題只能通過抓包(流控設備從新設計了此功能)來識別需要控制的協議。有意思的是，P2P協議族本身就是雙刃劍，他爲了保證高速傳輸通常會進行"端口跳躍"來躲避監控設備的協議識別，舉一個曾經遇到的問題，監控報警提示定義的視頻數據流暴漲通過，我們用過協議識別較差的審計設備觀察暴漲的流量發現竟然是QQ或者是某些私有協議(比如ERP等)。在這裏插一句，根據自身經歷個人覺得，大多數審計產品集成了流控功能，這是噱頭，想達到協議識別精度和內容審計精度這基本不可能，至少國內尚未出現，比如某些廠商的設備明明寫着承載併發30W，但是壓力測試發現基本上跟指標相差甚遠
在網絡性能優化上，大多數辦法是在出口鏈路上部署基於DPF和DFI技術的流控產品來實現。(關於產品，國內產品這個領域成熟產品有很多。如Panabit,網康,深信服,天融信,華爲等等)
此處需要解釋一下爲何不通過WEB端(WEB服務器)來控制非正常高峯流量而必須通過在鏈路出口部署流控設備進行流量控制來達到實現網絡優化的目的。
通過對某些廠商技術白皮書的理解我認爲原因如下：
通過WEB端進行流控主要運用了兩種辦法
1.TCP滑動窗口技術
2.調整配置文件參數達到會話數和連接數的控制。
那麼以上兩種辦法的好處是什麼？
比如，有一臺WEB服務器，用戶向服務器發起請求打開一個頁面，該頁面包含了8，000字節信息，標準TCP窗口爲16K，所以當服務器接收到請求後，16K的數據就會向用戶發送到。假設鏈路每毫秒可以傳輸100個字節，也就是說需要160毫秒用來傳輸這些頁面，在傳輸的過程中，任何其他的流量都需要等這些頁面傳輸完成後纔可以處理，也就是說在此網絡中整體會有160毫秒的延時。
基於TCP滑動窗口技術，將TCP窗口改爲32，000。那麼服務器發送8，000字節的數據給用戶，只需要80毫秒就可以傳輸完成，比沒有使用TCP窗口控制時節省了80毫秒，以此減少網絡的延時。
但是實際的需求往往沒有這麼簡單,首先控制TCP窗口並不代表控制每個用戶，因爲每個用戶都可以建立多個實時併發連接，比如一個用戶可以在瀏覽器中打開多個頁面，對每一個頁面產生的連接進行TCP窗口控制，僅僅能保證此用戶建立的每個連接受到控制而不是帶寬受到控制，而流控真正需要做的是讓每個用戶使用的帶寬不能佔用過多並且不能佔用
其他人的帶寬。
再者，使用TCP窗口控制，對於每個TCP的連接都需要分步進行調整，也就是說，每一個數據流都要進行監控，每個ACK包都需要延時，每個IP頭都需要重建，另外控制TCP的窗口將導致網絡中出現大量的小包（1500字節），因爲1500字節數據包是保證網絡沒有延時的最小數據包.這就解釋了在複雜生產環境下(ISP級)基於會話數/連接數和TCP滑動窗口技術無法有效抑制網絡擁堵的原因。如果在出口鏈路上無法控制P2P的泛濫，那麼當數據到達應用層很容易導致服務器癱瘓，數據庫也一樣，皮之不存毛將焉附！
關於系統性能上的優化我來大膽的舉一個例子：
鐵道部花了3億的RMB用來幫助IT同行們學習先致敬一下，然後在拿12306開刀。
查了一下資料，12306的網站使用的是J2EE架構，具體WEB服務就不清楚了，數據庫應該是ORACLE。下面我來分析一下，如果有優化我覺得從下面幾個問題考慮：
1,系統架構設計問題，說一個常見的架構方式，HTTP服務器做業務請求，WEB調用中間件,操作系統用AIX，數據庫用ORACLE，應用服務器通過集羣組承載龐大的業務請求。假設用戶發出的請求是先找車次(查詢操作)，再看餘票的信息，然後購買，那麼可以可以通過根據IP進行負載均衡處理這些事務，並把業務請求分發到各個節點上，可以通過CDN加速分發到各個節點，實現動態請求，讓真正的事務在節點上完成。這樣，在處理請求的時候就減輕主服務器的壓力，實現均衡的目的。
2,大併發的處理問題，系統設計之初就應該設計成容納最大的併發數，儘可能的防止用戶的訪問產生堵塞，當然多少併發都未必真能阻止堵塞，那麼在設置上就可以採用隊列機制，
但是，水漲船高面臨這個問題首先應該估算今年通過網絡形式購票的人數，這個計算方法
我覺得應該是比較成熟的，通過估算出的數據可以算出高峯訪問量和併發量的預計值。另外，根據整個訂票流程，可以分析出系統本身哪一個事務操作可能造成大併發操作，比如說，查詢完不提交(實際上,沒有誰會着急付錢啊)很容易造成數據鎖定，最後大家都卡在那。
3,由於12306比較特殊(官方話)那麼針對這個系統就需要一個龐大的數據庫，首先調用的數據過程能通過緩存就走緩存，通過內存的交互提高訂票的速度。這有個非常實際的例子
比如我買票，我可能會長時間的查詢，對於系統來說這張被查閱的票就被鎖定，導致其他用戶無法購買，也就是我沒有付錢，沒有提交，對於用戶來說是好的，但是誰也不能保證付款時間，如果大量用戶同時做這種事務，那麼就產生了大量的訪問，在數據庫看來付款成功率下降，用戶訪問量大量增加。那麼針對這種情況訂票流程就需要設計相應的應對機制。
所以綜上所述，實際生產環境的系統性能優化我個人覺得用一句話概括
“橫看成嶺側成峯，遠近高低各不同”
但是，從架構，業務邏輯，客戶產生的數據等等方面卻都有着相似之處，歸根結底就是三個字：經驗活！