The NoteBook of EricKong

            BlogJava :: 首頁 :: 聯系 :: 聚合  :: 管理
            611 Posts :: 1 Stories :: 190 Comments :: 0 Trackbacks

          常用鏈接

          留言簿(11)

          我參與的團隊

          搜索

          •  

          最新評論

          閱讀排行榜

          評論排行榜

          #

          1、首先,bash中0,1,2三個數字分別代表STDIN_FILENO、STDOUT_FILENO、STDERR_FILENO,即標準輸入(一般是鍵盤),標準輸出(一般是顯示屏,準確的說是用戶終端控制臺),標準錯誤(出錯信息輸出)。

          2、輸入輸出可以重定向,所謂重定向輸入就是在命令中指定具體的輸入來源,譬如 cat < test.c 將test.c重定向為cat命令的輸入源。輸出重定向是指定具體的輸出目標以替換默認的標準輸出,譬如ls > 1.txt將ls的結果從標準輸出重定向為1.txt文本。有時候會看到如 ls >> 1.txt這類的寫法,> 和 >> 的區別在于:> 用于新建而>>用于追加。即ls > 1.txt會新建一個1.txt文件并且將ls的內容輸出到新建的1.txt中,而ls >> 1.txt則用在1.txt已經存在,而我們只是想將ls的內容追加到1.txt文本中的時候。

          3、默認輸入只有一個(0,STDIN_FILENO),而默認輸出有兩個(標準輸出1 STDOUT_FILENO,標準錯誤2 STDERR_FILENO)。因此默認情況下,shell輸出的錯誤信息會被輸出到2,而普通輸出信息會輸出到1。但是某些情況下,我們希望在一個終端下看到所有的信息(包括標準輸出信息和錯誤信息),要怎么辦呢?

                 對了,你可以使用我們上面講到的輸出重定向。思路有了,怎么寫呢? 非常直觀的想法就是2>1(將2重定向到1嘛),行不行呢?試一試就知道了。我們進行以下測試步驟:

          1)mkdir test && cd test                ; 創建test文件夾并進入test目錄

          2)touch a.txt b.c c                          ; 創建a.txt b.c c 三個文件

          3)ls > 1                                           ; 按我們的猜測,這句應該是將ls的結果重定向到標準輸出,因此效果和直接ls應該一樣。但是實際這句執行后,標準輸出中并沒有任何信息。

          4)ls                                                  ; 執行3之后再次ls,則會看到test文件夾中多了一個文件1

          5)cat 1                                            ; 查看文件1的內容,實際結果為:1 a.txt b.c c     可見步驟3中 ls > 1并不是將ls的結果重定向為標準輸出,而是將結果重定向到了一個文件1中。即1在此處不被解釋為STDOUT_FILENO,而是文件1。

          4、到了此時,你應該也能猜到2>&1的用意了。不錯,2>&1就是用來將標準錯誤2重定向到標準輸出1中的。此處1前面的&就是為了讓bash將1解釋成標準輸出而不是文件1。至于最后一個&,則是讓bash在后臺執行。

          posted @ 2015-07-15 09:56 Eric_jiang 閱讀(318) | 評論 (0)編輯 收藏

               摘要: https介紹:   HTTPS(全稱:Hypertext Transfer Protocol over Secure Socket Layer),是以安全為目標的HTTP通道,簡單講是HTTP的安全版。即HTTP下加入SSL層,HTTPS的安全基礎是SSL,因此加密的詳細內容就需要SSL。 它是一個URI scheme(抽象標識符體系),句法類同http:體系。用于...  閱讀全文
          posted @ 2015-07-15 08:51 Eric_jiang 閱讀(273) | 評論 (0)編輯 收藏

          1.什么是會話保持?
          在大多數電子商務的應用系統或者需要進行用戶身份認證的在線系統中,一個客戶與服務器經常經過好幾次的交互過程才能完成一筆交易或者是一個請求的完成。由于這幾次交互過程是密切相關的,服務器在進行這些交互過程的某一個交互步驟時,往往需要了解上一次交互過程的處理結果,或者上幾步的交互過程結果,服務器進行下一步操作時就要求所有這些相關的交互過程都由一臺服務器完成,而不能被負載均衡器分散到不同的服務器上。

              而這一系列的相關的交互過程可能是由客戶到服務器的一個連接的多次會話完成,也可能是在客戶與服務器之間的多個不同連接里的多次會話完成。不同連接的多次會話,最典型的例子就是基于http的訪問,一個客戶完成一筆交易可能需多次點擊,而一個新的點擊產生的請求,可能會重用上一次點擊建立起來的連接,也可能是一個新建的連接。

              會話保持就是指在負載均衡器上有這么一種機制,可以識別做客戶與服務器之間交互過程的關連性,在作負載均衡的同時,還保證一系列相關連的訪問請求會保持分配到一臺服務器上。

          2.F5支持什么樣的會話保持方法?
              F5 Big-IP支持多種的會話保持方法,其中包括:簡單會話保持(源地址會話保持)、HTTP Header的會話保持,基于SSL Session ID的會話保持,i-Rules會話保持以及基于HTTP Cookie的會話保持,此外還有基于SIP ID以及Cache設備的會話保持等,但常用的是簡單會話保持,HTTP Header的會話保持以及 HTTP Cookie會話保持以及基于i-Rules的會話保持。

          2.1 簡單會話保持
              簡單會話保持也被稱為基于源地址的會話保持,是指負載均衡器在作負載均衡時是根據訪問請求的源地址作為判斷關連會話的依據。對來自同一IP地址的所有訪問 請求在作負載均時都會被保持到一臺服務器上去。在BIG-IP設備上可以為“同一IP地址”通過網絡掩碼進行區分,比如可以通過對IP地址 192.168.1.1進行255.255.255.0的網絡掩碼,這樣只要是來自于192.168.1.0/24這個網段的流量BIGIP都可以認為他們是來自于同一個用戶,這樣就將把來自于192.168.1.0/24網段的流量會話保持到特定的一臺服務器上。

              簡單會話保持里另外一個很重要的參數就是連接超時值,BIGIP會為每一個進行會話保持的會話設定一個時間值,當一個會話上一次完成到這個會話下次再來之前的間隔如果小于這個超時值,BIGIP將會將新的連接進行會話保持,但如果這個間隔大于該超時值,BIGIP將會將新來的連接認為是新的會話然后進行負載平衡。

              基于原地址的會話保持實現起來簡單,只需要根據數據包三、四層的信息就可以實現,效率也比較高。存在的問題就在于當多個客戶是通過代理或地址轉換的方式來訪問服務器時,由于都分配到同一臺服務器上,會導致服務器之間的負載嚴重失衡。另外一種情況上客戶機數量很少,但每個客戶機都會產生多個并發訪問,對這些并發訪問也要求通過負載均衡器分配到多個服器上,這時基于客戶端源地址的會話保持方法也會導致負載均衡失效。

          2.2 基于Cookie的會話保持
          2.2.1 Cookie插入模式:
              在Cookie插入模式下,Big-IP將負責插入cookie,后端服務器無需作出任何修改

              當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIG-IP, BIG-IP根據負載平衡算法策略選擇后端一臺服務器,并將請求發送至該服務器,后端服務器進行HTTP回復(不帶cookie)被發回BIGIP,然后 BIG-IP插入cookie,將HTTP回復返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次BIGIP插入的cookie)進入 BIGIP,然后BIGIP讀出cookie里的會話保持數值,將HTTP請求(帶有與上面同樣的cookie)發到指定的服務器,然后后端服務器進行請求回復,由于服務器并不寫入cookie,HTTP回復將不帶有cookie,恢復流量再次經過進入BIG-IP時,BIG-IP再次寫入更新后的會話保持 cookie。

          2.2.2 Cookie 重寫模式
              當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIGIP, BIGIP根據負載均衡算法策略選擇后端一臺服務器,并將請求發送至該服務器,后端服務器進行HTTP回復一個空白的cookie并發回BIGIP,然后BIGIP重新在cookie里寫入會話保持數值,將HTTP回復返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次BIGIP重寫的 cookie)進入BIGIP,然后BIGIP讀出cookie里的會話保持數值,將HTTP請求(帶有與上面同樣的cookie)發到指定的服務器,然后后端服務器進行請求回復,HTTP回復里又將帶有空的cookie,恢復流量再次經過進入BIGIP時,BIGIP再次寫入更新后會話保持數值到該 cookie。

          2.2.3 Passive Cookie 模式,服務器使用特定信息來設置cookie。
              當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIGIP, BIGIP根據負載平衡算法策略選擇后端一臺服務器,并將請求發送至該服務器,后端服務器進行HTTP回復一個cookie并發回BIGIP,然后 BIGIP將帶有服務器寫的cookie值的HTTP回復返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次服務器寫的cookie)進入 BIGIP,然后BIGIP根據cookie里的會話保持數值,將HTTP請求(帶有與上面同樣的cookie)發到指定的服務器,然后后端服務器進行請 求回復,HTTP回復里又將帶有更新的會話保持cookie,恢復流量再次經過進入BIGIP時,BIGIP將帶有該cookie的請求回復給客戶端。

          2.2.4 Cookie Hash模式:
              當客戶進行第一次請求時,客戶HTTP請求(不帶cookie)進入BIGIP, BIGIP根據負載均衡算法策略選擇后端一臺服務器,并將請求發送至該服務器,后端服務器進行HTTP回復一個cookie并發回BIGIP,然后 BIGIP將帶有服務器寫的cookie值的HTTP回復返回到客戶端。當客戶請求再次發生時,客戶HTTP請求(帶有上次服務器寫的cookie)進入 BIGIP,然后BIGIP根據cookie里的一定的某個字節的字節數來決定后臺服務器接受請求,將HTTP請求(帶有與上面同樣的cookie)發到指定的服務器,然后后端服務器進行請求回復,HTTP回復里又將帶有更新后的cookie,恢復流量再次經過進入BIGIP時,BIGIP將帶有該 cookie的請求回復給客戶端。

          2.3 SSL Session ID會話保持
              在用戶的SSL訪問系統的環境里,當SSL對話首次建立時,用戶與服務器進行首次信息交換以:1}交換安全證書,2)商議加密和壓縮方法,3)為每條對話 建立Session ID。由于該Session ID在系統中是一個唯一數值,由此,BIGIP可以應用該數值來進行會話保持。當用戶想與該服務器再次建立連接時,BIGIP可以通過會話中的 SSL Session ID識別該用戶并進行會話保持。

              基于SSL Session ID的會話保持就需要客戶瀏覽器在進行會話的過程中始終保持其SSL Session ID不變,但實際上,微軟Internet Explorer被發現在經過特定一段時間后將主動改變SSL Session ID,這就使基于SSL Session ID的會話保持實際應用范圍大大縮小。

          posted @ 2015-07-14 08:59 Eric_jiang 閱讀(339) | 評論 (0)編輯 收藏

          Linux系統中,有時候普通用戶有些事情是不能做的,除非是root用戶才能做到。這時就需要用su命令臨時切換到root身份來做事了。

          su:substitute['s?bst?tju?t]代替 user
          su 的語法為:
          su [OPTION選項參數] [用戶]
          -, -l, --login 登錄并改變到所切換的用戶環境;
          -c, --commmand=COMMAND 執行一個命令,然后退出所切換到的用戶環境;

          用su命令切換用戶后,可以用 exit 命令或快捷鍵[Ctrl+D]可返回原登錄用戶。

          例子:
          su 在不加任何參數,默認為切換到root用戶,但沒有轉到root用戶家目錄下,也就是說這時雖然是切換為root用戶了,但并沒有改變root登錄環境;用戶默認的登錄環境,可以在/etc/passwd 中查得到,包括家目錄,SHELL定義等;
          su 加參數 - ,表示默認切換到root用戶,并且改變到root用戶的環境;


          用su是可以切換用戶身份,如果每個普通用戶都能切換到root身份,如果某個用戶不小心泄漏了root的密碼,那豈不是系統非常的不安全?沒有錯,為了改進這個問題,產生了sudo這個命令。使用sudo執行一個root才能執行的命令是可以辦到的,但是需要輸入密碼,這個密碼并不是root的密碼而是用戶自己的密碼。默認只有root用戶能使用sudo命令,普通用戶想要使用sudo,是需要root預先設定的,即,使用visudo命令去編輯相關的配置文件/etc/sudoers。如果沒有visudo這個命令,請使用 "yum install -y sudo" 安裝。

          默認root能夠sudo是因為這個文件中有一行” root ALL=(ALL) ALL”

          sudo 的適用條件:
          由于su對切換到超級權限用戶root后,權限的無限制性,所以su并不能擔任多個管理員所管理的系統。如果用su來切換到超級用戶來管理系統,也不能明 確哪些工作是由哪個管理員進行的操作。特別是對于服務器的管理有多人參與管理時,最好是針對每個管理員的技術特長和管理范圍,并且有針對性的下放給權限, 并且約定其使用哪些工具來完成與其相關的工作,這時我們就有必要用到 sudo。
          通過sudo,我們能把某些超級權限有針對性的下放,并且不需要普通用戶知道root密碼,所以sudo 相對于權限無限制性的su來說,還是比較安全的,所以sudo 也能被稱為受限制的su ;另外sudo 是需要授權許可的,所以也被稱為授權許可的su;
          sudo 執行命令的流程:是當前用戶切換到root(或其它指定切換到的用戶),然后以root(或其它指定的切換到的用戶)身份執行命令,執行完成后,直接退回到當前用戶;而這些的前提是要通過sudo的配置文件/etc/sudoers來進行授權;

          從編寫 sudo 配置文件/etc/sudoers開始
          sudo的配置文件是/etc/sudoers ,我們可以用他的專用編輯工具visodu ,此工具的好處是在添加規則不太準確時,保存退出時會提示給我們錯誤信息;配置好后,可以用切換到您授權的用戶下,通過sudo -l 來查看哪些命令是可以執行或禁止的;
          /etc/sudoers 文件中每行算一個規則,前面帶有#號可以當作是說明的內容,并不執行;如果規則很長,一行列不下時,可以用\號來續行,這樣看來一個規則也可以擁有多個行;
          /etc/sudoers 的規則可分為兩類;一類是別名定義,另一類是授權規則;別名定義并不是必須的,但授權規則是必須的;

          sudo授權規則(sudoers配置):
          授權用戶 主機=命令動作
          這三個要素缺一不可,但在動作之前也可以指定切換到特定用戶下,在這里指定切換的用戶要用( )號括起來,如果不需要密碼直接運行命令的,應該加NOPASSWD:參數,但這些可以省略;舉例說明;

          sudoers的缺省配置:
          Html代碼  收藏代碼
          #############################################################  
          # sudoers file.  
          #  
          # This file MUST be edited with the 'visudo' command as root.  
          #  
          # See the sudoers man page for the details on how to write a sudoers file.  
          #  
          # Host alias specification  
          # User alias specification  
          # Cmnd alias specification  
          # Defaults specification  
          # User privilege specification  
          root    ALL=(ALL) ALL  
          # Uncomment to allow people in group wheel to run all commands  
          # %wheel        ALL=(ALL)       ALL  
          # Same thing without a password  
          # %wheel        ALL=(ALL)       NOPASSWD: ALL  
          # Samples  
          # %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom  
          # %users  localhost=/sbin/shutdown -h now  
          ##################################################################  

          1. 最簡單的配置,讓普通用戶support具有root的所有權限
          執行visudo之后,可以看見缺省只有一條配置:
          root    ALL=(ALL) ALL
          那么你就在下邊再加一條配置:
          support ALL=(ALL) ALL
          這樣,普通用戶support就能夠執行root權限的所有命令
          以support用戶登錄之后,執行:
          sudo su -
          然后輸入support用戶自己的密碼,就可以切換成root用戶了
          2. 讓普通用戶support只能在某幾臺服務器上,執行root能執行的某些命令
          首先需要配置一些Alias,這樣在下面配置權限時,會方便一些,不用寫大段大段的配置。Alias主要分成4種
          Host_Alias
          Cmnd_Alias
          User_Alias
          Runas_Alias
          1) 配置Host_Alias:就是主機的列表
          Host_Alias      HOST_FLAG = hostname1, hostname2, hostname3
          2) 配置Cmnd_Alias:就是允許執行的命令的列表,命令前加上!表示不能執行此命令.
          命令一定要使用絕對路徑,避免其他目錄的同名命令被執行,造成安全隱患 ,因此使用的時候也是使用絕對路徑!
          Cmnd_Alias      COMMAND_FLAG = command1, command2, command3 ,!command4
          3) 配置User_Alias:就是具有sudo權限的用戶的列表
          User_Alias USER_FLAG = user1, user2, user3
          4) 配置Runas_Alias:就是用戶以什么身份執行(例如root,或者oracle)的列表
          Runas_Alias RUNAS_FLAG = operator1, operator2, operator3
          5) 配置權限
          配置權限的格式如下:
          USER_FLAG HOST_FLAG=(RUNAS_FLAG) COMMAND_FLAG
          如果不需要密碼驗證的話,則按照這樣的格式來配置
          USER_FLAG HOST_FLAG=(RUNAS_FLAG) NOPASSWD: COMMAND_FLAG
          配置示例:
          Html代碼  收藏代碼
          ############################################################################  
          # sudoers file.  
          #  
          # This file MUST be edited with the 'visudo' command as root.  
          #  
          # See the sudoers man page for the details on how to write a sudoers file.  
          #  
          # Host alias specification  
          Host_Alias      EPG = 192.168.1.1, 192.168.1.2  
          # User alias specification  
          # Cmnd alias specification  
          Cmnd_Alias      SQUID = /opt/vtbin/squid_refresh, !/sbin/service, /bin/rm 
           
          Cmnd_Alias      ADMPW = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd, !/usr/bin/passwd root  
          # Defaults specification  
          # User privilege specification  
          root    ALL=(ALL) ALL  
          support EPG=(ALL) NOPASSWD: SQUID  
          support EPG=(ALL) NOPASSWD: ADMPW 
          # Uncomment to allow people in group wheel to run all commands  
          # %wheel        ALL=(ALL)       ALL  
          # Same thing without a password  
          # %wheel        ALL=(ALL)       NOPASSWD: ALL  
          # Samples  
          # %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom  
          # %users  localhost=/sbin/shutdown -h now  
          ############################################################### 

          posted @ 2015-07-13 11:54 Eric_jiang 閱讀(247) | 評論 (0)編輯 收藏

               摘要: JVM監控與調優 光說不練假把式,學習Java GC機制的目的是為了實用,也就是為了在JVM出現問題時分析原因并解決之。通過學習,我覺得JVM監控與調優主要的著眼點在于如何配置、如何監控、如何優化3點上。下面就將針對這3點進行學習。     (如果您對Java的內存區域劃分和內存回收機制尚不明確,那在閱讀本文前,請先閱讀我的前一篇博客《Java系...  閱讀全文
          posted @ 2015-07-10 09:03 Eric_jiang 閱讀(215) | 評論 (0)編輯 收藏

          LVS和Nginx都可以用作多機負載的方案,它們各有優缺,在生產環境中需要好好分析實際情況并加以利用。

            首先提醒,做技術切不可人云亦云,我云即你云;同時也不可太趨向保守,過于相信舊有方式而等別人來幫你做墊被測試。把所有即時聽說到的好東西加以鉆研,從而提高自己對技術的認知和水平,乃是一個好習慣。

          下面來分析一下兩者:

          一、lvs的優勢:

            1、抗負載能力強,因為lvs工作方式的邏輯是非常之簡單,而且工作在網絡4層僅做請求分發之用,沒有流量,所以在效率上基本不需要太過考慮。在我手里的 lvs,僅僅出過一次問題:在并發最高的一小段時間內均衡器出現丟包現象,據分析為網絡問題,即網卡或linux2.4內核的承載能力已到上限,內存和 cpu方面基本無消耗。

            2、配置性低,這通常是一大劣勢,但同時也是一大優勢,因為沒有太多可配置的選項,所以除了增減服務器,并不需要經常去觸碰它,大大減少了人為出錯的幾率。

            3、工作穩定,因為其本身抗負載能力很強,所以穩定性高也是順理成章,另外各種lvs都有完整的雙機熱備方案,所以一點不用擔心均衡器本身會出什么問題,節點出現故障的話,lvs會自動判別,所以系統整體是非常穩定的。

            4、無流量,上面已經有所提及了。lvs僅僅分發請求,而流量并不從它本身出去,所以可以利用它這點來做一些線路分流之用。沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響。

            5、基本上能支持所有應用,因為lvs工作在4層,所以它可以對幾乎所有應用做負載均衡,包括http、數據庫、聊天室等等。

            另:lvs也不是完全能判別節點故障的,譬如在wlc分配方式下,集群里有一個節點沒有配置VIP,會使整個集群不能使用,這時使用wrr分配方式則會丟掉一臺機。目前這個問題還在進一步測試中。所以,用lvs也得多多當心為妙。

          二、nginx和lvs作對比的結果

            1、nginx工作在網絡的7層,所以它可以針對http應用本身來做分流策略,比如針對域名、目錄結構等,相比之下lvs并不具備這樣的功能,所以 nginx單憑這點可利用的場合就遠多于lvs了;但nginx有用的這些功能使其可調整度要高于lvs,所以經常要去觸碰觸碰,由lvs的第2條優點 看,觸碰多了,人為出問題的幾率也就會大。

            2、nginx對網絡的依賴較小,理論上只要ping得通,網頁訪問正常,nginx就能連得通,nginx同時還能區分內外網,如果是同時擁有內外網的 節點,就相當于單機擁有了備份線路;lvs就比較依賴于網絡環境,目前來看服務器在同一網段內并且lvs使用direct方式分流,效果較能得到保證。另 外注意,lvs需要向托管商至少申請多一個ip來做Visual IP,貌似是不能用本身的IP來做VIP的。要做好LVS管理員,確實得跟進學習很多有關網絡通信方面的知識,就不再是一個HTTP那么簡單了。

            3、nginx安裝和配置比較簡單,測試起來也很方便,因為它基本能把錯誤用日志打印出來。lvs的安裝和配置、測試就要花比較長的時間了,因為同上所述,lvs對網絡依賴比較大,很多時候不能配置成功都是因為網絡問題而不是配置問題,出了問題要解決也相應的會麻煩得多。

            4、nginx也同樣能承受很高負載且穩定,但負載度和穩定度差lvs還有幾個等級:nginx處理所有流量所以受限于機器IO和配置;本身的bug也還是難以避免的;nginx沒有現成的雙機熱備方案,所以跑在單機上還是風險較大,單機上的事情全都很難說。

            5、nginx可以檢測到服務器內部的故障,比如根據服務器處理網頁返回的狀態碼、超時等等,并且會把返回錯誤的請求重新提交到另一個節點。目前lvs中 ldirectd也能支持針對服務器內部的情況來監控,但lvs的原理使其不能重發請求。重發請求這點,譬如用戶正在上傳一個文件,而處理該上傳的節點剛 好在上傳過程中出現故障,nginx會把上傳切到另一臺服務器重新處理,而lvs就直接斷掉了,如果是上傳一個很大的文件或者很重要的文件的話,用戶可能 會因此而惱火。

            6、nginx對請求的異步處理可以幫助節點服務器減輕負載,假如使用Apache直接對外服務,那么出現很多的窄帶鏈接時apache服務器將會占用大 量內存而不能釋放,使用多一個nginx做apache代理的話,這些窄帶鏈接會被nginx擋住,apache上就不會堆積過多的請求,這樣就減少了相 當多的內存占用。這點使用squid也有相同的作用,即使squid本身配置為不緩存,對apache還是有很大幫助的。lvs沒有這些功能,也就無法能 比較。

            7、nginx能支持http和email(email的功能估計比較少人用),lvs所支持的應用在這點上會比nginx更多。

            在使用上,一般最前端所采取的策略應是lvs,也就是DNS的指向應為lvs均衡器,lvs的優點令它非常適合做這個任務。

            重要的ip地址,最好交由lvs托管,比如數據庫的ip、webservice服務器的ip等等,這些ip地址隨著時間推移,使用面會越來越大,如果更換ip則故障會接踵而至。所以將這些重要ip交給lvs托管是最為穩妥的,這樣做的唯一缺點是需要的VIP數量會比較多。

            nginx可作為lvs節點機器使用,一是可以利用nginx的功能,二是可以利用nginx的性能。當然這一層面也可以直接使用squid,squid的功能方面就比nginx弱不少了,性能上也有所遜色于nginx。

            nginx也可作為中層代理使用,這一層面nginx基本上無對手,唯一可以撼動nginx的就只有lighttpd了,不過lighttpd目前還沒有 能做到nginx完全的功能,配置也不那么清晰易讀。另外,中層代理的IP也是重要的,所以中層代理也擁有一個VIP和lvs是最完美的方案了。

            nginx也可作為網頁靜態服務器,不過超出了本文討論的范疇,簡單提一下。

            具體的應用還得具體分析,如果是比較小的網站(日PV<1000萬),用nginx就完全可以了,如果機器也不少,可以用DNS輪詢,lvs所耗費的機器還是比較多的;大型網站或者重要的服務,機器不發愁的時候,要多多考慮利用lvs。

          posted @ 2015-07-01 10:51 Eric_jiang 閱讀(154) | 評論 (0)編輯 收藏

          在Linux中常用于判斷問題所在的初步定位或性能瓶頸,iostat則給我們提供了豐富的IO狀態信息,其他工具還有iotop。

          letong@me:~$ sudo iostat
          Linux 3.13.0-41-generic (me) 2014年12月18日 _x86_64_ (4 CPU)

          avg-cpu: %user %nice %system %iowait %steal %idle
          8.92 0.12 2.27 0.65 0.00 88.05

          Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
          sda 5.12 85.24 1.97 586069 13512
          sdb 9.51 43.74 112.81 300771 775678
          rrqm/s: 每秒進行 merge 的讀操作數目。即 delta(rmerge)/s
          wrqm/s: 每秒進行 merge 的寫操作數目。即 delta(wmerge)/s
          r/s: 每秒完成的讀 I/O 設備次數。即 delta(rio)/s
          w/s: 每秒完成的寫 I/O 設備次數。即 delta(wio)/s
          rsec/s: 每秒讀扇區數。即 delta(rsect)/s
          wsec/s: 每秒寫扇區數。即 delta(wsect)/s
          rkB/s: 每秒讀K字節數。是 rsect/s 的一半,因為每扇區大小為512字節。(需要計算)
          wkB/s: 每秒寫K字節數。是 wsect/s 的一半。(需要計算)
          avgrq-sz: 平均每次設備I/O操作的數據大小 (扇區)。delta(rsect+wsect)/delta(rio+wio)
          avgqu-sz: 平均I/O隊列長度。即 delta(aveq)/s/1000 (因為aveq的單位為毫秒)。
          await: 平均每次設備I/O操作的等待時間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
          svctm: 平均每次設備I/O操作的服務時間 (毫秒)。即 delta(use)/delta(rio+wio)
          %util: 一秒中有百分之多少的時間用于 I/O 操作,或者說一秒中有多少時間 I/O 隊列是非空的。即 delta(use)/s/1000 (因為use的單位為毫秒)
          常用參數:
          -d 1 #每1秒顯示1次
          -x #顯示更詳細信息
          -c #顯示cpu相關

          常見用法
          iostat -d -k 1 10 #查看TPS和吞吐量信息
          iostat -d -x -k 1 10 #查看設備使用率、響應時間
          iostat -c 1 10 #查看cpu狀態

          posted @ 2015-06-30 10:13 Eric_jiang 閱讀(173) | 評論 (0)編輯 收藏

          如果在測試過程中遇到某個進程的CPU利用率過高或者卡死而需要去調試該進程時,可以利用gdb命令生成coredump文件,然后再去調試coredump文件來定位問題。

          那么如何使用gdb生成coredump文件呢?其實步驟很簡單:


          1. 安裝好gdb,然后使用命令 'gdb'。(假設需要調試的進程號為 21509)

          2. 使用 ‘attach 21590’命令將gdb附加到進程21509上。

          3. 使用‘gcore core_name’命令生成coredump文件core_name。

          4. 使用‘detach’命令斷開連接。

          5.使用‘q’命令退出gdb。


          此時,在當前目錄下就會產生一個名為core_name的coredump文件。下面就可以利用gdb工具來對該coredump文件進行調試了。

          posted @ 2015-06-26 10:58 Eric_jiang 閱讀(280) | 評論 (1)編輯 收藏

          linux renice 命令詳解 
            功能說明:調整程序優先級。 
            語  法:renice [優先等級][-g <程序群組名稱>...][-p <程序識別碼>...][-u <用戶名稱>...] 
            補充說明:renice指令可重新調整程序執行的優先權等級。預設是以程序識別碼指定程序調整其優先權,您亦可以指定程序群組或用戶名稱調整優先權等級,并修改所有隸屬于該程序群組或用戶的程序的優先權。等級范圍從-20--19,只有系統管理者可以改變其他用戶程序的優先權,也僅有系統管理者可以設置負數等級。 
            參  數: 
            -g <程序群組名稱>  使用程序群組名稱,修改所有隸屬于該程序群組的程序的優先權。 
            -p <程序識別碼>  改變該程序的優先權等級,此參數為預設值。 
            -u <用戶名稱>  指定用戶名稱,修改所有隸屬于該用戶的程序的優先權。 
           
          一開始執行程式就立即給予一個特定的 nice 值:用 nice 命令; 
          調整某個已經存在的 PID 的 nice 值:用 renice 命令。 
          推薦閱讀一:linux進程cpu資源分配命令nice,renice,taskset 
          進程cpu資源分配就是指進程的優先權(priority)。優先權高的進程有優先執行權利。配置進程優先權對多任務環境的linux很有用,可以改善系統性能。還可以把進程運行到指定的CPU上,這樣一來,把不重要的進程安排到某個CPU,可以大大改善系統整體性能。 
          一、先看系統進程: 
          PR 就是 Priority 的簡寫,而 NI 是 nice 的簡寫。這兩個值決定了PR的值,PR越小,進程優先權就越高,就越“優先執行”。換算公式為:PR(new) = PR(old) + NI 
          --------------------------------------------------------------------------- 
          二、修改進程優先級的命令主要有兩個:nice,renice 
          1、一開始執行程序就指定nice值:nice 
          nice -n -5 /usr/local/mysql/bin/mysqld_safe & 
          linux nice 命令詳解 
            功能說明:設置優先權。 
            語  法:nice [-n <優先等級>][--help][--version][執行指令] 
            補充說明:nice指令可以改變程序執行的優先權等級。 
            參  數:-n<優先等級>或-<優先等級>或--adjustment=<優先等級>  設置欲執行的指令的優先權等級。等級的范圍從-20-19,其中-20最高,19最低,只有系統管理者可以設置負數的等級。 
             --help  在線幫助。 
             --version  顯示版本信息。 
          --------------------------------------------------------------------------- 
          2.1、調整已存在進程的nice:renice 
          renice -5 -p 5200 
          #PID為5200的進程nice設為-5 
          linux renice 命令詳解 
            功能說明:調整優先權。 
            語  法:renice [優先等級][-g <程序群組名稱>...][-p <程序識別碼>...][-u <用戶名稱>...] 
            補充說明:renice指令可重新調整程序執行的優先權等級。預設是以程序識別碼指定程序調整其優先權,您亦可以指定程序群組或用戶名稱調整優先權等級,并修改所有隸屬于該程序群組或用戶的程序的優先權。等級范圍從-20--19,只有系統管理者可以改變其他用戶程序的優先權,也僅有系統管理者可以設置負數等級。 
            參  數: 
            -g <程序群組名稱>  使用程序群組名稱,修改所有隸屬于該程序群組的程序的優先權。 
            -p <程序識別碼>  改變該程序的優先權等級,此參數為預設值。 
            -u <用戶名稱>  指定用戶名稱,修改所有隸屬于該用戶的程序的優先權。 
          posted @ 2015-06-19 17:20 Eric_jiang 閱讀(328) | 評論 (0)編輯 收藏

          性能測試排查定位問題,分析調優過程中,會遇到要分析gc日志,人肉分析gc日志有時比較困難,相關圖形化或命令行工具可以有效地幫助輔助分析。

          Gc日志參數

          通過在tomcat啟動腳本中添加相關參數生成gc日志

          -verbose.gc開關可顯示GC的操作內容。打開它,可以顯示最忙和最空閑收集行為發生的時間、收集前后的內存大小、收集需要的時間等。

          打開 -xx:+ printGCdetails開關,可以詳細了解GC中的變化。

          打開 -XX: + PrintGCTimeStamps開關,可以了解這些垃圾收集發生的時間,自JVM啟動以后以秒計量。

          最后,通過 -xx: + PrintHeapAtGC開關了解堆的更詳細的信息。

          為了了解新域的情況,可以通過 -XX:=PrintTenuringDistribution開關了解獲得使用期的對象權。

          -Xloggc:$CATALINA_BASE/logs/gc.loggc日志產生的路徑

          XX:+PrintGCApplicationStoppedTime//輸出GC造成應用暫停的時間

          -XX:+PrintGCDateStamps// GC發生的時間信息

           

          Gc日志

          日志中顯示了gc發生的時間,young區回收情況,整體回收情況,fullGC情況,回收所消耗時間等

           

          常用JVM參數

          分析gc日志后,經常需要調整jvm內存相關參數,常用參數如下

          -Xms:初始堆大小,默認為物理內存的1/64(<1GB);默認(MinHeapFreeRatio參數可以調整)空余堆內存小于40%時,JVM就會增大堆直到-Xmx的最大限制

          -Xmx:最大堆大小,默認(MaxHeapFreeRatio參數可以調整)空余堆內存大于70%時,JVM會減少堆直到-Xms的最小限制

          -Xmn:新生代的內存空間大小,注意:此處的大小是(eden+ 2 survivor space)。與jmap -heap中顯示的New gen是不同的。整個堆大小=新生代大小+老生代大小+永久代大小。 
          在保證堆大小不變的情況下,增大新生代后,將會減小老生代大小。此值對系統性能影響較大,Sun官方推薦配置為整個堆的3/8。

          -XX:SurvivorRatio:新生代中Eden區域與Survivor區域的容量比值,默認值為8。兩個Survivor區與一個Eden區的比值為2:8,一個Survivor區占整個年輕代的1/10。

          -Xss:每個線程的堆棧大小。JDK5.0以后每個線程堆棧大小為1M,以前每個線程堆棧大小為256K。應根據應用的線程所需內存大小進行適當調整。在相同物理內存下,減小這個值能生成更多的線程。但是操作系統對一個進程內的線程數還是有限制的,不能無限生成,經驗值在3000~5000左右。一般小的應用, 如果棧不是很深, 應該是128k夠用的,大的應用建議使用256k。這個選項對性能影響比較大,需要嚴格的測試。和threadstacksize選項解釋很類似,官方文檔似乎沒有解釋,在論壇中有這樣一句話:"-Xss is translated in a VM flag named ThreadStackSize”一般設置這個值就可以了。

          -XX:PermSize:設置永久代(perm gen)初始值。默認值為物理內存的1/64。

          -XX:MaxPermSize:設置持久代最大值。物理內存的1/4。

           

          Gc日志分析工具

          (1)GCHisto

          http://java.net/projects/gchisto

           

          直接點擊gchisto.jar就可以運行,點add載入gc.log

          統計了總共gc次數,youngGC次數,FullGC次數,次數的百分比,GC消耗的時間,百分比,平均消耗時間,消耗時間最小最大值等

           

           

          統計的圖形化表示

           

          YoungGC,FullGC不同消耗時間上次數的分布圖,勾選可以顯示youngGC或fullGC單獨的分布情況

           

          整個時間過程詳細的gc情況,可以對整個過程進行剖析

           

           

          (2)GCLogViewer

           

          http://code.google.com/p/gclogviewer/

           

          點擊run.bat運行

           

          整個過程gc情況的趨勢圖,還顯示了gc類型,吞吐量,平均gc頻率,內存變化趨勢等

          Tools里還能比較不同gc日志

           

           

           

          (3)HPjmeter

           

          獲取地址 http://www.hp.com/go/java 
          參考文檔 http://www.javaperformancetuning.com/tools/hpjtune/index.shtml

           

          工具很強大,但只能打開由以下參數生成的GC log,-verbose:gc -Xloggc:gc.log,添加其他參數生成的gc.log無法打開。

           

          (4)GCViewer

          http://www.tagtraum.com/gcviewer.html

          這個工具用的挺多的,但只能在JDK1.5以下的版本中運行,1.6以后沒有對應。

          (5)garbagecat

          http://code.google.com/a/eclipselabs.org/p/garbagecat/wiki/Documentation

           

           

          其它監控方法

          Jvisualvm動態分析jvm內存情況和gc情況,插件:visualGC

           

          jvisualvm還可以heapdump出對應hprof文件(默認存放路徑:監控的服務器/tmp下),利用相關工具,比如HPjmeter可以對其進行分析

          grep Full gc.log粗略觀察FullGC發生頻率

          jstat –gcutil [pid] [intervel] [count]

          jmap -histo pid可以觀測對象的個數和占用空間 
          jmap -heap pid可以觀測jvm配置參數,堆內存各區使用情況

          jprofiler,jmap dump出來用MAT分析

           

          如果要分析的dump文件很大的話,就需要很多內存,很容易crash。

          所以在啟動時,我們應該加上一些參數:Java–Xms512M–Xmx1024M–Xss8M

          posted @ 2015-06-18 11:29 Eric_jiang 閱讀(152) | 評論 (0)編輯 收藏

          僅列出標題
          共57頁: 上一頁 1 2 3 4 5 6 7 8 9 下一頁 Last 
          主站蜘蛛池模板: 徐闻县| 县级市| 中方县| 托克托县| 阜平县| 怀化市| 临湘市| 双流县| 南丰县| 疏附县| 偏关县| 湘乡市| 四会市| 昭觉县| 鹤山市| 万年县| 疏勒县| 东源县| 岗巴县| 合肥市| 武隆县| 博白县| 磐石市| 额尔古纳市| 扬州市| 聂拉木县| 衡东县| 兴隆县| 威宁| 赫章县| 阳泉市| 凤冈县| 玉田县| 黑龙江省| 焉耆| 平江县| 余庆县| 米脂县| 陇南市| 澳门| 安新县|