mysql php宝塔 root_宝塔优化之php mysqlnginx 负载

admin管理员组

文章数量:1565370

打开Linux工具箱添加Swap

Swap推荐值：

物理内存         Swap

512M              1024M

1GB                1500M

2GB                2048M

4GB                4096M

6GB+             4096M

php

1.安装php扩展

ionCube—-ionCube—–opcache——redis——imagemagick——Swoole(加速作用,减少手字节查询)——mongodb——-yac(php加速，数据库缓存，图形处理)

手字节减少，修改host，减少dns查询数据库这块

127.0.0.1 localhost

2.同样在 php 管理的配置修改中，memory_limit 脚本内存限制修改成256M，

最大脚本运行时间，40-200之间

客户端 长时间没有回应 影响用户体验.

若程序陷入死循环, 服务器端 会一直在运行这个脚本, 如果多人请求这个脚本 服务器就会崩溃掉

Session配置：设置redis

3.设置PHP脚本的运行最大时长。 一般设置60左右

若上传限制中值过大，需适当延长超时时间。

若你的网站在没有高并发的状况下频繁出现502超时现象，也可以尝试适当增加超时时间限制。

建议最大设置时间不要超过86400秒，也就是一天的时间

性能调整。这里大家可以根据自己服务器配置进行设置，宝塔面板比较人性化，会根据你的服务器配置设置推荐方案。其实设置并发多少，大家可以根据自己服务器内存大小进行计算，一般一个php-fpm进程占用内存30M左右，以2048MB内存(2G内存)来计算，大概可以设置68个并发。陌涛使用的就是4核2G内存配置的服务器，但觉得用不到那么高的并发，所以设置了2G的并发方案，

安装宝塔面板后推荐的事40并发，并把max_spare_servers数字调整成了25

理解并发的含义：

高并发，同时请求数据

高并发是请求，指的是多个客户端同一时刻向服务端发送请求， 它是一种现象。

比如，电商网站在双11凌晨12:00分 同时有2000个下单请求。

PHP并发调整建议：

CPU/内存          单站点               多站点

1H/512M          20-30                10-20

1H/1G              30-50                 20-30

2H/2G              50-80                 30-50

2H/4G              60-100               30-50

4H/4G              100-150             30-80

4H/8G              100-200             30-80

6H/6G              100-200             30-80

8H/8G              100-300             50-100

8H/16G            100-300             100-150

16H/16G          100-300             100-150

我们需要注意的是调整并发后服务器宽带使用明显会上升，那是因为服务器同时运行的进程多了，如果宽带不够的话网站会明显变慢，所以大家可以根据自己的实际情况来调整。

注1：容易受到CC攻击的站点使用的PHP版本，尽量不要设置过高的并发，以免服务器被打死

注2：VPS性能参差不齐，以上建议仅供参考，请根据实际使用效果自行调整

注3：不建议设置超过300并发上限，哪怕您的服务器性能足够好；若发现并发不够用，请尝试优化站点数据库缓存可能更有效

mysql

通常MySQL调优我们分以下几部分：

1、MySQL配置参数调优 (需要根据网站运行情况调整)

2、数据表索引调优 (效果明显，但通常优秀的开源程序都不需要调整)

3、SQL语句调优 (这是程序员或DBA干的事)

今天我们主要谈谈如果配合宝塔面板的新功能来进行MySQL配置参数调优，我们先来看两张图片：

很明显，(图1)显示的是MySQL当前的运行状态，(图2)显示的是MySQL主要配置参数

下面我们就来解读一下这两张图：

1、活动/峰值连接数

(图1)中当前活动的连接为1个，自MySQL服务启动以来，最高连接数为54；当最高连接数接近或等于(图2)中的max_connections时，应适当增加max_connections，需要注意的是，不要一下子增加过多，建议每次增加50，观察一段时间，不够再继续增加。

2、线程缓存命中率

(图1)中线程缓存命中率为99.78%，若这个值小于90%，建议适当增加(图2)中的thread_cache_size，建议每次增加8。

3、索引命中率

(图1)中索引命中率为99.50%，若这个值小于95%，建议适当增加(图2)中的key_buffer_size，建议每次增加64，需要说明的是，若您的数据库使用的是Innodb引擎，可忽略这个选项

4、Innodb索引命中率

(图1)中Innodb索引命中率为100%，若这个值小于95%，建议适当增加(图2)中的innodb_buffer_pool_size，建议每次增加64，需要说明的是，若您的数据库没有使用Innodb引擎，可忽略这个选项

5、查询缓存命中率

MySQL查询缓存是个比较受争议的功能，个人建议当你有在使用redis、memcached等缓存软件时，在(图2)中将query_cache_size设为0可以将其关闭，当你没有使用缓存软件，有多余的内存使用，且数据库瓶颈明显存在时，可以尝试开启查询缓存，这是个非常依赖数据表结构及SQL语句优化的功能，若数据表结构和SQL语句都针对查询缓存进行过优化，它的效果还是很不错的。

6、创建临时表到磁盘

(图1)中创建临时表到磁盘的比例是0.42%，这说明大部分临时表创建到内存了，不会过多增加磁盘IO的开销，建议，当比例大于2%时适当增加(图1)中的tmp_cache_size，建议每次增加32，当比例大于60%时，放弃吧，有些开源程序并没有专门优化过SQL语句，所以在运行过程中会开启大量临时表，加多少缓存都是不够用的。

7、已打开的表

当(图1)中的已打开的表接近或等于(图2)中的table_open_cache时，可以适当增加table_open_cache，但若设置过大可能导致您的程序频繁中断MySQL连接，建议在1024以内，最大不要超过2048。

8、没有使用索引的量、没有使用索引的JOIN量

若不为0，就检查下数据表索引吧，其实只要没有疯涨，比如一天增涨几千，一般可以忽略，必竟优化索引还是程序员或DBA去干比较合适。

9、排序后的合并次数

如果这个值在缓慢增张，建议适当增加(图2)中的sort_buffer_size，建议每次增加512，但最大不要超过8192，如果这个值一直在疯涨，增加sort_buffer_size也没用，就放弃这个选项吧，这个锅还是给程序开发者背。

10、锁表次数

如果服务器CPU开销不大的情况下，疯狂锁表，建议你将所有数据表转换成innodb，记得转换前备份哦。

nginx

自编译和添加云锁自编译防护

nginx安装nginx  tengine，比原始的性能强很多倍

参考：

1.云锁的安装 http://help.yunsuo/guide/install/Linux.html

2.云锁的自编译http://www.aiii.vip/25.html

是否有添加什么自动执行的任务

mysql是否有锁表，如下太大了，优化下数据库

系统负荷的经验法则

1.0是系统负荷的理想值吗？

不一定，系统管理员往往会留一点余地，当这个值达到0.7，就应当引起注意了。经验法则是这样的：

当系统负荷持续大于0.7，你必须开始调查了，问题出在哪里，防止情况恶化。

当系统负荷持续大于1.0，你必须动手寻找解决办法，把这个值降下来。

当系统负荷达到5.0，就表明你的系统有很严重的问题，长时间没有响应，或者接近死机了。你不应该让系统达到这个值。

最后一个问题，”load average” 一共返回三个平均值—-1分钟系统负荷、5分钟系统负荷，15分钟系统负荷，—-应该参考哪个值？

如果只有1分钟的系统负荷大于1.0，其他两个时间段都小于1.0，这表明只是暂时现象，问题不大。

如果15分钟内，平均系统负荷大于1.0(调整 CPU 核心数之后)，表明问题持续存在，不是暂时现象。

所以，你应该主要观察”15分钟系统负荷”，将它作为电脑正常运行的指标。

对于我的机器，有24个core，那么，load多少合适呢？

[root@lpf]# grep -c 'model name' /proc/cpuinfo

24

答案是：

[root@lpf]# echo "0.7*24" | bc

16.8

宝塔修复面板看看，负载和cpu 修复后还是爆满么

查看服务器进程cpu 内存统计

参考：https://blog.csdn/qq_35190492/article/details/105278061

先进服务器，用top -c 命令找出当前进程的运行列表

按一下 P 可以按照CPU使用率进行排序

然后我们需要根据PID 查出CPU里面消耗最高的进程

使用命令 top -Hp 2609 找出这个进程下面的线程，继续按P排序

2854是十进制的，我们需要转换为十六进制，转换结果：b26

接下来就需要导出我们的进程快照了，看看这个线程做了啥

jstack -l 2609 > ./2609.stack

再用grep查看一下线程在文件里做了啥

cat 2609.stack |grep 'b26' -C 8

木马查杀结束并删除

https://blog.csdn/csp_6666/article/details/106126753

https://blog.csdn/u010772882/article/details/104895270

https://blog.csdn/weixin_33736048/article/details/92631090

https://blog.csdn/u010938610/article/details/79696174

https://blog.csdn/qq_20545159/article/details/77775122

https://blog.csdn/xinxin_2011/article/details/84936581

https://blog.csdn/mikewuhao/article/details/90735700

本文标签： 宝塔负载PHPmysqlNginx