1、如何查看伺服器當前的負載信息
方法一：
通過top命令來查看伺服器負載
再對此Linux伺服器性能分析之前，先了解下Linux系統Load average負載的知識，負載均值在 uptime 或者top 命令中可以看到，
方法二：輸入 iostat -x -k -t
說明：%util: 一秒中有百分之多少的時間用於 I/O 操作，或者說一秒中有多少時間 I/O 隊列是非空的。
即 delta(use)/s/1000 (因為use的單位為毫秒)
如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁碟可能存在瓶頸。
方法三：
如果玩游戲很卡，可以用hdparm –t /dev/磁碟名稱來測試磁碟性能是否達標，下圖是單個希捷1T的盤測試的結果
說明：sd表示硬碟是SATA，SCSI或者SAS，a表示串口的第一塊硬碟
2、負載均衡器和伺服器的區別是什麼？
負載均衡器是一種把網路請求分散到一個伺服器集群中的可用伺服器上去，通過管理進入的Web數據流量和增加有效的網路帶寬的硬體設備。
而伺服器，也稱伺服器，是提供計算服務的設備。
景安網路河南最大的多線伺服器託管商！
3、負載均衡伺服器有什麼優缺點？
隨著網站、應用訪問量的增加，一台伺服器租用已經不能滿足應用的需求，而需要多台伺服器集群，這時就會用到負載均衡，那麼負載均衡優點有那些呢，壹基比小喻來說說
負載均衡設備優勢
• 負載均衡優化了訪問請求在伺服器組之間的分配，消除了伺服器之間的負載不平衡，從而提高了系統的反應速度與總體性能；
• 負載均衡可以對伺服器的運行狀況進行監控，及時發現運行異常的伺服器，並將訪問請求轉移到其它可以正常工作的伺服器上，從而提高伺服器組的可靠性採用了負均衡器器以後，可以根據業務量的發展情況靈活增加伺服器，系統的擴展能力得到提高，同時簡化了管理。
負載均衡器有多種多樣的形式，除了作為獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置於伺服器與Internet鏈接之間，有些則以兩塊網路適配器將這一功能集成到PC中，一塊連接到Internet上，一塊連接到後端伺服器群的內部網路上。
一般而言，硬體負載均衡在功能、性能上優於軟體方式，不過成本昂貴。當Web伺服器為圖像服務、SSL（安全套接層）會話或資料庫事務而進行優化時，負載均衡器可以體現特別的價值。
當需要進行伺服器升級或系統維護時，保證穩定的伺服器退出服務以避免服務中斷。當選定某台伺服器要退出服務後，將不會將任何新的用戶分配到該伺服器。但是，它可以要該伺服器完成對當前用戶的服務。從而保證了無中斷的優質服務，並且簡化了伺服器群的管理。
智能的伺服器服務恢復
將重新啟動的伺服器應用到服務中時，避免新伺服器因突然出現的流量沖擊導致系統故障是非常重要的。所以，在將新伺服器引入伺服器群時，將逐漸地增加分配到該伺服器的流量，直至達到其完全的處理能力。從而不僅保證用戶在伺服器退出服務時，同時還保證伺服器在啟動期間以及應用程序開始時，均能獲得不間斷服務。
4、伺服器怎麼多機負載
集群架設伺服器數量：2台
集群架設方法：（設定：主伺服器IP：192.168.0.11 從伺服器 192.168.0.12）
第一步：架設主伺服器
1、 利用啟動器配置好完整的服務端程序 （舉例：比如伺服器名：測試 伺服器IP：192.168.0.11 登陸網關埠 7000 角色網關埠 7100 游戲RUN埠 7200 7300 7400），利用啟動器配置好後，那麼你的主伺服器是一個完整的服務端了
2、 修改配置文件：（修改配置文件的目的是為了讓你的從伺服器能夠跟這台主伺服器進行通訊，具備負擔的條件）
1> DBServer !addrtable.txt 此文檔含義：允許連接DBS管理器的IP列表，一般寫上 127.0.0.1 主IP 192.168.0.11 從IP 192.168.0.12 三個IP獨立成行
2> DBServer ！serverinfo.txt 此文檔含義：主伺服器 從伺服器 的網關IP以及埠，可以設置如下
192.168.0.11 192.168.0.11 7200 192.168.0.11 7300 192.168.0.11 7400
192.168.0.12 192.168.0.12 7200 192.168.0.12 7300 192.168.0.12 7400
3> LogunSrv !addrtable.txt 此文檔 實際上是一個角色網關跟登陸網關直接通訊路由標識表 在最後加一個 從伺服器的IP跟埠即可
比如：127.0.0.1 127.0.0.1 192.168.0.11:7100 192.168.0.12:7100
4> LogunSrv !serveraddr.txt 允許連接IDDBS 同DBServer !addrtable.txt
主伺服器架設完畢 架設完畢後切忌不要再用啟動器配置了 否則要從來再配置一遍，就麻煩啦。
第二步：架設從伺服器
1、 從伺服器只需要開 SELATE RUNGATE
1> SELATE 開啟的目的是 登陸7000之後 可以選擇到這台從伺服器的網關 記得配置文件網關地址寫本伺服器IP地址 192.168.0.12 伺服器地址寫 192.168.0.11
2> RUNGATE 手動配置3個 7200 7300 7400 伺服器地址寫上 主伺服器地址 192.168.0.11
架設完畢主伺服器利用啟動所有程序 從伺服器手動開 角色網關 和三個游戲網關
在主伺服器的M2上面能看到 從伺服器的IP過來就說明通訊成功，如果看不到，說明自己哪裡設置錯了，仔細檢查下！原理很簡單的，自己實踐吧！
5、伺服器負載量過大，怎樣處理？
一，確認伺服器硬體是否足夠支持當前的流量。
二，優化資料庫訪問。
伺服器的負載過大，一個重要的原因是CPU負荷過大，降低伺服器CPU的負荷，才能夠有效打破瓶頸。而使用靜態頁面可以使得CPU的負荷最小化。前台實現完全的靜態化當然最好，可以完全不用訪問資料庫，不過對於頻繁更新的網站，靜態化往往不能滿足某些功能。
緩存技術就是另一個解決方案，就是將動態數據存儲到緩存文件中，動態網頁直接調用這些文件，而不必再訪問資料庫，WordPress和Z-Blog都大量使用這種緩存技術。
如果確實無法避免對資料庫的訪問，那麼可以嘗試優化資料庫的查詢SQL.避免使用Select *from這樣的語句，每次查詢只返回自己需要的結果，避免短時間內的大量SQL查詢。
三，禁止外部的盜鏈。
外部網站的圖片或者文件盜鏈往往會帶來大量的負載壓力，因此應該嚴格限制外部對於自身的圖片或者文件盜鏈，好在目前可以簡單地通過refer來控制盜鏈，Apache自己就可以通過配置來禁止盜鏈，IIS也有一些第三方的ISAPI可以實現同樣的功能。當然，偽造refer也可以通過代碼來實現盜鏈，不過目前蓄意偽造refer盜鏈的還不多，可以先不去考慮，或者使用非技術手段來解決，比如在圖片上增加水印。
四，控制大文件的下載。
大文件的下載會佔用很大的流量，並且對於非SCSI硬碟來說，大量文件下載會消耗CPU，使得網站響應能力下降。因此，盡量不要提供超過2M的大文件下載，如果需要提供，建議將大文件放在另外一台伺服器上。
6、請問負載均衡的伺服器掛了怎麼辦
盡管有多種的負載均衡演算法可以較好的把數據流量分配給伺服器去負載，但如果負載均衡策略沒有對網路系統狀況的檢測方式和能力，一旦在某台伺服器或某段負載均衡設備與伺服器網路間出現故障的情況下，負載均衡設備依然把一部分數據流量引向那台伺服器，這勢必造成大量的服務請求被丟失，達不到不間斷可用性的要求。所以良好的負載均衡策略應有對網路故障、伺服器系統故障、應用服務故障的檢測方式和能力： 1、Ping偵測：通過ping的方式檢測伺服器及網路系統狀況，此種方式簡單快速，但只能大致檢測出網路及伺服器上的操作系統是否正常，對伺服器上的應用服務檢測就無能為力了。 2、TCP Open偵測：每個服務都會開放某個通過TCP連接，檢測伺服器上某個TCP埠（如Telnet的23口，HTTP的80口等）是否開放來判斷服務是否正常。 3、HTTP URL偵測：比如向HTTP伺服器發出一個對main.html文件的訪問請求，如果收到錯誤信息，則認為伺服器出現故障。 負載均衡策略的優劣除受上面所講的兩個因素影響外，在有些應用情況下，我們需要將來自同一客戶端的所有請求都分配給同一台伺服器去負擔，例如伺服器將客戶端注冊、購物等服務請求信息保存的本地資料庫的情況下，把客戶端的子請求分配給同一台伺服器來處理就顯的至關重要了。有兩種方式可以解決此問題，一是根據IP地址把來自同一客戶端的多次請求分配給同一台伺服器處理，客戶端IP地址與伺服器的對應信息是保存在負載均衡設備上的；二是在客戶端瀏覽器cookie內做獨一無二的標識來把多次請求分配給同一台伺服器處理，適合通過代理伺服器上網的客戶端。 還有一種路徑外返回模式（Out of Path Return），當客戶端連接請求發送給負載均衡設備的時候，中心負載均衡設備將請求引向某個伺服器，伺服器的回應請求不再返回給中心負載均衡設備，即繞過流量分配器，直接返回給客戶端，因此中心負載均衡設備只負責接受並轉發請求，其網路負擔就減
7、怎樣處理伺服器負載量過大
一，確認伺服器硬體是否足夠支持當前的流量。
二，優化資料庫訪問。
伺服器的負載過大，一個重要的原因是CPU負荷過大，降低伺服器CPU的負荷，才能夠有效打破瓶頸。而使用靜態頁面可以使得CPU的負荷最小化。前台實現完全的靜態化當然最好，可以完全不用訪問資料庫，不過對於頻繁更新的網站，靜態化往往不能滿足某些功能。
緩存技術就是另一個解決方案，就是將動態數據存儲到緩存文件中，動態網頁直接調用這些文件，而不必再訪問資料庫，WordPress和Z-Blog都大量使用這種緩存技術。
如果確實無法避免對資料庫的訪問，那麼可以嘗試優化資料庫的查詢SQL.避免使用Select *from這樣的語句，每次查詢只返回自己需要的結果，避免短時間內的大量SQL查詢。
三，禁止外部的盜鏈。
外部網站的圖片或者文件盜鏈往往會帶來大量的負載壓力，因此應該嚴格限制外部對於自身的圖片或者文件盜鏈，好在目前可以簡單地通過refer來控制盜鏈，Apache自己就可以通過配置來禁止盜鏈，IIS也有一些第三方的ISAPI可以實現同樣的功能。當然，偽造refer也可以通過代碼來實現盜鏈，不過目前蓄意偽造refer盜鏈的還不多，可以先不去考慮，或者使用非技術手段來解決，比如在圖片上增加水印。
四，控制大文件的下載。
大文件的下載會佔用很大的流量，並且對於非SCSI硬碟來說，大量文件下載會消耗CPU，使得網站響應能力下降。因此，盡量不要提供超過2M的大文件下載，如果需要提供，建議將大文件放在另外一台伺服器上。
8、多台伺服器負載均衡，怎麼選擇？
一般用的就用簡單的輪詢就好了
調度演算法
靜態方法：僅根據演算法本身實現調度；實現起點公平，不管伺服器當前處理多少請求，分配的數量一致
動態方法：根據演算法及後端RS當前的負載狀況實現調度；不管以前分了多少，只看分配的結果是不是公平
靜態調度演算法(static Sche)（4種）:
(1)rr (Round Robin) :輪叫,輪詢
說明：輪詢調度演算法的原理是每一次把來自用戶的請求輪流分配給內部中的伺服器，從1開始，直到N(內部伺服器個數)，然後重新開始循環。演算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。缺點：是不考慮每台伺服器的處理能力。
(2)wrr (Weight Round Robin) :加權輪詢(以權重之間的比例實現在各主機之間進行調度)
說明：由於每台伺服器的配置、安裝的業務應用等不同，其處理能力會不一樣。所以，我們根據伺服器的不同處理能力，給每個伺服器分配不同的權值，使其能夠接受相應權值數的服務請求。
(3)sh (Source Hashing) : 源地址hash實現會話綁定sessionaffinity
說明：簡單的說就是有將同一客戶端的請求發給同一個real server,源地址散列調度演算法正好與目標地址散列調度演算法相反，它根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的並且沒有超負荷，將請求發送到該伺服器，否則返回空。它採用的散列函數與目標地址散列調度演算法的相同。它的演算法流程與目標地址散列調度演算法的基本相似，除了將請求的目標IP地址換成請求的源IP地址。
(4)dh : (Destination Hashing) : 目標地址hash
說明：將同樣的請求發送給同一個server,一般用於緩存伺服器，簡單的說，LB集群後面又加了一層，在LB與realserver之間加了一層緩存伺服器，當一個客戶端請求一個頁面時,LB發給cache1,當第二個客戶端請求同樣的頁面時，LB還是發給cache1,這就是我們所說的，將同樣的請求發給同一個server,來提高緩存的命中率。目標地址散列調度演算法也是針對目標IP地址的負載均衡，它是一種靜態映射演算法，通過一個散列（Hash）函數將一個目標IP地址映射到一台伺服器。目標地址散列調度演算法先根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。
動態調度演算法(dynamic Sche)（6種）:
(1)lc (Least-Connection Scheling): 最少連接
說明：最少連接調度演算法是把新的連接請求分配到當前連接數最小的伺服器，最小連接調度是一種動態調度短演算法，它通過伺服器當前所活躍的連接數來估計伺服器的負載均衡，調度器需要記錄各個伺服器已建立連接的數目，當一個請求被調度到某台伺服器，其連接數加1，當連接中止或超時，其連接數減一，在系統實現時，我們也引入當伺服器的權值為0時，表示該伺服器不可用而不被調度。此演算法忽略了伺服器的性能問題，有的伺服器性能好，有的伺服器性能差，通過加權重來區分性能，所以有了下面演算法wlc。
簡單演算法：active*256+inactive (誰的小，挑誰)
(2)wlc (Weighted Least-Connection Scheling):加權最少連接
加權最小連接調度演算法是最小連接調度的超集，各個伺服器用相應的權值表示其處理性能。伺服器的預設權值為1，系統管理員可以動態地設置伺服器的許可權，加權最小連接調度在調度新連接時盡可能使伺服器的已建立連接數和其權值成比例。由於伺服器的性能不同，我們給性能相對好的伺服器，加大權重，即會接收到更多的請求。
簡單演算法：（active*256+inactive）/weight（誰的小，挑誰）
(3)sed (shortest expected delay scheling):最少期望延遲
說明：不考慮非活動連接，誰的權重大，我們優先選擇權重大的伺服器來接收請求，但會出現問題，就是權重比較大的伺服器會很忙，但權重相對較小的伺服器很閑，甚至會接收不到請求，所以便有了下面的演算法nq。
基於wlc演算法，簡單演算法：（active+1)*256/weight （誰的小選誰）
(4).nq (Never Queue Scheling): 永不排隊
說明：在上面我們說明了，由於某台伺服器的權重較小，比較空閑，甚至接收不到請求，而權重大的伺服器會很忙，所此演算法是sed改進，就是說不管你的權重多大都會被分配到請求。簡單說，無需隊列，如果有台real server的連接數為0就直接分配過去，不需要在進行sed運算。
(5).LBLC(Locality-Based Least Connections) :基於局部性的最少連接
說明：基於局部性的最少連接演算法是針對請求報文的目標IP地址的負載均衡調度，主要用於Cache集群系統，因為Cache集群中客戶請求報文的目標IP地址是變化的，這里假設任何後端伺服器都可以處理任何請求，演算法的設計目標在伺服器的負載基本平衡的情況下，將相同的目標IP地址的請求調度到同一個台伺服器，來提高伺服器的訪問局部性和主存Cache命中率，從而調整整個集群系統的處理能力。
(6).LBLCR(Locality-Based Least Connections with Replication) :基於局部性的帶復制功能的最少連接
說明：基於局部性的帶復制功能的最少連接調度演算法也是針對目標IP地址的負載均衡，該演算法根據請求的目標IP地址找出該目標IP地 址對應的伺服器組，按「最小連接」原則從伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器；若伺服器超載，則按「最小連接」原則從這個集群中選出一台伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除， 以降低復制的程度。
9、魔獸世界選擇伺服器是負載高的好還是中的好？
如果你是休閑玩家，選擇高，因為當你不怎麼上線又偶然上線的話，有人~！
如果你是一般玩家，比如每次都參加公會活動，又不是很高端要沖FD的話，也選擇高，因為還是人多幹啥都方便。
如果你是超級玩家，要各種沖FD，那麼就選擇鬼F了，不過當你問這個問題，說明你不是沖FD的骨灰，所以就還是選高了。
最後一個重點，如果你選擇了高，就別玩獵人，不然好看稀有的BB你是抓不到了。
陣營比不是太重要，現在野外PVP的數量太少了
10、什麼是負載均衡伺服器？
在網路應用中，有時會使用多台伺服器提供同一個服務，負載均衡就是把壓力平均分配給每台伺服器，比如使用DNS負載均衡就是最有效有簡單的一個方法，你可以去試試DNSPOD提供的智能解析，他里邊就包含負載均衡功能，我很多朋友都在用，很穩定也很強大~ dnspod＊cn