大多我們運用的工具都會提到乙個共同的問題------效能調優。什麼是效能調優，每個人都有自己的乙個定義，我比較喜歡的乙個定義就是：效能調優就是盡力去消除系統中存在的效能瓶頸。這是乙個迴圈往復的過程，首先找到效能瓶頸，然後採取各種方法盡力消除它，然後尋找下乙個效能瓶頸，然後消除它，迴圈往復，直到效能達到預期目的為止。比較喜歡這個定義在於它告訴我們，效能調優沒有乙個最終的答案，每一次優化只要達到我們的期待的結果即是優化完成。
效能優化應該從整個系統上去規劃，使系統能有乙個理想的效能平衡。換句話說就是使系統中的各個部分：應用軟體、資料庫、硬體資源共同達到乙個效能的最優化，讓各部分資源能用自己最擅長的一面最大程度的提公升系統效能，最終達到乙個系統級的效能平衡。
在此我們將對informatica效能優化做乙個系統的介紹，而其中也在一定程度上運用系統效能平衡的規則進行調優指導。在此我們將按調優的乙個通用的順序進行介紹，或者說是乙個調優guideline, 即首先定位效能瓶頸，其次進行效能調優，最後介紹一些調優經驗。
一、
效能瓶頸
效能調優時，首要的任務即是確定效能的瓶頸所在。在對informatica進行瓶頸確定時，我們應首先排除是否特殊情況，即從當時網路、資料庫、伺服器是否執行正常、是否忙等情況排除，當確認是普通情況後，我們便可以按以下步驟進行效能瓶頸確定。
1．
target
確定瓶頸是否發生在etl中的l上。
在做informatica調優過程中，我們發現絕大部分的系統瓶頸都會發生在
informatica的寫目標資料庫這個過程中。對於我們大部分的系統來說，我們的目標均是資料庫系統，此時我們可以在session中將目標寫方式直接改為file writer，而此時如果系統效能得到了顯著的提高，那我們可以確定寫target是我們的乙個系統瓶頸。而如果系統效能沒有什麼提高，那說明寫target不是瓶頸，需要從其它方面確定瓶頸。
thoughput 這是乙個結果值, 它是每秒l的條數, 但並不代表l的performance.問題.
2．
source
確定瓶頸是否發生在etl中的e上。
當確定寫target不是系統瓶頸後，我們可以檢視是否瓶頸發生在讀時。我們可以按以採用以下幾種方法來進行確定。
1）在每個source qualifier後增加乙個filter transformation，並把condition設定為false.，並比較修改前後的執行時間，如果前後執行時間沒有什麼變化，則我們可以確定讀source是瓶頸。
4）throughput(rows/sec)
3．
確定瓶頸是否發生在etl中的t上。
當我們經過l，e兩個過程的確認後都沒有發現瓶頸問題，或者說這兩個部分
的效能調優存在很大的困難或者需要很大的代價，我們可以考慮進行t的效能調
設定performance detail只需要在session屬性中選中collect performance data選項，此時在workflow monitor中可以看到執行的詳細情況，且這個統計的詳細資訊也會被存為log檔案。
這個統計資訊在調優過程中主要用於aggregatorrank、lookup、joiner的效能瓶頸確定。
當設定了該選項後，我們可以看到執行過程中，workflow monitor在
以aggregator為例簡單介紹一下如何從performance detail中找出效能瓶頸。
主要看其readfromdisk / writetodisk的指數，如果這些值大於0，我們可以調整index /data cache size，使其減少並趨向於0。newgroupkey指informatica總共建立的group數，oldgroupkey則指informatica使用已建立group的次數。而這個次數也從另一方面指示了我們使用index cache的次數。理論上來說當然是希望new值越小越好，old越大越好，這個值主要是受我們設定的group by欄位影響，所以這個值的調優需要結合業務需求，選擇最優的group by欄位。
4．
session
當我們完成了l、e、t的瓶頸確認後，如果還需要進一步的尋找調優的可能，
那就是session級的瓶頸確定了。
而session級的調優主要是對session的引數的調整，以期達到進一步調優的效果。其中主要涉及到以下幾個引數。
這幾個引數每個引數的意義及其調優方式，將在下面調優過程中進行說明。
5．
system
利用一些系統監控工具監控系統效能。整體對硬體、作業系統、資料庫系統、
網路等進行系統級調優。在此不作具體說明。
二、
系統調優
1.效能平衡
效能平衡的調優更多的是需要靠經驗及系統的熟悉進行調優。需要熟知系統所
2.
target
當我們確定了系統瓶頸在寫target後，我們可以按以下步驟進行調優：
1）、drop index and key constraint
我們知道當目標表存在index和key constraint時，會很大程度上影響我們load的效能，而對此情況我們可以採用使其在load的過程中失效的方式來提公升效能。
2）、use bulk loading
bulk 方式進行目標資料的load，是informatica提供的一種高效能的load資料方式。它利用資料庫底層機制，依靠呼叫資料庫本身提供的utility來進行資料的載入。
使用bulk方式load時，informatica呼叫utility進行load，此方式將繞過資料庫的log記錄，以此來提高資料庫load效能，因此bulk方式也就不可能進行rollback操作，也不可能使用資料庫作recover操作。所以當進行這個屬性設定時，需用平衡一下效能提公升與系統資料恢復的重要性。
從bulk的實現方式上我們即可以知道，bulk方式主要是進行大資料量insert的操作時選用，換句話說就是不做update。當設定了這個選項後，informatica sever實際是呼叫了資料庫的bulk utility 並忽略log進行載入的。所以在這兒對bulk方式也可進行調優設定，這就是我們需要調整的「事務提交數」了。commit interval的預設值是10000。所以可以調大這個值，以減少事務數(bulk load transaction)，提公升效能。需要說明的是這個調整只對oracle和sql sever有用。db2 和sybase不受這個值影響，只與write block的大小有關係，一旦寫滿即進行提交。
因為bulk方式只能用來做insert操作。而大家知道我們如果需要update操作，在session的treat source rows as的設定上需要設定成data driven，當我們同時選擇了兩種設定，會有什麼結果呢。如果你同時設定了data driven和bulk模式powercenter sever將自動切換採用normal 方式進行load。
預設bulk到normal設定. workflow manageràtoolsàoptionsàmiscellaneousàtarget load type ( session log)
3）、use external loading
上面我們所提到的load方式均是指relational connetion方式下的調優。而除了在此基礎上的調優，我們也可以直接利用資料庫的loader 工具並選用informatica的external load方式進行資料的load。
oracle版本不同需要。修改sqlloadàsqlldr.exe
increase commit intervals
row per commit à10000 ( session log)
只作insert操作, 發生約束衝突將失敗. 或者disable constraints.
4）、optimize oracle database
在完成這些操作後，如果需要進一步調優，可以考慮對資料庫效能的調優。而資料庫效能的調優將主要由dba完成，在此不作多的說明。
informatica調優（高階）
根據常理，這些高階建議放在最後，並且是在系統級上的建議。還有其他的適用於資料倉儲調優的高階建議，可以依據你的軟硬體資源存在的問題去尋找相應的幫助。5 改變網路包的大小 對於sybase sql server oracle的使用者 最大的網路包的大小是資料庫的設定，通常是512位元組或者是1024位元...
調優 Nginx效能調優
一.nginx優化配置 1.主配置檔案優化 注 部分配置詳解 worker processes 8 nginx程序數，建議按照cpu數目來指定，一般為它的倍數。worker cpu affinity 00000001 00000010 00000100 00001000 00010000 00100...
Spark效能調優 JVM調優
通過一張圖讓你明白以下四個問題 1.jvm gc機制，堆記憶體的組成 2.spark的調優為什麼會和jvm的調優會有關聯？因為scala也是基於jvm執行的語言 3.spark中oom產生的原因 4.如何在jvm這個層面上來對spark進行調優 補充 spark程式執行時 jvm堆記憶體分配比例 r...