服务器集群优化

高性能的服务器的架设

 

对于高性能网站 ,请求量大,如何支撑?

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1500万的企业数据在A号服务器的Mysql上。因此咱们就让A号服务器做为mysql服务器

实际生产环境中，服务器之间是有区别的，有的服务器cpu很是强（好比有8个cpu，每一个cpu还8个核心，计算浮点数很是厉害，优酷土豆作视频压缩，用这个没错），有的用来作存储cpu不必定强，可是硬盘必定要强，有的计算不复杂，可是进程多，好比跑100个php-fpm进程，内存要大。因此要搞清楚服务器当前的业务是计算密集，仍是io密集，仍是进程密集。

 

静态内容，html，缓存，在B

memcached，

 

 

 

 

步骤:

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

注：stub_status_module是一个内建的模块，编译的时候，直接加进去就好了

装完以后，去配置文件配置一下该模块

1. 专门配置一个location
2. 把日志关掉，由于是统计模块，不必加日志
3. 统计模块通常不给人看，因此只容许192.168.1.100访问
4. 其余的都deny

 

配置完以后在192.168.1.100机器上访问192.168.1.202/status就能看到统计信息了，统计信息格式以下图。

 

 

 

压力测试：

安装apache的时候，会有一个小工具ab，位置为：/usr/local/apache/bin/ab 

 

咱们执行上述命令对nginx服务器进行压力测试，1000并发，50000次请求：结果为下图。

失败数量达到3721，很很差。

 

再进行2000并发 80000请求的压力测试：直接报出Too many open files的错误。

缘由：linux系统，以简洁为美。一切皆文件，咱们打开socket链接，也被视为文件，咱们一会儿打开2000个链接，系统以为打开的太多了，不容许。

 

咱们经过以下命令查看：默认只容许打开1024个，果真如此

 

用以下命令修改一下，让他一会儿能打开20000个

 

 

  

 

使用status查看，并发最多才800多，咱们的并发设置是2000，问题很大

又测试了并发 请求

 

nginx相应请求：

1. 创建响应请求的socket链接
2. 打开文件(index.html)，并沿socket返回
3. 万M网卡，可以跑通那么多的流量

那么高并发，无非就是要考虑系统可否让我同时创建如此多的socket链接，和系统是否容许我同时打开那么多的文件（万兆网卡，那时硬件的问题，不考虑。）

因此排查问题也要注意这两点

主要从系统的dmesg和nginx的error.log错误日志来观察

 

下面咱们对于上面高并发出现的问题进行排查，

首先看错误日志

下面的错误日志：报出，open() “index.html” failed ，估计就是因为操做系统是否容许你一个进程打开那么多的html文件形成的

 

使用 ulimit –n命令查看，果真如此。那么进行修改。

 

 

 

修改完毕后，又有洪水攻击

下面图片 显示 洪水攻击，每次请求带一个cookie、过去，防止洪水攻击

 

 

 

 

 

这不是一个文件，是一个系统运行状态值

 

 

 

 

咱们把上面的配置作成一个脚本，方便咱们之后使用

 

一个工做进程容许打开几个文件  worker_rlimit_nofile 10000，放到全局区

 

此时再进行压力测试：轻松达到

 

 

查看status也是如此

 

 

 

 

 

 

 

 

 

1w并发

 

再压力测试

 

 

高并发网站 keepalive  2s之内  最好不用

 

 

keepalive没了

 

 

 

 

 

Php 安装配置

1 tar -xzvf  /path/’

2 cd /path/

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

实际生产中，公司都是用多台服务器专门跑php，每台服务器的9000端口来跑php，可是咱们这里没有那么多台服务器，咱们只有一台，那么咱们就多开几个端口来跑php，9000,9001，9002,9003,9004

 

php-fpm是独立的进程，是由父进程管理着子进程子进程也监听者对应的端口。每来一个请求，就会起一个子进程，可是若是长时间没有请求，那么这个子进程可能就消失(回收)了。可是对于高并发的网站，基本没有停歇的时候，因此咱们就不必让子进程进行回收了

 

让每个主进程地下都存活8个子进程，

 

5*8=40个子进程，一个进程站30多兆内存，加起来也就1-2G

作这么多不一样的配置文件，目的就是让他监听不一样的端口。咱们能够看到php-fpm.conf监听的是9000端口-以下图。在php-fpm9001.conf里面应该监听的就是9001端口，其余同理。

 

 

启动的时候咱们写一个脚本，-y表明，选择使用什么配置文件启动php

 

执行该脚本以后，执行ps aux |grep php会发现有80个进程严阵以待，等待着请求呢

修改nginx的配置文件，添加以下

 

 

 

test.php在 203上，位置为/var/www

 

 

关防火墙

 

服务器集群与负载均衡搭建完毕

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之间的优化

 

 

 

 

 

n

 

 

 

 

 

 

 

 

 

 

 

如上图,在不少个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

在引入memcached后,性能提高不明显,甚至还略有降低

 

memcached使50%的请求变快了,可是一部分,反倒慢了.

缘由在于--PHP->memcached也要创建tcp链接,代价挺高,

但缓存了数据以后,就省去了mysql的查询时间.

 

总结: memcached适合存复杂的sql,尤为是链接查询/模糊查询的sql结果

 

Memcached服务器的优化(集中在内核的ipv4设置上,再也不重复)

 

 

d号服务器

 

 

 

 

 

 

 

4台机器防火墙所有关掉