从事php开发的都知道,LNMP一般是指linux+Nginx+MySQL+PHP组合,也是日常开发和线上环境中最简单的Web服务器架构。为尽可能的提升服务器响应速度,LNMP的配置优化是十分关键的步骤。下面分别总结一下LNMP各组件的配置优化方法。
关于Linux优化,我们这次主要从内核配置方面去讲(硬件优化增加投入即可)。内核配置优化主要围绕如何提供更好更稳定的TCP/IP服务为主,可以查看这篇文章:从TCP/IP协议谈Linux内核参数优化, 这里不在单独写了。
Nginx运行工作进程个数,建议按照cpu 数目来指定,一般为它的倍数 (如,2个四核的cpu计为8)。
worker_processes 8;
worker_cpu_affinity 为每个进程分配cpu,一般情况下一个进程分配一个cpu,例如8cpu:
worker_processes 8; worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
worker_rlimit_nofile 65535;
这个指令是指当一个nginx进程打开的最多文件描述符数目,理论值应该是最多打开文件数(ulimit -n)与nginx进程数相除,但是nginx分配请求并不是那么均匀,所以最好与ulimit -n的值保持一致。
注:文件资源限制的配置可以在/etc/security/limits.conf设置,针对root/user等各个用户或者*代表所有用户来设置。
* soft nofile 65535 * hard nofile 65535
用户重新登录生效。
events { use epoll; }
nginx采用epoll事件模型,处理效率高。
worker_connections 65535;
设置每个进程允许的最多连接数, 理论上每台nginx 服务器的最大连接数为worker_processes*worker_connections,一般设置为65535。
使用gzip压缩功能,可能为节约带宽,加快传输速度。
一般我们需要压缩的内容有:文本,js,html,css,对于图片,视频,flash什么的不压缩,使用gzip的功能是需要消耗CPU的。
gzip on; gzip_min_length 2k; gzip_buffers 4 32k; gzip_http_version 1.1; gzip_comp_level 6; gzip_typestext/plain text/css text/JAVAscriptApplication/json application/JavaScript application/x-javascriptapplication/xml; gzip_vary on; gzip_proxied any; gzip on; #开启压缩功能
参数说明:
keepalived_timeout 65; client_header_timeout 30; client_body_timeout 30; sned_timeout 60; proxy_send_timeout 300; reset_timedout_connection on;
参数说明:
在大部分场景下,利用 Nginx 的 buffer(缓冲) 和 cache(缓存) 能力,可以大大地减轻负担。
client_body_buffer_size 16K client_header_buffer_size 1K
http { include mime.types; default_type application/octet-stream; …… sendfile on; tcp_nopush on; …… }
缓存,主要针对于图片,css,js等元素更改机会比较少的情况下使用,特别是图片,占用带宽大,我们完全可以设置图片在浏览器本地缓存365d,css,js,html可以缓存个10来天,这样用户第一次打开加载慢一点,第二次,就非常快了!缓存的时候,我们需要将需要缓存的拓展名列出来, Expires缓存配置在server字段里面。
location ~* .(ico|jpe?g|gif|png|bmp|swf|flv)$ { expires 30d; } location ~* .(js|css)$ { expires 7d; }
fastcgi_connect_timeout 600; fastcgi_send_timeout 600; fastcgi_read_timeout 600; fastcgi_buffer_size 64k; fastcgi_buffers 4 64k; fastcgi_busy_buffers_size 128k; fastcgi_temp_file_write_size 128k; fastcgi_temp_path/usr/local/nginx1.10/nginx_tmp; fastcgi_intercept_errors on; fastcgi_cache_path/usr/local/nginx1.10/fastcgi_cache levels=1:2 keys_zone=cache_fastcgi:128minactive=1d max_size=10g;
这一点影响较大,因为高流量站点上的日志文件涉及大量必须在所有线程之间同步的IO操作。
access_log off; log_not_found off; error_log /var/log/nginx-error.log warn;
若你不能关闭访问日志文件,至少应该使用缓冲:
access_log /var/log/nginx/access.log main buffer=16k;
server_tokens off;
server_tokens并不会让nginx执行的速度更快,但它可以关闭在错误页面中的nginx版本数字,这样对于安全性是有好处的。
表的数据和索引存放在共享表空间里或者单独表空间里。我们的工作场景安装是默认设置了innodb_file_per_table = ON,这样也有助于工作中进行单独表空间的迁移工作。MySQL 5.6中,这个属性默认值是ON。
默认值为1,表示InnoDB完全支持ACID特性。当你的主要关注点是数据安全的时候这个值是最合适的,比如在一个主节点上。但是对于磁盘(读写)速度较慢的系统,它会带来很巨大的开销,因为每次将改变flush到redo日志都需要额外的fsyncs。
如果将它的值设置为2会导致不太可靠(unreliable)。因为提交的事务仅仅每秒才flush一次到redo日志,但对于一些场景是可以接受的,比如对于主节点的备份节点这个值是可以接受的。如果值为0速度就更快了,但在系统崩溃时可能丢失一些数据:只适用于备份节点。说到这个参数就一定会想到另一个sync_binlog。
这项配置决定了数据和日志写入硬盘的方式。一共有三种方式,我们默认使用O_DIRECT 。O_DIRECT模式:数据文件的写入操作是直接从mysql innodb buffer到磁盘的,并不用通过操作系统的缓冲,而真正的完成也是在flush这步,日志还是要经过OS缓冲。
这项配置决定了为尚未执行的事务分配的缓存。其默认值(1MB)一般来说已经够用了,但是如果你的事务中包含有二进制大对象或者大文本字段的话,这点缓存很快就会被填满并触发额外的I/O操作。看看Innodb_log_waits状态变量,如果它不是0,增加innodb_log_buffer_size。
这个参数应该是运维中必须关注的了。缓冲池是数据和索引缓存的地方,它属于MySQL的核心参数,默认为128MB,正常的情况下这个参数设置为物理内存的60%~70%。(不过我们的实例基本上都是多实例混部的,所以这个值还要根据业务规模来具体分析。)
这是redo日志的大小。redo日志被用于确保写操作快速而可靠并且在崩溃时恢复。如果你知道你的应用程序需要频繁地写入数据并且你使用的是MySQL 5.6,那么你可以一开始就把它这是成4G。(具体大小还要根据自身业务进行适当调整)
innodb_support_xa可以开关InnoDB的XA两段式事务提交。默认情况下,innodb_support_xa=true,支持XA两段式事务提交。由于XA两段式事务提交导致多余flush等操作,性能影响会达到10%,所有为了提高性能,有些DBA会设置innodb_support_xa=false。这样的话,redolog和binlog将无法同步,可能存在事务在主库提交,但是没有记录到binlog的情况。这样也有可能造成事务数据的丢失。
该参数用来存储数据字段信息和其他内部数据结构。表越多,需要在这里分配的内存越多。如果InnoDB用光了这个池内的内存,InnoDB开始从操作系统分配内存,并且往MySQL错误日志写警告信息,默认8MB。一般设置16MB。
MySQL服务器默认连接数比较小,一般也就100来个最好把最大值设大一些。一般设置500~1000即可每一个链接都会占用一定的内存,所以这个参数也不是越大越好。有的人遇到too many connections会去增加这个参数的大小,但其实如果是业务量或者程序逻辑有问题或者sql写的不好,即使增大这个参数也无济于事,再次报错只是时间问题。在应用程序里使用连接池或者在MySQL里使用进程池有助于解决这一问题。
复制架构时确保 server-id 要不同,通常主ID要小于从ID。
如果你想让数据库服务器充当主节点的备份节点,那么开启二进制日志是必须的。如果这么做了之后,还别忘了设置server_id为一个唯一的值。就算只有一个服务器,如果你想做基于时间点的数据恢复,这(开启二进制日志)也是很有用的:从你最近的备份中恢复(全量备份),并应用二进制日志中的修改(增量备份)。
二进制日志一旦创建就将永久保存。所以如果你不想让磁盘空间耗尽,你可以用 PURGE BINARY LOGS 来清除旧文件,或者设置expire_logs_days 来指定过多少天日志将被自动清除。记录二进制日志不是没有开销的,所以如果你在一个非主节点的复制节点上不需要它的话,那么建议关闭这个选项。
当客户端连接数据库服务器时,服务器会进行主机名解析,并且当DNS很慢时,建立连接也会很慢。因此建议在启动服务器时关闭skip_name_resolve选项而不进行DNS查找。唯一的局限是之后GRANT语句中只能使用IP地址了,因此在添加这项设置到一个已有系统中必须格外小心。
sync_binlog 的默认值是0,像操作系统刷其他文件的机制一样,MySQL不会同步到磁盘中去而是依赖操作系统来刷新binary log。
当sync_binlog =N (N>0) ,MySQL 在每写N次二进制日志binary log时,会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去。当innodb_flush_log_at_trx_commit和sync_binlog 都为 1 时是最安全的,在mysqld服务崩溃或者服务器主机crash的情况下,binary log只有可能丢失最多一个语句或者一个事务。但是鱼与熊掌不可兼得,双1会导致频繁的IO操作,因此该模式也是最慢的一种方式。出于我们的业务考虑在业务压力允许的情况下默认的都是双1配置。
当业务中需要使用级联架构的时候log_slave_update = 1这个参数必须打开,否者第三级可能无法接收到第一级产生的binlog,从而无法进行数据同步。
如果内存临时表超出了限制,MySQL就会自动地把它转化为基于磁盘的MyISAM表,存储在指定的tmpdir目录下.因此尽可能将tmpdir配置到性能好速度快的存储设备上。
slow_query_log = 1 #打开慢日志
pm = dynamic #pm参数指定了进程管理方式,有两种可供选择:static或dynamic,从字面意思不难理解,为静态或动态方式。如果是静态方式,那么在php-fpm启动的时候就创建了指定数目的进程,在运行过程中不会再有变化(并不是真的就永远不变);而动态的则在运行过程中动态调整,当然并不是无限制的创建新进程,受pm.max_spare_servers参数影响;动态适合小内存机器,灵活分配进程,省内存。静态适用于大内存机器,动态创建回收进程对服务器资源也是一种消耗 pm.max_children = 24 #static模式下创建的子进程数或dynamic模式下同一时刻允许最大的php-fpm子进程数量 pm.start_servers = 16 #动态方式下的起始php-fpm进程数量 pm.min_spare_servers = 12 #动态方式下服务器空闲时最小php-fpm进程数量 pm.max_spare_servers = 24 #动态方式下服务器空闲时最大php-fpm进程数量
一般php-fpm进程占用20~30m左右的内存就按30m算。如果单独跑php-fpm,动态方式起始值可设置物理内存Mem/30M。
pm.max_requests = 10240
最大处理请求数是指一个php-fpm的worker进程在处理多少个请求后就终止掉,master进程会重新respawn一个新的,这个配置的主要目的是避免php解释器或程序引用的第三方库造成的内存泄露。
max_execution_time = 20 request_terminate_timeout = 20
这个是用来处理因为PHP执行时间超长而报502错误的解决。这个时长配置可以在php.ini(max_execution_time)或php-fpm.conf中配置均可,为了不影响全局配置,可在php-fpm.conf中实现