标签： Redis

前几天因为把数据库给搞崩溃了，气恼之下直接重装了服务器。由于年纪大了，平时搞的东西也多，导致很多时候做完的事，一些数据参数以及作用都要临时再查询并设置，为了方便以后更换服务器不再花费大量时间优化配置，所以LeePoet做了一个记笔，也算是备份。以下是LeePoet一直以来LeePoet BLOG都是用的2H2G的配置。自己是怎么优化服务器的。

作为一名“资深二手垃圾收藏家废物站长”，LeePoet深知2核2G（2H2G）配置的服务器是许多个人站长的首选。它成本低廉，但资源有限，尤其在面对突发流量或不当配置时，数据库崩溃、网站卡顿是家常便饭。2GB内存是主要限制。所有优化都必须围绕“节约内存、防止溢出”展开。盲目追求高并发参数（如MySQL的max_connections）是导致服务器崩溃最常见的原因。

LeePoet在多次重装服务器后，总结出的一套针对 宝塔面板 + LNMP（Linux, Nginx, MySQL, PHP）环境 + Redis​ 的深度优化配置。目标明确：在保证稳定性的前提下，最大化榨取2H2G服务器的每一分性能。

一、服务器的NGINX优化

在保证服务器稳定性的前提下，最大化利用您有限的硬件资源（2核CPU，2GB内存），以支持更高的并发连接和更大的文件上传。

核心配置参数分析与建议

可以直接参照此表在您的管理面板中进行修改。

配置参数	默认值	2H2G服务器推荐值​	说明
worker_processes​	auto	auto或 2​	Nginx工作进程数。auto会自动设置为CPU核数，对于2核服务器，设为2或auto都是最佳选择。
worker_connections​	51200	20480​	【重要调整】​ 每个工作进程的最大连接数。图片中的51200对2G内存来说过高，容易导致内存耗尽。建议保守设置为20480，理论最大并发为 worker_processes * worker_connections = 2 * 20480 = 40960，这已经非常充足。
keepalive_timeout​	60	30 - 60​	长连接超时时间。60秒是合理的，可以减少连接重建开销。如果您的站点并发很高，可以适当调低至30秒以快速释放连接。
client_max_body_size​	50 MB	根据需求调整（如200M）​	【您最可能需要的调整】​ 允许客户端上传的最大文件大小。如果您需要上传大于50MB的文件（如高清图片、视频、软件包），就在这里修改。例如设为200M。注意：修改后必须点击“保存”并重载Nginx配置才能生效。​
gzip​	开启	开启​	开启Gzip压缩可以有效减少文本类资源（HTML，CSS，JS）的传输大小，提升加载速度。
gzip_min_length​	1 KB	1 KB​	小于1KB的文件压缩可能得不偿失，保持默认即可。
gzip_comp_level​	5	3 - 5​	压缩级别（1-9），级别越高压缩率越好但CPU消耗越大。建议在3-5之间取得平衡，5是很好的选择。
server_names_hash_bucket_size​	512	512​	如果您的服务器配置了大量域名，出现哈希桶大小错误时才需要调整这个值。通常默认或512足够。
client_header_buffer_size​	32 KB	32 KB​	用于读取客户端请求头的缓冲区大小。对于绝大多数情况够用，保持默认。
client_body_buffer_size​	512 KB	512 KB​	用于读取客户端请求主体（如POST数据）的缓冲区大小。通常够用，保持默认。如果经常有超大POST请求，可考虑增大。

---

针对2H2G服务器的综合配置策略

1. 核心思路：平衡内存与并发
   • 内存是您的瓶颈：2GB内存需要精打细算。过高的worker_connections会预分配资源，可能导致服务器在真正的高并发下因内存不足而崩溃。因此，我们将worker_connections从51200下调到更安全的20480。
   • CPU足够应对：2个CPU核心可以很好地处理Nginx的两个工作进程。
2. 重点调整步骤：
   • 第一步（关键）：将 client_max_body_size修改为您需要的值（例如 200M）。
   • 第二步（推荐）：将 worker_connections修改为 20480，以提升服务器稳定性。
   • 第三步：检查其他参数，确认与推荐值一致。
   • 最后：滚动到页面底部，点击绿色的 “保存”​ 按钮，并重启Nginx服务或重载配置以使更改生效。

---

二、服务器的MYSQL优化

对于2G内存的服务器来说（如最大连接数500）过于激进，存在耗尽内存导致数据库崩溃的高风险。我们的优化目标是：在有限的内存下，优先保证数据库的稳定性和响应速度，而不是追求不切实际的高并发连接数。

核心优化思路

1. 内存是最大瓶颈：2GB内存中，操作系统和其他服务（如Nginx、PHP）需要占用约300-500MB。留给MySQL的安全内存上限应在 1.2GB ~ 1.5GB​ 左右。
2. 连接数是内存杀手：许多缓冲区（如sort_buffer_size）是“按连接”分配的。即使一个空闲连接，也会占用这些内存。500个连接会瞬间吃光内存。
3. 抓住重点：innodb_buffer_pool_size是MySQL性能的“心脏”，它用于缓存数据和索引，应分配最多内存。

2H2G服务器MySQL配置推荐

配置的详细优化建议，可以直接在管理面板中修改。

配置参数	默认值	2H2G服务器推荐值​	修改说明
最大使用内存​	~1348 MB	约 1200 – 1400 MB​	这是计算结果，无需直接设置。它由下面各个参数值累加而来。我们的目标就是将其控制在安全线内。
max_connections​	500	100​	【最关键调整】​ 大幅降低最大连接数。100个连接对中小型网站已足够。这能有效防止内存过载。实际并发连接数可能只有10-30个。
innodb_buffer_pool_size​	128 MB	768 M​ 或 1024 M​	【性能核心】​ 这是缓存数据和索引的地方，越大查询越快。建议分配总可用内存的50-70%。从128MB提升到768MB或1G，性能将有质的飞跃。
key_buffer_size​	32 MB	16 M​	仅用于MyISAM引擎的索引缓存。如果您的表都是InnoDB引擎（现代MySQL的默认引擎），这个值可以设小，比如16M。
tmp_table_size​	32 MB	16 M​	临时表的最大大小。如果复杂查询多，可以保持32M，否则可以适当降低以节省内存。
innodb_log_buffer_size​	16 MB	8 M– 16 M​	用于缓冲重做日志（Redo Log）数据。16MB对一般业务足够，如果大事务不多，可以设为8MB。
table_open_cache​	128	512– 1024​	表示可以同时打开的表的数量。适当增大（如512）可以减少表开关销，对内存影响不大。
thread_cache_size​	16	16– 32​	缓存线程数量，避免频繁创建销毁线程。16是一个合理的值，可以保持。

【重点】按连接分配的缓冲区优化

这些参数是“内存杀手”，必须谨慎设置。它们乘以可能的并发连接数就是总消耗。

配置参数	默认值	2H2G服务器推荐值​	修改说明
sort_buffer_size​	768 KB	256 KB​	每个连接排序时使用的缓冲区。不要超过256KB。
read_buffer_size​	768 KB	128 KB– 256 KB​	每个连接顺序扫描表时使用的缓冲区。降低到256KB或更低。
read_rnd_buffer_size​	256 KB	128 KB​	每个连接用于随机读的缓冲区。128KB足够。
join_buffer_size​	256 KB	128 KB​	每个连接用于表关联的缓冲区。128KB足够。如果查询优化得当，很少需要大的join buffer。
thread_stack​	256 KB	256 KB​	每个线程的堆栈大小。保持默认即可，不要动。
binlog_cache_size​	32 KB	32 KB​	每个连接用于二进制日志的缓存。保持默认即可。

---

修改后内存估算（理想情况）

估算一下推荐配置下的内存使用峰值：

• 全局缓冲区:
  • innodb_buffer_pool_size: 768 MB
  • key_buffer_size: 16 MB
  • tmp_table_size& 其他: ~50 MB
  • 小计: ~834 MB
• 每连接缓冲区​ (按最大100连接，但实际可能只有20个活跃连接计算):
  • (256K+ 256K+ 128K+ 128K) * 20个连接 ≈ (768KB/连接) * 20 = 15 MB
• 操作系统/其他开销: ~200 MB
• 总计峰值: 834 MB + 15 MB + 200 MB ≈ 1050 MB

这个估算值在您2GB内存的安全范围内，系统运行会非常稳定。

操作步骤

1. 备份：如果数据库中有重要数据，修改配置前最好先备份。
2. 修改：在您的管理面板中，按照上表的“推荐值”逐一修改。
3. 保存并重启：滚动到页面底部，点击绿色的 “保存”​ 按钮，然后点击 “重启数据库”​ 使配置生效。
4. 监控：重启后，通过数据库管理工具或SHOW GLOBAL STATUS LIKE 'Threads_connected';命令监控实际的最大连接数，通常远低于max_connections。

对于2H2G服务器，MySQL配置的精髓就是“保守”。通过大幅降低 max_connections并优化每个连接的缓冲区大小，将节省下来的内存集中分配给 innodb_buffer_pool_size，这样才能在有限资源下获得最佳性能。

---

三、Redis配置与优化

对于2G内存的服务器来说（如maxclients 10000）风险极高，我们的目标是：在有限的内存下，确保Redis稳定运行，防止内存耗尽导致服务崩溃，并保障安全。

核心优化思路

1. 内存是生命线：Redis所有数据存储在内存中。必须设置内存上限，否则Redis会吃光所有内存，导致系统崩溃。
2. 连接数不是重点：与MySQL不同，Redis是单线程模型，处理连接非常高效。但每个连接仍会占用少量内存，无需设置得过高。
3. 安全第一：默认只绑定内网（127.0.0.1）并设置强密码，是防止服务器被入侵的关键。

下表是针对默认值的配置的详细优化建议。

配置参数	默认值	2H2G服务器推荐值​	修改说明
bind​	127.0.0.1	127.0.0.1​	【安全关键】​ 保持默认。这意味着Redis只允许本机（即服务器上的PHP、Web应用）连接。绝对不要改为 0.0.0.0（允许任何IP连接），否则极易被黑客入侵。​
port​	6379	6379​ 或 自定义端口​	保持默认即可。如果为了隐蔽性，可以改为其他端口（如 6479），但这并非主要安全手段。
timeout​	0	300​	客户端空闲超时时间（秒）。0表示不断开。建议设为 300（5分钟），自动断开闲置连接，释放资源。
maxclients​	10000	1000​	【重要调整】​ 最大客户端连接数。10000对2G服务器过高，可能占用几百MB内存。设置为 1000对于绝大多数应用绰绰有余，能有效控制内存使用。
databases​	16	16​	数据库数量。16是合理的默认值，无需修改。
requirepass​	空	【必须设置一个强密码】​	【安全关键】​ 这是保护Redis的第二道防线。请务必设置一个包含大小写字母、数字和特殊字符的复杂密码（例如 MyRedisPass123!）。应用程序连接Redis时也需要使用此密码。
maxmemory​	0	1024 MB​ 或 1536 MB​	【最核心的调整】​ 0表示无限制，这是极其危险的！必须设置为一个上限。建议为系统预留500MB-1GB内存，因此Redis最大内存可设为 1024M（1GB）。如果您的应用主要是Redis，可以设为 1536M（1.5GB）。

【关键】maxmemory-policy配置（至关重要！）

当内存使用达到 maxmemory限制时，Redis的行为由 maxmemory-policy决定。您需要在配置文件中找到并设置它。对于通用场景，推荐：

• allkeys-lru：（推荐）​ 从所有键中淘汰最近最少使用的键。这是最常用的策略，能保证热点数据常驻内存。
• volatile-lru：仅从设置了过期时间的键中淘汰最近最少使用的键。

需要在配置文件（通常位于 /etc/redis/redis.conf）中手动添加或修改这一行：

maxmemory-policy allkeys-lru

针对2H2G服务器的完整配置方案

1. 第一步（安全与稳定核心）：
   • 将 maxmemory​ 设置为 1024M。
   • 在 requirepass​ 中设置一个强密码。
2. 第二步（资源优化）：
   • 将 maxclients​ 从 10000修改为 1000。
   • 将 timeout​ 从 0修改为 300。
3. 第三步（高级策略，需手动修改配置文件）：
   • 使用SSH登录服务器，用文本编辑器（如 nano或 vim）打开Redis配置文件（路径可能为 /etc/redis/redis.conf）。
   • 找到并修改（或添加）一行：maxmemory-policy allkeys-lru。
   • 保存文件并退出编辑器。
4. 最后：
   • 在宝塔面板的Redis设置页面，点击绿色的 “保存”​ 按钮。
   • 重要：根据页面提示，重启Redis服务​ 以使所有配置生效。

注意事项

• 重启影响：重启Redis会清空所有当前存储在内存中的数据（如果未开启持久化）。请在业务低峰期操作。
• 持久化：如果您需要数据持久化，请确保配置了RDB快照或AOF日志。宝塔面板通常默认已配置，但建议您检查“性能调整”或配置文件中的 save和 appendonly相关设置。
• 监控：配置完成后，通过宝塔面板的“监控”功能或Redis自带的 INFO命令，观察内存使用情况是否稳定。

对于2H2G服务器，Redis配置的核心就三点：

1）用 maxmemory设限保命；

2）用 bind和 requirepass筑牢安全防线；

3）用 maxclients等参数优化资源。​

按照以上方案配置，您的Redis服务将能在一个安全、稳定的环境下运行。

后续

因为在设置完redis密码后，WP会报错，是因为我们WP也装了redis插件如：

所以在修改完redis后再打开站点会出现一个报错

解决方法

我们直接找到站点的wp-config.php文件，编辑WordPress根目录下的 wp-config.php文件再添加一段redis配置：

// 在wp-config.php中添加或修改以下配置
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'your_redis_password_here'); // 这里是redis的密码
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

---

四、配置PHP

在内存紧张的情况下，优先保证服务器稳定性，按需分配资源。

【最佳推荐方案：切换到“按需模式”(ondemand)】

这是最节省内存的方案，非常适合访问量不大或波动明显的站点。

配置参数	默认值（动态）	2H2G推荐值（按需）​	说明
运行模式 (pm)​	dynamic（动态）	ondemand（按需）​	【关键修改】​ 此模式下，PHP进程在无请求时会自动结束，仅在需要时创建，能极大节省内存。
max_children​	20	15​	即使切换到按需模式，也需要设置一个上限防止爆内存。15是2G内存下相对安全的数值。
start_servers​	5	（此模式无效）	按需模式无需设置起始进程数。
min_spare_servers​	5	（此模式无效）	按需模式不保持空闲进程。
max_spare_servers​	10	（此模式无效）	按需模式不保持空闲进程。
pm.process_idle_timeout​	–	60s（或默认值）	进程空闲多少秒后关闭。保持默认或设为60秒即可。

此方案优点：在网站无人访问时，PHP进程数为0，内存占用极低。当有访问时，系统会快速创建进程处理请求，处理完毕后一段时间会自动回收。

1. 强烈建议您采用【最佳推荐方案】。
2. 在这个“性能调整”界面，将 “运行模式”​ 从 “动态”​ 改为 “按需”。
3. 将下方的 “max_children”​ 从20修改为 15。
4. 点击绿色的 “保存”​ 按钮。
5. 最重要的一步：需要到宝塔的“软件商店”或“服务”页面，找到PHP-8.2，点击“重启”。不重启配置不会生效！

2H2G服务器，PHP-FPM进程管理是内存优化的重中之重。将模式从“动态”改为“按需”，并设置一个合理的max_children（如15），可以确保服务器在承受访问压力时不会因PHP进程过多而内存耗尽崩溃。这是提升服务器稳定性的最有效手段。

以下是PHP的 FPM主配置文件已经是最优配置

配置分析与评价

配置行	默认值	分析与评价
pm​	ondemand	【核心优化，非常正确！】​ 这是最省内存的模式。进程只有在有请求时才会创建，请求处理完后会自动结束。完美契合2G内存服务器。
pm.max_children​	15	【设置合理】​ 这是PHP进程数的上限。15对于您的服务器内存来说是安全且可承受的，防止进程过多导致内存耗尽。
pm.start_servers​	5	（此模式下无效）​ 在ondemand模式下，系统启动时不会预先创建5个进程，所以这个值没有影响，可以忽略。
pm.min_spare_servers​	5	（此模式下无效）​ 在ondemand模式下，系统不保持任何空闲进程，所以这个值没有影响，可以忽略。
pm.max_spare_servers​	10	（此模式下无效）​ 同上，在ondemand模式下无效。
listen.backlog​	8192	监听队列长度，默认值，足够大，没问题。
request_terminate_timeout​	100	【设置合理】​ 单个请求最大执行时间100秒，比php.ini里的max_execution_time更长，确保FPM能强制结束超时进程，避免进程阻塞。
listen.mode​	0600	Socket文件权限，仅允许所有者读写，安全。

将PHP-FPM设置成了对小型服务器最友好的 “按需模式 (ondemand)”，并设置了安全的进程上限 15。这能确保：

1. 低内存占用：在网站访问低谷期，PHP进程数为0，几乎不占用额外内存。
2. 高稳定性：进程数有硬性上限，不会因为突发流量而拖垮整个服务器。
3. 按需响应：当有访问请求时，系统会立刻创建新的进程来处理，响应速度不受影响。

确认修改后，点击界面下方的绿色 “保存”​ 按钮，然后到宝塔的“服务”页面，重启PHP-8.2服务，使新的配置生效。

安装PHP的OPcache 扩展

安装并启用OPcache是提升PHP性能性价比最高的操作，没有之一。

检查并优化OPcache配置

仅仅安装还不够，我们需要确保它的配置对于您的2G内存服务器是优化的。请您按照以下步骤操作：

1. 点击左侧菜单的【配置修改】，打开PHP的主配置文件（php.ini）。
2. 在文件中找到 [opcache]部分。如果找不到，可以直接在文件末尾添加。
3. 请对照下表，检查或修改您的OPcache配置，使其达到最佳状态：

配置项	推荐值（用于2H2G服务器）	说明
opcache.enable​	1	确保OPcache是开启状态。
opcache.memory_consumption​	128	【核心参数】​ 为OPcache分配的内存量（MB）。默认值可能很小（如64）。建议设置为128，这能为大量PHP脚本提供缓存空间，显著提升性能，同时不会对您2G的总内存造成压力。
opcache.interned_strings_buffer​	8	存储 interned strings 的内存大小（MB）。PHP会重复使用相同的字符串，这个配置能节省内存。从默认值提升到 8效果很好。
opcache.max_accelerated_files​	10000	OPcache哈希表中可存储的脚本文件数量上限。建议设为10000，以确保所有项目文件都能被缓存。
opcache.revalidate_freq​	60	检查脚本是否更新的时间间隔（秒）。设为 60意味着OPcache会每60秒检查一次源文件是否有变化。在生产环境，为了最高性能，甚至可以设为 0，但这样需要手动重启PHP来更新更改。
opcache.save_comments​	1	保留代码注释。某些框架（如Laravel）依赖注释，请保持为1。
opcache.enable_cli​	0	是否为命令行接口（CLI）启用OPcache。通常不需要，设为 0以避免潜在问题。

优化的配置示例（复制粘贴到 php.ini中）：

opcache.enable = 1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=0

配置中的 opcache.jit_buffer_size和 opcache.jit是PHP 8.0+的即时编译功能，属于高级优化。如果OPcache工作正常，可以保留它们。但如果重启PHP后网站出现任何问题，可以暂时将这两行开头加上分号;注释掉，先确保基础OPcache能正常运行。

修改完成后，点击保存。最重要的一步：回到【服务】页面，重启PHP（点击对应的重启按钮）。不重启，配置更改不会生效。

---

设置计划任务，每日凌晨重启服务

“宝塔任务管理器”主要用于实时监控和管理进程，而设置定时任务需要用到宝塔面板自带的“计划任务”功能。操作步骤如下：

1. 在宝塔面板左侧导航栏中，找到并点击 “计划任务”。
2. 点击页面右上角的 “添加计划任务”​ 按钮。
3. 在弹出的窗口中，按以下说明进行配置：
   • 任务类型：选择 “Shell脚本”。
   • 任务名称：填写一个便于识别的名称，例如 “每日凌晨重启PHP和MySQL”。
   • 执行周期：选择 “每天”，并在时间设置中选择一个凌晨的、访问量最少的时间点，例如 凌晨 3:00。
   • 脚本内容：这是最关键的部分，请将以下命令复制粘贴进去：

# 重启PHP-FPM服务（请根据您的PHP版本修改，例如php-fpm-82）
/etc/init.d/php-fpm restart
# 重启MySQL服务
/etc/init.d/mysqld restart

1. 在任务列表中，找到您刚刚创建的任务，点击右侧的 “执行”​ 按钮。
2. 注意：请根据您服务器上安装的PHP版本，将 php-fpm替换为正确的服务名。通常格式为 php-fpm-版本号，例如 php-fpm-82（对应PHP 8.2）。您可以在宝塔的“软件商店”中查看已安装的PHP版本，或者在“服务”页面查看PHP服务的全名。
3. 确认信息无误后，点击 “添加任务”。

成功设置了在每天凌晨自动重启PHP和MySQL服务的计划任务。这有助于释放被长时间占用的内存，清理可能存在的内存泄漏，从而保持服务器的稳定性和性能。对于您这台2H2G的服务器来说，这是一个非常有效的维护手段。

---

额外说明：为什么没有装Memcached？

1.服务器内存只有2GB，非常宝贵。同时运行Redis和Memcached两个内存型服务，意味着需要为两者分别分配内存（比如Redis 1GB，Memcached 128MB）。这会造成内存资源的浪费和碎片化。将分配给Memcached的这部分内存也划给Redis，让Redis拥有更大的缓存空间，性能会更好。

“把好钢用在刀刃上”：集中所有内存资源给一个更强大的缓存服务（Redis），比分散给两个服务更高效。

2.Redis的功能是Memcached的超集

•Redis支持数据持久化，可以定期将内存数据写入磁盘，防止服务器重启后所有缓存丢失。而Memcached不支持持久化，重启后缓存就全没了。

•Memcached只能做简单的键值对缓存，如图中的配置，它就是一个纯内存缓存。

•Redis不仅可以做键值对缓存，还支持更丰富的数据结构（如列表、集合、哈希表、有序集合），这使得它能处理更复杂的场景（如排行榜、消息队列、会话存储等）。

2H2G服务器，保留Redis，停用Memcached是一个更优、更专业的选择。​ 这能让有限的硬件资源发挥出最大的效能，同时获得更强大的功能。

---

优化进阶：解决同一服务器上两个WordPress网站共用Redis导致数据混乱的问题