性能調優從哪裏入手

      說到性能調優，給人的感受每每都是修煉有成的專家幹得事了，對於咱們這些菜鳥仍是想也不要想了，作好份內事，不出現紕漏就OK了。對於這種觀點我表示嚴肅的否決！那想學習性能調優的童鞋應該從哪裏下手呢？接下來就讓咱們來談談關於性能調優你所忽視的一些常識。

　　1、代碼；
前文講過「華爲Java編程軍規，每季度代碼驗收標準」這個標準是衡量代碼自己的缺陷，也是衡量一個研發人員自己的價值。代碼是性能調優中的一粒分子，分子雖小但通過上億次的分裂也會變成黑洞，因此代碼自己的缺陷也是咱們性能調優的主因之一。

軍規一：【避免在程序中使用魔鬼數字，必須用有意義的常量來標識。】

軍規二：【明確方法的功能，一個方法僅完成一個功能。】

軍規三：【方法參數不能超過5個】

軍規四：【方法調用盡可能不要返回null，取而代之以拋出異常，或是返回特例對象（SPECIAL CASE object，SPECIAL CASE PATTERN）；對於以集合或數組類型做爲返回值的方法，取而代之以空集合或0長度數組。】

軍規五：【在進行數據庫操做或IO操做時，必須確保資源在使用完畢後獲得釋放，而且必須確保釋放操做在finally中進行。】

軍規六：【異常捕獲不要直接catch (Exception ex) ，應該把異常細分處理。】

軍規七：【對於if „ else if „(後續可能有多個else if …)這種類型的條件判斷，最後必須包含一個else分支，避免出現分支遺漏形成錯誤；每一個switch-case語句都必須保證有default，避免出現分支遺漏，形成錯誤。】

軍規八：【覆寫對象的equals()方法時必須同時覆寫hashCode()方法。】

軍規九：【禁止循環中建立新線程，儘可能使用線程池。】

軍規十：【在進行精確計算時(例如:貨幣計算)避免使用float和double，浮點數計算都是不精確的，必須使用BigDecimal或將浮點數運算轉換爲整型運算。】

注：「華爲Java編程軍規，每季度代碼驗收標準」詳見:http://www.cnblogs.com/Javame/p/3513670.html

　　2、基準；
基準環境，基準負載和基準指標，這是前提也是標準更是依據。沒有人能保證每次執行的指標就是真實有效的，今天提交個版本明天升級個環境這是咱們不能容忍的。怎麼才能基準？什麼又叫基準？正式的標準的穩定版本就是基準。也只有基準了，咱們才能發現問題。

　　3、硬件；
硬件環境的調整：主要是對系統運行的硬件環境進行調整，包括改變系統運行的服務器、主機設備環境（改用具備更高性能的機器，或是調整某些服務器的物理內存總量，CPU數量等），調整網絡環境（更換快速的網絡設備，或是採用更高帶寬的組網技術）等。

注：「工做經驗總結：百萬數據引起的性能瓶頸問題」http://www.cnblogs.com/Javame/p/3510641.html

　　4、系統；
系統設置的調整：主要是對系統運行的基礎平臺設置進行調整，例如，根據應用須要調整UNIX系統的核心參數，調整數據庫的內存池大小，調整應用服務器使用的內存大小，或是採用更高版本的JVM環境等；

注：推薦常有性能測試工具

      性能測試工具：LR、kylinPET

      系統監控工具：nmon 或Linux（top sar）等自帶命令

      強烈推薦：Spotlight.On.Oracle 很是不錯的工具，誰用誰知道! ^^

　　5、軟件；
應用框架的調整：主要是對應用實現自己進行調整，包括選用新的架構、採用新的數據訪問或是修改業務邏輯的實現方式等。

注：說到架構我如今正在研究阿里巴巴的Dubbo，有興趣的朋友能夠一塊兒探討探討。

「經過dubbo暴露接口調用方法，及基於zookeeper的dubbo涉及配置文件」http://www.cnblogs.com/Javame/p/3645481.html

「基於ZooKeeper的Dubbo註冊中心」http://www.cnblogs.com/Javame/p/3632708.html
「最近項目用到Dubbo框架，臨時抱佛腳分享一下共探討」http://www.cnblogs.com/Javame/p/3632473.html

     6、再說系統

ulimit -a 用來顯示當前的各類用戶進程限制。
Linux對於每一個用戶，系統限制其最大進程數。爲提升性能，能夠根據設備資源狀況，設置各linux 用戶的最大進程數，下面我把某linux用戶的最大進程數設爲10000個：

ulimit -u 10000

對於須要作許多 socket 鏈接並使它們處於打開狀態的 Java 應用程序而言，最好經過使用 ulimit -n xx 修改每一個進程可打開的文件數，缺省值是 1024。
ulimit -n 4096 將每一個進程能夠打開的文件數目加大到4096，缺省爲1024
其餘建議設置成無限制（unlimited）的一些重要設置是：

數據段長度：ulimit -d unlimited
最大內存大小：ulimit -m unlimited
堆棧大小：ulimit -s unlimited
CPU 時間：ulimit -t unlimited
虛擬內存：ulimit -v unlimited

　　
暫時地，適用於經過 ulimit 命令登陸 shell 會話期間。
永久地，經過將一個相應的 ulimit 語句添加到由登陸 shell 讀取的文件中， 即特定於 shell 的用戶資源文件，如：

1)、解除 Linux 系統的最大進程數和最大文件打開數限制：

    vi /etc/security/limits.conf
    # 添加以下的行
    * soft noproc 11000
    * hard noproc 11000
    * soft nofile 4100
    * hard nofile 4100

 

    說明：* 表明針對全部用戶
    noproc 是表明最大進程數
    nofile 是表明最大文件打開數

2)、讓 SSH 接受 Login 程式的登入，方便在 ssh 客戶端查看 ulimit -a 資源限制：
    a、vi /etc/ssh/sshd_config
       把 UserLogin 的值改成 yes，並把 # 註釋去掉
    b、重啓 sshd 服務：
       /etc/init.d/sshd restart
3)、修改全部 linux 用戶的環境變量文件：

vi /etc/profile
ulimit -u 10000
ulimit -n 4096
ulimit -d unlimited
ulimit -m unlimited
ulimit -s unlimited
ulimit -t unlimited
ulimit -v unlimited

/**************************************

有時候在程序裏面須要打開多個文件，進行分析，系統通常默認數量是1024，（用ulimit -a能夠看到）對於正常使用是夠了，可是對於程序來說，就太少了。

修改2個文件。

1./etc/security/limits.conf
    vi /etc/security/limits.conf
    加上：
    * soft nofile 8192
    * hard nofile 20480
2./etc/pam.d/login
    session required /lib/security/pam_limits.so

 

**********
    另外確保/etc/pam.d/system-auth文件有下面內容
    session required /lib/security/$ISA/pam_limits.so
    這一行確保系統會執行這個限制。
***********
3.通常用戶的.bash_profile
#ulimit -n 1024
從新登錄ok
-------------
對於solaris

其實在系統裏面有這樣一個命令ulimit，如下是ulimit -a執行的結果：

time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) unlimited
nofiles(descriptors) 1024
memory(kbytes) unlimited

 

其中nofiles就是文件描述符的變量值，該值受rlim_fd_cur這個參數的影響，能夠用ulimit -n number命令來修改。但無論怎麼改,程序仍然不能突破fd=256的限制。在Solaris Tunable Parameters Reference Manua這本書裏面能查到如下的資料：

A 32-bit program using standard I/O is limited to 256 file descriptors。
A 64-bit program using standard I/O can use up to 2 billion descriptors。
這也就是說32位的程序是沒有辦法突破這個限制的，只有64位的程序才能使用高達2億個文件描述符，SUN的軟硬件在很早之前就實現了64位的架構，如今惟一要解決的就是將程序編譯成64位程序，爲了生成64位程序,就必需要有64位的編譯器（其實不是這樣的）,若是你去www.sunfreeware.com下載64位編譯器gcc，網站上沒有特別註明是64位的gcc，可是會有個意外的收穫，就是該軟件的說明裏面註明了只要在用gcc編譯的時候加上-m64的option就能生成64位程序了。

因而用gcc -m64去編譯生成一個64位程序後，用ulimit -n 102400將number of fd設成很大的狀況下，全部問題迎刃而解，不再存在文件描述符不夠用的狀況。

在/etc/system文件設置rlimi_fc_max和rlim_fd_cur格式以下：

* set hard limit on file descriptors
set rlim_fd_max = 4096
* set soft limit on file descriptors
set rlim_fd_cur = 1024
命令ulimit使用格式以下：

usage: ulimit [ -HSacdfnstv ] [ limit ]
ulimit -a是顯示各參數的設置值，ulimit -n是用來設置fd的最大值的。
*************************************************

修改文件描述符限制

Solaris有兩個參數控制進程可打開的文件描述符：rlim_fd_max，rlim_fd_cur。前者修改是個硬設置，修改須要權限，後者是個軟設置，用戶能夠limit或者setrlimit() 修改，該值最大不能超過前者。通常咱們在/etc/system裏修改這兩個參數

set rlim_fd_max = 65535

set rlim_fd_cur = 65535

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

ulimit 用於shell啓動進程所佔用的資源。

可使用該命令查看進程佔用資源的狀況。

使用方法：ulimit [-acdfHlmnpsStvw] [size]

-H 設置硬件資源限制.
-S 設置軟件資源限制.
-a 顯示當前全部的資源限制.
-c size:設置core文件的最大值.單位:blocks
-d size:設置數據段的最大值.單位:kbytes
-f size:設置建立文件的最大值.單位:blocks
-l size:設置在內存中鎖定進程的最大值.單位:kbytes
-m size:設置可使用的常駐內存的最大值.單位:kbytes
-n size:設置內核能夠同時打開的文件描述符的最大值.單位:n
-p size:設置管道緩衝區的最大值.單位:kbytes
-s size:設置堆棧的最大值.單位:kbytes
-t size:設置CPU使用時間的最大上限.單位:seconds
-v size:設置虛擬內存的最大值.單位:kbytes 5
1]在RH8的環境文件/etc/profile中,咱們能夠看到系統是如何配置ulimit的:

#grep ulimit /etc/profile
ulimit -S -c 0 > /dev/null 2>&1    (輸出重定向，正常輸出和異常輸出都忽略)

這條語句設置了對軟件資源和對core文件大小的設置
2]若是咱們想要對由shell建立的文件大小做些限制,如:

#ll h
-rw-r--r-- 1 lee lee 150062 7月 22 02:39 h
#ulimit -f 100 #設置建立文件的最大塊(一塊=512字節)
#cat h>newh
File size limit exceeded
#ll newh
-rw-r--r-- 1 lee lee 51200 11月 8 11:47 newh

 

文件h的大小是150062字節,而咱們設定的建立文件的大小是512字節x100塊=51200字節
固然系統就會根據你的設置生成了51200字節的newh文件.
Linux性能調優基本策略設定3]能夠像實例1]同樣,把你要設置的ulimit放在/etc/profile這個環境文件中.
若是針對全部用戶設置,可在/etc/security/limits.conf 設置.

copyright by ixdba.

　　簡述以上五點，你能夠按部就班依步調優，也能夠着重調優，但有一點你卻要牢記，那就是軟件工程的概論，有一纔有二，有因纔有果，到頭來千萬不要揀了芝麻丟了西瓜。

 

　　吐槽：南京工資低房價高，像咱們這些高技術想要有活路，仍是要創業。

 

 /**

   * @author wonter  

   * <b>描述:</b> 敏捷測試團隊，再也不僅僅是在coding以後。而是和研發人員貫穿在需求分析、規格說明、自動化單元測試、自動化驗收測試、靜態代碼分析、技術債等環節中。因此敏捷項目一定在未來效率的趨勢    * 下成爲主流。<br>

   * <b>博客:</b> http://www.cnblogs.com/javame <br>

   * <b>郵件：</b> yiyu1@163.com <br>