服務器集羣及優化筆記

 

高性能的服務器的架設

 

對於高性能網站 ,請求量大,如何支撐?

1方面,要減小請求

對於開發人員----合併css, 背景圖片, 減小mysql查詢等.

 

2: 對於運維 nginx的expires ,利用瀏覽器緩存等,減小查詢.

3: 利用cdn來響應請求

 

4: 最終剩下的,不可避免的請求----服務器集羣+負載均衡來支撐.

 

因此,來到第4步後,就不要再考慮減小請求這個方向了.

而是思考如何更好的響應高併發請求.

 

大的認識-------既然響應是不可避免的,咱們要作的是把工做內容」平均」分給每臺服務器.

最理想的狀態 每臺服務器的性能都被充分利用.

 

 

 

 

服務器介紹:

 

服務器IP:

A  192.168.1.201

B  192.168.1.202

C 203

D204

 

Root: zixue.it

 

 

1臺 A

RAM: 2G

HD: 500G

 

 

3臺 B, C, D

RAM: 8G

Hd  : 200G

 

步驟:

1:A號服務器

           1.1安裝 mysql

    1.2並導入數據.

注意:先把表中的索引去掉,加快導入速度

 

2: C號服務器:

  2.1: 編譯PHP

注意: enbale-fpm , with-mysql=mysqlnd   (編譯成獨立fpm進程,支持mysql,)

  2.2: 下載第3方的memcached擴展 編譯進來

 

3: D號服:

  3.1 編譯 memcached

 

4: B號服:

編譯nginx ,並配置

Cd /app/pcre-8.12

./configure

Make && make install

 

Cd nginx-1.2.7

./configure --prefix=/usr/local/nginx --add-module=/app/ngx_http_consistent_hash-master

注:紅線部分是nginx的第3方模塊,須要本身下載.

 

 

安裝統計模塊,便於觀察nginx的狀態

./configure --prefix=/usr/local/nginx/ --add-module=/app/ngx_http_consistent_hash-master --with-http_stub_status_module

 

 

 

 

 

 

Php 安裝配置

1 tar -xzvf  /path/’

2 cd /path/

3 .configure --prefix=/usr/local/php --

 

 

 

 

服務器集羣與負載均衡搭建完畢

1:問題  C-->A 的mysql鏈接很慢

解決: my.cnf中的[mysqld]節點中,添加

skip-name-resolve   // 這句話使mysql鏈接時忽略解析域名,在制定Mysql權限時,只能根據IP限制,不能根據域名限制.

 

2: 問題  當memcache中沒有相應的數據,從後臺回調數據時,

http的狀態碼是404,(雖然內容正常),這樣不利於SEO

解決: nginx/conf/nginx.conf

 error_page 404  =200 /callback.php;  // 這樣 404被改寫成200來響應中

 

 

 

壓力測試:

模擬 前0-10萬是熱數據,

10-20萬是冷門數據

 

請求熱數據 0-10,請求9次

請求准予數據 請求1次,     -----100萬次的請求.

 

 

優化思路:

nginx響應請求

1:創建socket鏈接

2: 打開文件,並沿socket返回.

 

排查問題,也要注意觀察這兩點,

主要從系統的dmesg ,和nginx的error.log來觀察

 

 

 

1:判斷nginx的瓶頸

 

1.1: 首先把ab測試端的性能提升,使之能高併發的請求.

易出問題: too many open files

緣由 :  ab在壓力測試時,打開的socket過多

解決: ulimit -n 30000 (重啓失效)

觀察結果: nginx 不須要特殊優化的狀況下, 5000個鏈接,1秒內響應.

知足要求,但 wating狀態的鏈接過多.

 

1.2: 解決waiting進程過多的問題.

解決辦法: keepalive_timeout = 0; 

即: 請求結果後,不保留tcp鏈接.

在高併發的狀況下, keepalive會佔據大量的socket鏈接.

結果: waiting狀態的鏈接明顯減小.

 

1.3: 解決服務端 too many open files

分析: nginx要響應,

1是要創建socket鏈接,

2 是要讀本地文件

這兩個者限制.

 

 

 

 

 

由上圖可看出,nginx的問題容易出在2點上:

1: nginx接受的tcp鏈接多,可否創建起來?

2: nginx響應過程,要打開許多文件 ,可否打開?

 

第1個問題: 在內核層面(見下)

第2個問題 (見下)

 

 

系統內核層面:

net.core.somaxconn = 4096 容許等待中的監聽

net.ipv4.tcp_tw_recycle = 1  tcp鏈接快速回收

net.ipv4.tcp_tw_reuse = 1    tcp鏈接重用  

net.ipv4.tcp_syncookies = 0  不抵禦洪水攻擊

ulimit -n 30000

 

 

Nginx層面:

解決: nginx.conf 下面: work_connection 加大

worker_connections  10240;

Worker_rlimit_nofiles 10000;

Keepalive_timeout 0;

 

 

 

 

 

Nginx---->php-fpm之間的優化

 

如上圖,在不少個nginx來訪問fpm時, fpm的進程要是不夠用, 會生成子進程.

 

生成子進程須要內核來調度,比較耗時,

若是網站併發比較大,

咱們能夠用靜態方式一次性生成若干子進程,保持在內存中.

 

方法 -- 修改php-fpm.conf

Pm = static  讓fpm進程始終保持,不要動態生成

Pm.max_children= 32  始終保持的子進程數量

 

 

Php-mysql的優化

 

Linux機器下 ,php 經過IP鏈接其餘mysql服務器時,容易出的問題

能ping能,但connect不到.

 

 

 

通常是由:mysql服務器的防火牆影響的.

 

併發1萬鏈接,響應時間過長.

 

優化思路: 同上的nginx

1: 內核層面,加大鏈接數,並加快tcp回收

2: mysql層面,增大鏈接數

3: php層面,用長鏈接,節省鏈接數

4: 用memcached緩存,減輕mysql負擔

 

具體:

1.1  , PHP服務器增大 ulimint -n選項

1.2 mysql服務器內核配置

添加或修改以下選項

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_syncookies = 0

 

# syscttl -p 使修改當即生效

 

2.1  修改mysql.cnf

Vi  /etc/my.conf

# service mysqld restart 重啓mysql

 

3.1 PHP層面 ,用長鏈接

Mysql_connect ---> mysql_pconnect

注: pconnect 在PHP以apache模塊的形式存在時,無效果.

 

Nginx+phjp+mysql+nginx