网站打开速度变慢，nginx日志报104: Connection reset by peer错误

镖师 · 发表于 2023-3-6 17:03:28

马上注册，免费下载更多dz插件网资源。

您需要登录才可以下载或查看，没有账号？立即注册

×

　　近日，发现网站访问速度开始变慢，以前能够秒开的，这几天居然要等上好几秒，而手机并没有收到带宽跑满的预警信息，这就有点奇怪了。于是连接到服务器看网站访问日志，发现有很多的这个错误：recv() failed (104: Connection reset by peer) while reading response header from upstream。

网站打开速度变慢，nginx日志报104: Connection reset by peer错误网站,打开,速度,nginx,日志

　　于是网上搜索看是什么原因造成的。104错误表明你在对一个对端socket已经关闭的的连接调用write或send方法，在这种情况下，调用write或send方法后，对端socket便会向本端socket发送一个RESET信号，在此之后如果继续执行write或send操作，就会得到errno为104，错误描述为connection reset by peer。
　　看描述就是说用户打开页面后，页面没有加载完成就关闭了，服务器这边就有了104的错误记录。解决方案是nginx配置和php-fpm配置调优。根据网上说的方法调了一下，期待能够解决。
　　重启服务器，发现没什么卵用，错误反而越来越多了。页面打开速度也非常慢，但有一个细节引起了我的注意：网站静态页打开速度还是非常快的，动态页就死慢死慢，于是分析得出，最大的问题可能是数据库服务器那边出问题了。
　　登录阿里云数据库RDS版，查看性能选项，CPU占用率60%多点，内存占用20%多点，连接数100多点，好像问题也不是很大，也没有到报警的级别。不过，本着“宁可错杀不可错放”的原则，毫不犹豫重启了数据库服务器。
　　有点奇怪，这个数据库服务器重启时间相当长，都快花了10分钟时间，我一度怀疑是不是数据库服务器重启过程中挂了。还好重启成功又跑起来了。再打开一下网站动态页面，咦，速度又回来了，又能秒开啦！
　　问题排除了，是出在数据库服务器上，但具体是哪里的问题，还是没有彻底搞明白。不过，数据库服务器应该有好几年没有重启了，经过这次问题排查我觉得，数据库服务器还是需要定期重启的，比如1个月重启1次，可以解决很多你不知道的问题。
　　记录以上心得，供遇到同样问题的朋友们参考。

©DZ插件网所发布的一切资源仅限用于学习和研究目的；不得将上述内容用于商业或者非法用途，否则，一切后果请用户自负。
本站内容为站长个人技术研究记录或网络，不提供用户交互功能，所有内容版权归原作者所有。您必须在下载后的24个小时之内，从您的电脑中彻底删除上述内容。如果您喜欢该程序，请支持正版软件，得到更好的正版服务。
您在本站任何的赞助购买、下载、查阅、回复等行为等均表示接受并同意签订《DZ插件网免责声明协议》。
如有侵权请邮件与我们联系处理: discuzaddons@vip.qq.com 并出示相关证明以便删除。敬请谅解！

Discuz智能体 · 发表于 2025-3-16 20:24:31

从你的描述来看，网站访问速度变慢的问题确实与数据库服务器有关。虽然你通过重启数据库服务器暂时解决了问题，但为了彻底排查和优化，以下是一些建议和可能的解决方案：

### 1. **数据库连接问题**
- **连接数过高**：虽然你提到连接数只有100多点，但建议检查是否有过多的空闲连接未释放。可以通过调整数据库的连接池配置来优化。
- **长连接问题**：如果使用了长连接，可能会导致连接数积累过多。建议适当减少长连接的超时时间，或者定期断开空闲连接。

### 2. **数据库查询优化**
- **慢查询日志**：启用数据库的慢查询日志，分析是否有某些SQL语句执行时间过长。可以通过优化索引、重构查询语句等方式来提升查询性能。
- **索引优化**：检查数据库表的索引是否合理，尤其是频繁查询的表。缺少索引或索引不合理会导致查询速度变慢。

### 3. **PHP-FPM配置优化**
- **进程管理**：检查PHP-FPM的进程管理配置，确保有足够的子进程处理请求，同时避免过多的子进程占用资源。可以调整`pm.max_children`、`pm.start_servers`、`pm.min_spare_servers`和`pm.max_spare_servers`等参数。
- **请求超时**：调整PHP-FPM的`request_terminate_timeout`参数，避免某些请求长时间占用资源。

### 4. **Nginx配置优化**
- **缓冲区设置**：调整Nginx的缓冲区大小，避免因缓冲区不足导致连接重置。可以尝试增加`proxy_buffer_size`和`proxy_buffers`的值。
- **超时设置**：调整Nginx的超时设置，确保与后端服务的连接不会因为超时而被重置。可以调整`proxy_connect_timeout`、`proxy_read_timeout`和`proxy_send_timeout`等参数。

### 5. **定期维护**
- **数据库优化**：定期对数据库进行优化操作，如`OPTIMIZE TABLE`、`ANALYZE TABLE`等，以减少碎片和提高查询效率。
- **重启计划**：如你所提到的，定期重启数据库服务器可以解决一些潜在的问题。建议每月或每季度进行一次重启，同时结合数据库的备份和优化操作。

### 6. **监控与报警**
- **性能监控**：建议部署数据库和服务器性能监控工具，实时监控CPU、内存、连接数等关键指标，及时发现潜在问题。
- **报警设置**：设置合理的报警阈值，确保在资源使用率达到一定水平时能够及时收到通知，避免问题积累。

### 7. **其他可能的原因**
- **网络问题**：检查服务器与数据库之间的网络连接是否稳定，是否存在丢包或延迟过高的情况。
- **硬件问题**：如果数据库服务器运行时间过长，硬件可能出现老化或故障。建议定期检查硬件状态，必要时进行更换或升级。

通过以上措施，你可以进一步优化数据库和服务器的性能，减少类似问题的发生。如果问题依然存在，建议深入分析数据库的慢查询日志和服务器日志，找到具体的瓶颈并进行针对性优化。

希望这些建议对你有所帮助！如果有其他问题，欢迎继续咨询。
-- 本回答由人工智能 AI智能体生成，内容仅供参考，请仔细甄别。

Discuz智能体 · 发表于 2025-3-20 23:35:08

你遇到的问题确实是一个典型的数据库服务器性能瓶颈导致的网站访问速度变慢的情况。以下是一些可能的原因和解决方案，供你参考：

### 1. **数据库连接问题**
- **连接数过多**：虽然你提到连接数只有100多点，但可能这些连接中有很多是长时间未释放的。建议检查数据库的连接池配置，确保连接能够及时释放。
- **慢查询**：数据库中的慢查询可能会导致数据库服务器负载过高。你可以通过数据库的慢查询日志来排查是否有某些SQL语句执行时间过长，进而优化这些查询。

### 2. **数据库索引问题**
- **索引失效或缺失**：如果数据库表中的数据量较大，且没有合适的索引，查询速度会显著下降。建议定期检查并优化数据库表的索引。
- **索引碎片**：长时间运行的数据库可能会出现索引碎片问题，定期重建索引可以提高查询性能。

### 3. **数据库缓存问题**
- **缓存失效**：数据库的查询缓存可能因为某些原因失效，导致每次查询都需要重新执行。建议检查并优化数据库的缓存配置。
- **缓存命中率低**：如果缓存命中率较低，可能会导致数据库频繁进行磁盘I/O操作，进而影响性能。可以通过调整缓存大小或优化查询来提高缓存命中率。

### 4. **数据库服务器资源问题**
- **CPU和内存使用率**：虽然你提到CPU和内存使用率并不高，但可能在某些时间段内会出现峰值。建议监控数据库服务器的资源使用情况，确保在高负载时资源充足。
- **磁盘I/O**：数据库服务器的磁盘I/O性能也可能成为瓶颈。建议检查磁盘的读写速度，必要时可以考虑升级磁盘或使用SSD。

### 5. **定期维护**
- **定期重启**：正如你所提到的，定期重启数据库服务器可以解决一些潜在的问题。建议每月或每季度进行一次重启，以确保数据库服务器的稳定性。
- **数据库优化**：定期进行数据库优化操作，如清理无用数据、重建索引、优化表结构等，可以保持数据库的高效运行。

### 6. **Nginx和PHP-FPM配置优化**
- **Nginx配置**：确保Nginx的`worker_connections`和`worker_processes`配置合理，避免因连接数过多导致性能下降。
- **PHP-FPM配置**：调整PHP-FPM的`pm.max_children`、`pm.start_servers`等参数，确保PHP-FPM能够处理足够的并发请求。

### 7. **监控和报警**
- **实时监控**：建议部署实时监控系统，如Prometheus、Grafana等，实时监控数据库服务器的性能指标，及时发现并解决问题。
- **报警机制**：设置合理的报警阈值，当数据库服务器的CPU、内存、连接数等指标超过阈值时，及时通知管理员进行处理。

通过以上措施，你应该能够更好地管理和优化数据库服务器，避免类似问题再次发生。如果问题依然存在，建议进一步深入分析数据库日志和服务器日志，找出根本原因。
-- 本回答由人工智能 AI智能体生成，内容仅供参考，请仔细甄别。