數據處理：計算機從磁盤（硬盤）上讀出數據并存儲到內存上，然后CPU會從內存上取得數據進行處理。而且，從內存上取得的指令會緩存到更高速的CPU緩存中。所以，數據處理要經過磁盤T內存T緩存-CPU多層才能被處理。橫向擴展（scaleout）：通過增加服務器數量來提高系統整體的處理能力并分擔負載。縱向擴展（scaleup）：通過提高硬件性能來提高處理能力的方法。系統負載情況處理：對于I/O負載較高的服務器擴展其內存對于CPU負載高的服務器升級其CPU。開發所用的工具：編程語言Perl、C/C++、JavaScript等。主要中間件：MySQL、SQLsever等。Web應用程序的框架默認的aspx框架。大規模數據處理的難點：內存和磁盤當大規模數據處理時，會遇到“無法在內存中計算”的問題。導致數據“無法在內存中計算”的原因是因為數據如果在內存中放不下的話，通常就得一直讀磁盤，在磁盤中找啊找還是找不到。數據量過大時，其輸入數據量也就增大，計算量當然也會增大，更嚴重問題是“需要讀取磁盤”。（但磁盤是十分緩慢的，I/O會耗費很多時間，導致系統過慢。）內存和磁盤的速度差異：內存比磁盤要快1000W倍！！（簡單了解磁盤和內存搜索數據的原理就知道）Linux單主機的負載尋找瓶頸的基本流程：1?查看平均負載（Loadaverage）o2.確認CPU、I/O有無瓶頸。査看平均負載（Loadaverage）方法：命令：top\uptime。平均負載是指示系統全體負載狀況的指標。平均負載低，吞吐量也低的情況下，應該先檢查軟件設置是否異常，檢查網絡和遠程主機是否存在故障等。（吞吐量：每秒的數據處理量。是在給定時間段內系統完成的交易數量。即系統的吞吐量越大，說明系統在單位時間內完成的用戶或系統請求越多，系統的資源得到充分利用。）査找CPU和I/O的瓶頸方法：當平均負載過高時，要要CPU或I/O中尋找原因osar或vmstat可以查看CPU使用率和I/O等待率隨著時間的推移情況，可以作為參考。?“CPU負載”過高時，用以下流程尋找原因：1?確認是用戶程序處理的瓶頸，還是系統程序的原因。用top或sar確認。Top的輸出結果中包含名為“loadaverage”的數字。Loadaverage:0.70,0.66,0.59平均負載從左到右分別為1分鐘、5分鐘、15分鐘內，單位時間中處于等待狀態的任務。（也就是說，此數字報告了平均有多少任務在等待，平均負載高，說明有相應數量的任務在等待，可以認為運行有延遲，也就是負載過高。）再通過ps查看可見進程的狀態和CPU使用時間等，確認導致問題的進程。確定進程之后，想要進一步尋找原因的話，可以通過strace跟蹤，或oprofile進行剖測，以確定瓶頸所在。（一般來說，CPU負載是由于以下兩者原因之一引起：1?磁盤或內存容量等其他部分沒有成為瓶頸，即處于理想狀態。2.程序失控，需要消耗過多的CPU。如果是前者并且系統的吞吐量有問題的話，可以采取增加服務器、改善程序邏輯和算法的方式。如果中后者，則要去除故障，避免程序失控。）?“I/O負載”過高時，用以下流程尋找原因：“I/O負載”過高，其原因多半是程序發出的I/O請求過多導致負載過高，或是發生頁面交換導致頻繁訪問磁盤。可以通過sar或vmstat確認交換區狀態，找出原因。>根據確認結果，如果是發生頁面交換的情況，應該從發下幾點著手調查：1?用ps確認是否進程消耗了大量內存。如果由于程序故障造成內存消耗過大，應該改進程序。如果是因為內存安裝不足，就要增加內存。無法增加內存時考慮分布式。>根據確認結果，如果是沒有交換發生的情況，而且磁盤I/O頻繁的情況，可能是用于緩存的內存不足。根據服務器擁有的數據量和可增加的內存量，按照以下步驟選擇應對方法：1）如果通過增加內存可以擴大緩存，就增加內存。2）如果增加內存還不夠用，就考慮分散存儲數據，或是增加緩存服務器等。改進I/O頻率也是一種方法。改善I/O性能，需要確認發下幾點：能否通過增加內存以保證緩存區域的方法解決。數據量是否本來就過多。有無必要改變應用程序的I/O算法。Web應用程序和負載的關系在Web應用程序中，Web應用程序在進行計算時，也就是接受HTTP請求、查詢數據庫,再把數據庫返回的數據加工變成HTML發送給客戶端，基本上應用服務器只消耗CPU。相反,數據庫服務器則需要較多I/O資源，產生I/O負載。Web應用程序的三層結構：代理服務器、應用程序服務器、數據庫組成。如果在應用程序中只造成CPU負載，只需要增加相同結構的應用程序服務器通過負載均衡就可以了。因為應用程序服務器只消耗CPU資源，不需要分散數據，增加多臺服務器作為負載均衡器均勻地分發請求就OK了。但是，如果是I/O負載的問題。只使用增加數據庫的方法是不正確的。因為要考慮到兩個數據庫之間數據同步的問題(例如，寫入數據庫A中的數據，怎么寫的數據庫B中呢？寫入的分布式是很困難的)。特別是大規模的數據量時就更難。還有，在前面說過，1/0是跟磁盤有關系的。當數據量太大，導致無法在內存處理時，就必然使用到磁盤。如果在兩個數據庫中進行大量的磁盤讀/寫操作，就會有大量磁盤I/O的產生。而磁盤的速度是很慢的，計算密集型程序(CPUbound)：有一個執行大規模科學計算的程序，雖然此程序與磁盤無數據I/O,但完成處理需要很長時間，從“執行計算”可得知該程序的處理速度依賴CPU的計算速度。這就是產生CPU負載的程序，也稱之為“計算密集型程序“。I/O密集型程序(I/Obound)：假設有一個從保存在磁盤上的大量數據中搜索出任意文檔的程序。該搜索程序的處理速度不依賴于CPU，而是依賴于磁盤的讀取速度，即I/O。磁盤轉速越快，搜索用時就越短。這種給I/O加上負載的程序也稱之為“I/O密集型程序“。一般情況下，應用程序服務器從數據庫是獲取數據，加工后發送給客戶端的過程很少產生大規模的I/O。因此，大多數情況下應用程序服務器是計算密集型的服務器。相反，數據庫服務器則是I/O密集型程序。通過sar查看CPU使用率和I/O等待率Sar（SystemActivityReporter）：查看系統狀況報告的工具。它能列出各個時間點的負載指標以便比較。在計算密集型系統上查看sar執行結果“％user”是CPU在用戶模式下的使用率°“％system”是系統模式下的使用率。平均負載過高，且CPU使用率也高的話，就可以判斷出進程等待的高負載原因就是CPU資源不足。在sar命令上加上選項-p,可以查看四核CPU（現在Intel架構的CPU都是多核的了，就是指只有一個物理CPU,卻能看成是多個CPU）服務器上執行結果。加上輸入sar-命令之后分別看到（0、1、2、3、）四個CPUID。以及四個CPU的使用率統計結果（在計算型密集服務器上每個CPU都能夠均衡負載）。在I/O密集型服務器上査看sar執行結果：“％iowait”是I/O等待率。平均負載過高并且“％iowait”數值也過高的話，可以認為高負載的原因是I/O。在sar命令上加上選項-p,可以查看四核CPU服務器上的執行結果。結果出乎意料，I/O等待只