Nginx-安裝依賴及配置詳解

時間 2019-12-02

標籤 nginx 安裝依賴配置詳解欄目 Nginx 简体版

原文原文鏈接

依賴javascript

　　在安裝Nginx以前, 需確保系統已經安裝了gcc、 openssl-devel、 pcre-devel和zlib-devel軟件庫php

配置css

　　Nginx的配置文件nginx.conf位於其安裝目錄的conf目錄下html

　　Nginx.conf由多個塊組成, main section、events section、http section、sever section、location section、upstream section, 最外面的塊是main, main包含events和http, http包含upstream和多個server, server又包含多個location：前端

　　main（全局設置）、server（主機設置）、upstream（負載均衡服務器設置）和 location（URL匹配特定位置的設置）java

　　　　main塊設置的指令將影響其餘全部設置node

　　　　server塊的指令主要用於指定主機和端口linux

　　　　upstream指令主要用於負載均衡，設置一系列的後端服務器nginx

　　　　location塊用於匹配網頁位置web

　　這四者之間的關係式：server繼承main, location繼承server, upstream既不會繼承其餘設置也不會被繼承
　　在這四個部分當中, 每一個部分都包含若干指令, 這些指令主要包含Nginx的主模塊指令、事件模塊指令、HTTP核心模塊指令, 同時每一個部分還可使用其餘HTTP模塊指令, 例如Http SSL模塊、HttpGzip Static模塊和Http Addition模塊等

　　nginx是由模塊組成的，這些模塊在配置文件中又有指定的指令。指令被分紅簡單指令和塊指令。簡單指令包括名稱和用空格分割的參數以及用來結尾的分號(;)。一個塊指令和簡單指令有相同的結構，可是它使用大括號({and})來包圍一系列說明來替代使用分號做爲結尾。若是一個塊指令在大括號中有其餘的指令，則稱之爲上下文（如：events,http,server, 和location）。
　　放在配置文件最外面的指令的稱之爲主文，event,http指令在主文中；server在http中，location在server中。

　　http: 通常狀況下，配置文件中包含多個server塊，它們之間以監聽的端口號和server name來區分。一旦nginx決定了哪一個server處理請求，它測試在請求的對server塊內定義的位置指令的參數頭中指定的URI。

　　　　server: 若是有多個匹配的location塊，nginx會選擇前綴最長的。

server {
    location / {
        root /data/www;
    }
    location /images/ {
        root /data;
    }
}

　　　　例如，響應 http://localhost/images/example.png 路由請求，nginx將會發送/data/images/example.png文件。

　　　　不帶/images/的URIs請求將會映射到/data/www目錄。
　　　　例如，爲了響應http://localhost/some/example.html請求，nginx將會發送/data/www/some/example.html文件

　　main module: 主要控制子進程的所屬用戶/用戶組、派生子進程數、錯誤日誌位置/級別、pid位置、子進程優先級、進程對應cpu、進程可以打開的文件描述符數目等

#user是個主模塊指令, 指定Nginx Worker進程運行用戶以及用戶組, 默認由nobody帳號運行
user  nobody nobody;

#worker_processes是個主模塊指令, 指定了Nginx要開啓的進程數, 每一個Nginx進程平均耗費10M~12M內存, 建議指定和CPU的數量一致便可
worker_processes  8;

#Nginx默認沒有開啓利用多核cpu，咱們能夠經過增長worker_cpu_affinity配置參數來充分利用多核cpu的性能。cpu是任務處理，計算最關鍵的資源，cpu核越多，性能就越好。cpu有多少個核，就有幾位數，1表明內核開啓，0表明內核關閉。worker_processes最多開啓8個，8個以上性能就不會再提高了，並且穩定性會變的更低，所以8個進程夠用了。

#詳情參考下文中的進程數與CPU核數對應配置
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;


#error_log是個主模塊指令, 用來定義全局錯誤日誌文件, 日誌輸出級別有debug、info、notice、warn、error、crit可供選擇, 其中, debug輸出日誌最爲最詳細, 而crit輸出日誌最少
error_log  logs/error.log  notice;

#pid是個主模塊指令, 用來指定進程pid的存儲文件位置(kill -9 `cat /usr/local/nginx/logs/nginx.pid`)
pid        logs/nginx.pid;

#worker_rlimit_nofile用於綁定worker進程和CPU, Linux內核2.4以上可用
#這個指令是指當一個nginx進程打開的最多文件描述符數目, 理論值應該是最多打開文  件數（ulimit -n）與nginx進程數相除
#可是nginx分配請求並非那麼均勻, 因此最好與ulimit -n 的值保持一致
#如今在linux 2.6內核下開啓文件打開數爲65535, worker_rlimit_nofile就相應應該填寫65535
這是由於nginx調度時分配請求到進程並非那麼的均衡, 因此假如填寫10240, 總併發量達到3-4萬時就有進程可能超過10240了, 這時會返回502錯誤
worker_rlimit_nofile 65535;

　　events module: 設定Nginx的工做模式(Nginx處理鏈接的方式)及鏈接數上限

events {
    #使用網絡的I/O模型
    #補充說明:
    #與apache類似, nginx針對不一樣的操做系統, 有不一樣的事件模型
    #A）標準事件模型
    #Select、poll屬於標準事件模型, 若是當前系統不存在更有效的方法, nginx會選擇select或poll, 使用網絡IO模型
    #B）高效事件模型
    #Kqueue: 使用於FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使用雙處理器的MacOS X系統使用kqueue可能會形成內核崩潰
    #Epoll: 使用於Linux內核2.6版本及之後的系統
    #/dev/poll: 使用於Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+
    #Eventport: 使用於Solaris 10. 爲了防止出現內核崩潰的問題, 有必要安裝安全補丁
    #Linux下效率最高的是epoll模型
    use epoll;

    #每一個進程容許的最多鏈接數, 根據硬件調整, 和前面工做進程配合起來用, 儘可能大, 可是別把cpu跑到100%就行
    #理論上每臺nginx服務器的 最大鏈接數 = worker_processes*worker_connections
    #不少人會誤解worker_connections這個參數的意思，認爲這個值就是nginx所能創建鏈接的最大值。其實否則，這個值是表示每一個worker進程所能創建鏈接的最大值。
    #因此，一個nginx能創建的最大鏈接數，應該是worker_connections * worker_processes。
    #固然 ，這裏說的是最大鏈接數，對於HTTP請求本地資源來講，可以支持的最大併發數量是worker_connections * worker_processes。
    #而若是是HTTP做爲反向代理來講，最大併發數量應該是worker_connections * worker_processes/2。由於做爲反向代理服務器，每一個併發會創建與客戶端的鏈接和與後端服務的鏈接，會佔用兩個鏈接。
    #worker_connections 值的設置跟物理內存大小有關
    #默認是1024, 考慮到keep-alive爲60秒, 每一個瀏覽器平均消耗兩個連接（chrom會同時打開多個鏈接提升加載速度）
    #那麼平均每秒處理 1024 / 60 / 2 = 8.5, 一天能夠處理 8.5 * 86400 = 734400, 至關於天天有70萬IP。
    #由於併發受IO約束, 最大鏈接數的值須小於系統能夠打開的最大文件數
    #而系統能夠打開的最大文件數和內存大小成正比, 通常1GB內存的機器上能夠打開的文件數大約是10萬左右
    #咱們來看看360M內存的VPS能夠打開的文件句柄數是多少：
    #$ cat /proc/sys/fs/file-max
    #輸出 34336
    #32000 < 34336, 即併發鏈接總數小於系統能夠打開的文件句柄總數, 這樣就在操做系統能夠承受的範圍以內
    #因此, worker_connections 的值需根據 worker_processes 進程數目和系統能夠打開的最大文件總數進行適當地進行設置
    #使得併發總數小於操做系統能夠打開的最大文件數目
    #其實質也就是根據主機的物理CPU和內存進行配置
    #固然, 理論上的併發總數可能會和實際有所誤差, 由於主機還有其餘的工做進程須要消耗系統資源
    #ulimit -SHn 65535
    #進程的最大鏈接數受Linux系統進程的最大打開文件數限制, 在執行操做系統命令`ulimit -n 65536`後worker_connections的設置才能生效
　　 worker_connections 204800;

    #長鏈接過時時間, 10~20比較合理
    keepalive_timeout 60;

    #客戶端請求頭部的緩衝區大小, 這個能夠根據你的系統分頁大小來設置
    #通常一個請求頭的大小不會超過1k, 不過因爲通常系統分頁都要大於1k, 因此這裏設置爲分頁大小
    #分頁大小能夠用命令 ·getconf PAGESIZE· 取得
    #但也有client_header_buffer_size超過4k的狀況, 可是client_header_buffer_size該值必須設置爲「系統分頁大小」的整倍數
    client_header_buffer_size 4k;

    #這個將爲打開文件指定緩存, 默認是沒有啓用的, max指定緩存數量, 建議和打開文件數一致
    #inactive是指通過多長時間文件沒被請求後刪除緩存
    open_file_cache max=65535 inactive=60s;

    #這個是指多長時間檢查一次緩存的有效信息
    open_file_cache_valid 80s;

    #open_file_cache指令中的inactive參數時間內文件的最少使用次數, 若是超過這個數字, 文件描述符一直是在緩存中打開的, 如上例, 若是有一個文件在inactive時間內一次沒被使用, 它將被移除
    open_file_cache_min_uses 1;
}

　　http module: 配置http服務器相關屬性(能夠利用它的反向代理功能提供負載均衡支持, 以及正向代理的X牆)

http {
    #include是個主模塊指令, 實現對配置文件所包含的文件的設定, 能夠減小主配置文件的複雜度
    #相似於Apache中的include方法
    include mime.types;
    
    #屬於HTTP核心模塊指令, 這裏設定默認類型爲二進制流, 也就是當文件類型未定義時使用這種方式
    #例如在沒有配置PHP環境時, Nginx是不予解析的, 此時, 用瀏覽器訪問PHP文件就會出現下載窗口
    default_type application/octet-stream;
    
    #log_format是Nginx的HttpLog模塊指令, 用於指定Nginx日誌的輸出格式。main爲此日誌輸出格式的名稱, 能夠在下面的access_log指令中引用
    #$remote_addr與$http_x_forwarded_for用以記錄客戶端的ip地址；
    #$remote_user：用來記錄客戶端用戶名稱；
    #$time_local： 用來記錄訪問時間與時區；
    #$request： 用來記錄請求的url與http協議；
    #$status： 用來記錄請求狀態；成功是200, 
    #$body_bytes_s ent ：記錄發送給客戶端文件主體內容大小；
    #$http_referer：用來記錄從那個頁面連接訪問過來的；
    #$http_user_agent：記錄客戶毒啊瀏覽器的相關信息；
    #一般web服務器放在反向代理的後面, 這樣就不能獲取到客戶的IP地址了, 經過$remote_add拿到的IP地址是反向代理服務器的iP地址
    #反向代理服務器在轉發請求的http頭信息中, 能夠增長x_forwarded_for信息, 用以記錄原有客戶端的IP地址和原來客戶端的請求的服務器地址
    log_format main '$host $status [$time_local] $remote_addr [$time_local] $request_uri '
        '"$http_referer" "$http_user_agent" "$http_x_forwarded_for" '
        '$bytes_sent $request_time $sent_http_x_cache_hit';
        log_format log404 '$status [$time_local] $remote_addr $host$request_uri $sent_http_location';
    
    #設置了log_format確定要設置日誌存放路徑
    access_log /usr/local/nginx/logs/access_log main; 
        
    #用來設置容許客戶端請求的最大的單個文件字節數
    client_max_body_size 20m;
    
    #用來指定客戶端請求中較大的消息頭的緩存最大數量和大小,  「4」爲個數, 「128K」爲大小, 最大緩存量爲4個128K
    large_client_header_buffers 32K;
    
    #用於開啓高效文件傳輸模式
    sendfile on；
    
    #將tcp_nopush和tcp_nodelay兩個指令設置爲on用於防止網絡阻塞
    tcp_nopush on;
    tcp_nodelay on;
    
    #設置客戶端鏈接保持活動的超時時間, 在超過這個時間以後, 服務器會關閉該鏈接
    keepalive_timeout 60;
    
    #指定響應客戶端的超時時間, 這個超時僅限於兩個鏈接活動之間的時間, 若是超過這個時間, 客戶端沒有任何活動, Nginx將會關閉鏈接
    send_timeout 10;
    
    #gzip用於設置開啓或者關閉gzip模塊, 「gzip on」表示開啓GZIP壓縮, 實時壓縮輸出數據流
    gzip  on;
    
    #gzip_min_length設置容許壓縮的頁面最小字節數, 頁面字節數從header頭的Content-Length中獲取
    #默認值是0, 即無論頁面多大都進行壓縮, 建議設置成大於1K的字節數, 小於1K可能會越壓越大
    gzip_min_length  1k;
    
    #gzip_buffers表示申請4個單位爲16K的內存做爲壓縮結果流緩存, 默認值是申請與原始數據大小相同的內存空間來存儲gzip壓縮結果
    gzip_buffers     4  16k;
    
    #gzip_http_version用於設置識別HTTP協議版本, 默認是1.1, 目前大部分瀏覽器已經支持GZIP解壓, 使用默認便可
    gzip_http_version  1.1;
    
    #gzip_comp_level用來指定GZIP壓縮比
    #1 壓縮比最小, 處理速度最快
    #9 壓縮比最大, 傳輸速度快, 但處理最慢, 也比較消耗cpu資源
    gzip_comp_level  2;
    
    #gzip_types用來指定壓縮的類型, 不管是否指定, 「text/html」類型老是會被壓縮的
    gzip_types  text/plain application/x-javascript text/css application/xml;
    
    #gzip_vary選項可讓前端的緩存服務器緩存通過GZIP壓縮的頁面, 例如用Squid緩存通過Nginx壓縮的數據
    gzip_vary  on;
    
    #保存服務器名字的hash表是由指令server_names_hash_max_size和server_names_hash_bucket_size所控制的
    #參數hash_bucket_size老是等於hash表的大小, 而且是一路處理器緩存大小的倍數
    #在減小了在內存中的存取次數後, 使在處理器中加速查找hash表鍵值成爲可能
    #若是hash_bucket_size等於一路處理器緩存的大小, 那麼在查找鍵的時候, 最壞的狀況下在內存中查找的次數爲2
    #第一次是肯定存儲單元的地址, 第二次是在存儲單元中查找鍵值
    #所以, 若是Nginx給出須要增大hash_max_size或hash_bucket_size的提示, 那麼首要的是增大前一個參數的大小.
    server_names_hash_bucket_size 128;
    
    #客戶端請求頭部的緩衝區大小, 這個能夠根據你的系統分頁大小來設置, 通常一個請求的頭部大小不會超過1k
    #不過因爲通常系統分頁都要大於1k, 因此這裏設置爲分頁大小, 分頁大小能夠用命令`getconf PAGESIZE`取得
    client_header_buffer_size 4k;
    
    #客戶請求頭緩衝大小, Nginx默認會用client_header_buffer_size這個buffer來讀取header值
    #若是header過大, 它會使用large_client_header_buffers來讀取
    #若是設置太小HTTP頭/Cookie過大 會報400 錯誤nginx 400 bad request求行
    #若是超過buffer, 就會報HTTP 414錯誤(URI Too Long)
    #nginx接受最長的HTTP頭部大小必須比其中一個buffer大, 不然就會報400的HTTP錯誤(Bad Request)
    large_client_header_buffers 8 128k;
    
    #使用字段:http, server, location 這個指令指定緩存是否啓用,若是啓用,將記錄文件如下信息:
    #打開的文件描述符,大小信息和修改時間. ·存在的目錄信息. ·在搜索文件過程當中的錯誤信息 --沒有這個文件,沒法正確讀取,參考open_file_cache_errors指令選項:
    #·max -指定緩存的最大數目,若是緩存溢出,最長使用過的文件(LRU)將被移除
    #例: open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;
    open_file_cache max 102400

    #語法:open_file_cache_errors on | off 默認值:open_file_cache_errors off 使用字段:http, server, location 這個指令指定是否在搜索一個文件是記錄cache錯誤.
    open_file_cache_errors on;
    
    #語法:open_file_cache_min_uses number 默認值:open_file_cache_min_uses 1 使用字段:http, server, location #這個指令指定了在open_file_cache指令無效的參數中必定的時間範圍內可使用的最小文件數,若是使用更大的值,文件描述符在cache中老是打開狀態
    open_file_cache_min_uses on;
    
    #語法:open_file_cache_valid time 默認值:open_file_cache_valid 60 使用字段:http, server, location 這個指令指定了什麼時候須要檢查open_file_cache中緩存項目的有效信息.
    open_file_cache_valid on;
    
    #設定經過nginx上傳文件的大小
    client_max_body_size 300m;
    
    #設置客戶端請求頭讀取超時時間, 若是超過這個時間, 客戶端尚未發送任何數據
    #Nginx將返回「Request time out（408）」錯誤；
    client_header_timeout 10;
    
    #設置客戶端請求主體讀取超時時間, 若是超過這個時間, 客戶端尚未發送任何數據
    #Nginx將返回「Request time out（408）」錯誤, 默認值是60；
    client_body_timeout 10;
}

　　server module: 虛擬主機配置, 建議將對虛擬主機進行配置的內容寫進另一個文件，而後在http module中經過include指令包含進來，這樣更便於維護和管理

server{
    #listen指定虛擬主機的服務監聽端口
    listen          80;
    
    #server_name用來指定IP地址或者域名, 多個域名之間用空格分開
    server_name    192.168.8.18  yilexun.com;
    
    #index用於設定訪問的默認首頁地址
    index index.html index.htm index.php;
    
    #root指令用於指定虛擬主機的網頁根目錄, 這個目錄能夠是相對路徑, 也能夠是絕對路徑
    root  /wwwroot/www.yilexun.com
    
    #charset用於設置網頁的默認編碼格式
    charset gb2312;
    
    #access_log用來指定此虛擬主機的訪問日誌存放路徑, 最後的main用於指定訪問日誌的輸出格式
    access_log  logs/access.log  main;
    
    location ...往下看location module....
}

　　location module: URL地址匹配配置, URL地址匹配是進行Nginx配置中最靈活的部分, location支持正則表達式匹配, 也支持條件判斷匹配, 用戶能夠經過location指令實現Nginx對動、靜態網頁進行過濾處理, 使用location URL匹配配置還能夠實現反向代理, 用於實現PHP動態解析或者負載負載均衡

#默認請求
location / {
    #指定對應目錄 若是沒有指定root則往上級尋找
    root     /wwwroot/www.yilexun.com
    
    #定義首頁索引文件的名稱
    index index.php index.html index.htm;   
}

#定義錯誤提示頁面
#設置了虛擬主機的錯誤信息返回頁面, 經過error_page指令能夠定製各類錯誤信息的返回頁面
#在默認狀況下, Nginx會在主目錄的html目錄中查找指定的返回頁面
#特別須要注意的是, 這些錯誤信息的返回頁面大小必定要超過512K, 否者會被ie瀏覽器替換爲ie默認的錯誤頁面
error_page   404             /404.html;
error_page   500 502 503 504 /50x.html;
location = /50x.html {
    root    /wwwroot/www.yilexun.com/500
}

#圖片請求
#或者其餘JS等請求
#~ 波浪線表示執行一個正則匹配，區分大小寫 
#~* 表示執行一個正則匹配，不區分大小寫 
#^~ 表示普通字符匹配，若是該選項匹配，只匹配該選項，不匹配別的選項，通常用來匹配目錄
#= 進行普通字符精確匹配
#@ 定義一個命名的 location，使用在內部定
#location ~ ^/(images|javascript|js|css|flash|media|static)/ {
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$  {
    #指定對應目錄 若是沒有指定root則往上級尋找
    root    /wwwroot/www.yilexun.com/images;
    
    #過時30天, 靜態文件不怎麼更新, 過時能夠設大一點, 若是頻繁更新, 則能夠設置得小一點
    expires 30d;
}

#PHP, 腳本請求所有轉發到FastCGI處理, 使用FastCGI默認配置
location ~ .php$ {
    #也就是將全部以.php爲後綴的文件都交給本機的9000端口處理, 也可使用unix的sock, 127.0.0.1:9000監聽設置可使用 php-cgi -b 127.0.0.1 或者在 php-fpm.conf 中的 listen 選項中設置
    fastcgi_pass 127.0.0.1:9000;
    
    #設置默認的地址
    fastcgi_index index.php;
    
    #定義$_SERVER['SCRIPT_FILENAME']
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    
    #包含fastcgi_params配置
    include fastcgi_params;
}

#禁止訪問 .htxxx 文件
location ~ /.ht {
    deny all;
}

　　upstream module: 負載均衡配置模塊, Nginx的HTTP Upstream模塊, 這個模塊經過一個簡單的調度算法來實現客戶端IP到後端服務器的負載均衡, 在上面的設定中, 經過upstream指令指定了一個負載均衡器的名稱yilexun.com, 這個名稱能夠任意指定, 在後面須要的地方直接調用便可, 指定設置一羣服務器，服務器能夠指定不一樣的權重

upstream yilexun.com{
    #Nginx的負載均衡模塊目前支持4種調度算法, 下面進行分別介紹, 其中後兩項屬於第三方的調度方法
    #輪詢（默認）: 每一個請求按時間順序逐一分配到不一樣的後端服務器, 若是後端某臺服務器宕機, 故障系統被自動剔除, 使用戶訪問不受影響
    #Weight: 指定輪詢權值, Weight值越大, 分配到的訪問機率越高, 主要用於後端每一個服務器性能不均的狀況下
    #ip_hash: 每一個請求按訪問IP的hash結果分配, 這樣來自同一個IP的訪客固定訪問一個後端服務器, 有效解決了動態網頁存在的session共享問題
    #fair: 比上面兩個更加智能的負載均衡算法, 此種算法能夠依據頁面大小和加載時間長短智能地進行負載均衡
    #也就是根據後端服務器的響應時間來分配請求, 響應時間短的優先分配, Nginx自己是不支持fair的, 若是須要使用這種調度算法, 必須下載Nginx的upstream_fair模塊
    #url_hash: 按訪問url的hash結果來分配請求, 使每一個url定向到同一個後端服務器, 能夠進一步提升後端緩存服務器的效率
    #Nginx自己是不支持url_hash的, 若是須要使用這種調度算法, 必須安裝Nginx的hash軟件包
    ip_hash;
    
    #能夠經過server指令指定後端服務器的IP地址和端口, 同時還能夠設定每一個後端服務器在負載均衡調度中的狀態
    #經常使用的狀態有：
    #down: 表示當前的server暫時不參與負載均衡
    #backup: 預留的備份機器, 當其餘全部的非backup機器出現故障或者忙的時候, 纔會請求backup機器, 所以這臺機器的壓力最輕
    #max_fails: 容許請求失敗的次數, 默認爲1, 當超過最大次數時, 返回proxy_next_upstream模塊定義的錯誤
    #fail_timeout: 在經歷了max_fails次失敗後, 暫停服務的時間, max_fails能夠和fail_timeout一塊兒使用
    #注意, 當負載調度算法爲ip_hash時, 後端服務器在負載均衡調度中的狀態不能是weight和backup
    server 192.168.8.11:80;
    server 192.168.8.12:80  down;
    server 192.168.8.13:8009  max_fails=3  fail_timeout=20s;
    server 192.168.8.146:8080;
}

進程與CPU配置實例：

一、2核CPU，開啓2個進程

worker_processes  2;  
worker_cpu_affinity 01 10;

二、2核CPU，開啓4進程

worker_processes 4;
worker_cpu_affinity 01 10 01 10;

三、2核CPU，開啓8進程

worker_processes  8;  
worker_cpu_affinity 01 10 01 10 01 10 01 10;

四、8核CPU，開啓2進程

worker_processes  2;  
worker_cpu_affinity 10101010 01010101;

說明：10101010表示開啓了第2,4,6,8內核，01010101表示開始了1,3,5,7內核
經過apache 的ab測試查看nginx對CPU的使用情況：

top - 11:25:53 up 39 days,  1:25,  2 users,  load average: 0.33, 0.11, 0.09
Tasks: 133 total,   3 running, 130 sleeping,   0 stopped,   0 zombie
Cpu0  :  2.3%us,  0.9%sy,  0.0%ni, 82.7%id,  0.0%wa,  0.0%hi,  0.0%si, 14.1%st
Cpu1  :  1.7%us,  0.6%sy,  0.0%ni, 81.8%id,  0.0%wa,  0.0%hi,  0.0%si, 16.0%st
Cpu2  :  2.8%us,  1.9%sy,  0.0%ni, 74.4%id,  0.0%wa,  0.0%hi,  0.0%si, 20.9%st
Cpu3  :  2.0%us,  0.9%sy,  0.0%ni, 83.0%id,  0.0%wa,  0.0%hi,  0.0%si, 14.0%st
Cpu4  :  2.2%us,  0.8%sy,  0.0%ni, 79.3%id,  0.0%wa,  0.0%hi,  0.0%si, 17.6%st
Cpu5  :  3.6%us,  1.1%sy,  0.0%ni, 75.9%id,  0.0%wa,  0.0%hi,  0.0%si, 19.5%st
Cpu6  :  2.1%us,  0.9%sy,  0.0%ni, 87.2%id,  0.0%wa,  0.0%hi,  0.0%si,  9.8%st
Cpu7  :  1.7%us,  0.6%sy,  0.0%ni, 80.6%id,  0.0%wa,  0.0%hi,  0.0%si, 17.1%st
Mem:   1024884k total,   891020k used,   133864k free,   144912k buffers
Swap:   262140k total,     4172k used,   257968k free,   434244k cached