SunZhongWei | 孙仲维的 RSS 预览

Magento 服务器负载居高不下问题排除系列之二，屏蔽恶意爬虫

2026-06-28 13:21:31

之前整理了一期 Magento 服务器负载居高不下问题排除，没想到观察了几天发现服务器负载依然居高不下。

最终靠着 cloudflare 中设置访问规则，屏蔽了大量恶意爬虫，服务器负载终于恢复正常。

这里记录一下排除过程。特别是其中的 MySQL / MariaDB 相关的排查过程很有参考价值。

高负载依旧

在重建了 Magento 索引之后，没想到 MySQL 的 CPU 占用依旧很高，导致服务器负载居高不下。

排除交换分区的影响

我本以为是系统交换分区（swap）导致的高负载问题，查看了系统的 swap 使用情况，发现 swap 使用率很低，几乎没有使用到 swap 分区。

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       1.0Gi       6.5Gi       5.7Mi       363Mi       6.7Gi
Swap:          2.0Gi          0B       2.0Gi

以上是我本机的内存使用情况，并非服务器的，仅仅是为了说明 swap 使用率很低，几乎没有使用到 swap 分区。
这里的 available 内存是指系统可用的内存，free 内存是指系统空闲的内存，buff/cache 是指系统缓存的内存。总的来说，系统内存使用情况良好，没有出现内存不足的情况。

如果想看具体每个进程的 SWAP 分区使用情况，可以使用 smem 工具，安装方法如下：

sudo apt install smem

查看每个进程的 SWAP 分区使用情况：

$ sudo smem -t -k -s uss -r | head -25
  PID User     Command                         Swap      USS      PSS      RSS
  280 mysql    /usr/sbin/mysqld                   0   401.6M   403.6M   410.8M
  308 root     /usr/bin/dockerd -H fd:// -        0    78.8M    78.9M    81.9M
  211 root     /usr/bin/containerd                0    48.1M    48.1M    49.5M
  179 root     /usr/libexec/wsl-pro-servic        0    16.0M    16.0M    17.5M
  166 redis    /usr/bin/redis-server 127.0        0    13.0M    14.1M    20.3M
  164 root     php-fpm: master process (/e        0    11.2M    17.5M    34.2M

上面命令是查看 USS 占用排名前 25 的进程，USS 是指进程独占的内存大小，PSS 是指进程共享的内存大小，RSS 是指进程实际使用的物理内存大小。

show processlist 看不出问题

在 MySQL 中使用 show processlist 命令查看当前正在执行的 SQL 语句，发现没有明显的异常。
已经看不到满查询的情况了。之前没有建 magento 索引的时候，show processlist 中还会偶有慢查询，
但是现在已经没有了。大部分的 SQL 语句都是正常的查询语句，没有出现任何慢查询。

那为何从 top 命令看 MySQL 占用这么高的 CPU 呢？注意面试的时候，一定要说用了 top，否则一些脑残面试官，以为你啥也不知道。。。

查看 MySQL 每秒的 SQL 执行量

于是我怀疑是 MySQL 每秒的 SQL 执行量过高，导致 CPU 占用过高。

]> SHOW GLOBAL STATUS LIKE 'Questions';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Questions     | 705205 |
+---------------+--------+
1 row in set (0.00 sec)

MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'Questions';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| Questions     | 715310 |
+---------------+--------+
1 row in set (0.00 sec)

大概间隔了 5 秒钟左右，发现 Questions 的值增加了 10000 左右，说明 MySQL 每秒的 SQL 执行量大约是 2000 左右。
但是，这种纯手工计时的方式太不精确，于是改用 watch 命令来查看 MySQL 每秒的 SQL 执行量。

watch -n 10 'mysqladmin -uroot -ppassword status | grep Questions'

watch 命令每隔 10 秒钟执行一次 mysqladmin 命令，查看 MySQL 的状态信息，并过滤出 Questions 这一行。
同时计算出每秒的 SQL 执行量，发现 MySQL 每秒的 SQL 执行量大约是 1500 左右。🥲

这也太离谱了，MySQL 每秒的 SQL 执行量居然这么高，难怪 CPU 占用会这么高。

Nginx 日志定位到问题

因为之前看过 cloudflare 及 Nginx 的访问日志，从日志看，请求量也就在每秒 20 次左右。
这个访问量很小，我一直没有当回事。确实是我大意了。

再次仔细看了一下 Nginx 日志，发现这每秒 20 次的请求，实际应该是同一来源。因为 User Agent 类似。

而且都是访问的 Magento 的产品列表页的属性过滤功能，但是属性参数每次都不一样。

这个网站 170 万多个产品，100 多属性，属性组合非常多，导致恶意爬虫在抓取产品列表页的时候，访问了大量的不同属性组合的 URL。
我怀疑是这个属性列表页的属性组合导致了 MySQL 每秒的 SQL 执行量过高，最终导致 MySQL CPU 占用过高。

而这个我又没法做本地缓存，因为磁盘空间不太够。

通过 cloudflare 屏蔽恶意爬虫

所以，先临时启用了 cloudflare 的访问规则，除了认证的正规爬虫（如 Googlebot、Bingbot 等）之外，其他的所有请求都开启人类验证（Challenge）模式。

但是，需要排除首页，毕竟需要防止宕机监控请求也被挑战。

尝试了一下只部分属性列表路径才开启挑战，但是发现相关的页面规则太多，最终还是选择了对所有路径开启挑战模式。

暂时看是正常了。系统负载也恢复正常了。

待续

为何属性组合会导致 MySQL 每秒的 SQL 执行量过高？
为何屏蔽了恶意爬虫之后，MySQL 的 CPU 占用没有立即下降？而且在重启 MySQL 之后，CPU 占用才正常？是因为数据库的 SQL 队列机制，还是 PHP 的请求队列机制？还是其他原因？

RuoYi Vue 版本如何启动后台服务和前端

2026-06-28 12:10:47

vue2 版本文档地址

https://doc.ruoyi.vip/ruoyi-vue/

vue demo

http://vue.ruoyi.vip/system/config

下载代码脚手架

参考 https://doc.ruoyi.vip/ruoyi-vue/document/hjbs.html#%E5%87%86%E5%A4%87%E5%B7%A5%E4%BD%9C

到 https://gitee.com/y_project/RuoYi-Vue 下载压缩包，即 release 页面的 zip 压缩包。到本地解压即可。

IDEA 中启动

搜索文件 RuoYiApplication.java，点击启动即可。其路径是：

ruoyi-admin\src\main\java\com\ruoyi\RuoYiApplication.java

数据库配置

新建数据库
将 SQL 目录中的两个 sql 导入初始数据
搜索 application-druid.yml，会找到 ruoyi-admin/src/main/resources/application-druid.yml, 在里面修改 master 数据库的配置。注意修改连接字符串中的数据库名称

修改完成后，重启 idea 中的服务即可。

前端启动

进入前端目录 ruoyi-ui，先安装依赖

npm install --registry=https://registry.npmmirror.com

然后执行：

npm run dev

即可。执行完成后，会自动打开浏览器显示前端登录界面。
如果后台服务运行正常，就能登陆成功了。

如何在 IDEA 中配置 npm run dev？

Spring Boot 找不到 oracle 及 sqlserver 指定版本的依赖库

2026-06-24 19:09:29

在编译 RuoYi (Sprint Boot 版本) RuoYiApplication.java 时，报错找不到 oracle 及 sqlserver 的依赖库。

或者在 IDEA 右侧的 Maven 中点击 Reload All Maven Projects 也会报错。

报错信息

Could not find artifact com.oracle:ojdbc8:pom:12.2.0.1 in central (https://repo.maven.apache.org/maven2)

及

Could not find artifact com.microsoft.sqlserver:sqljdbc4:pom:4.0.0 in central (https://repo.maven.apache.org/maven2)

Oracle ojdbc8 12.2.0.1 问题

Oracle ojdbc8 12.2.0.1的禁止是由于它的许可证限制造成的。根据Oracle的许可条款，Oracle数据库的JDBC驱动程序不允许被存储在公共的Maven仓库中。

可以手动下载驱动程序 jar 文件安装到您的本地 Maven 仓库中。

下载地址：

https://repo1.maven.org/maven2/com/oracle/database/jdbc/ojdbc8/12.2.0.1/

将 ojdbc8-12.2.0.1.jar 文件下载到本地，然后通过命令行进入下载目录，执行以下命令将其安装到本地 Maven 仓库中：

mvn install:install-file -Dfile=ojdbc8-12.2.0.1.jar -DgroupId=com.oracle -DartifactId=ojdbc8 -Dversion=12.2.0.1 -Dpackaging=jar

主要下载后，需要点击浏览器的保留按钮，否则 jar 包默认不会以原文件名的方式保存到本地。

Microsoft SQL Server JDBC Driver 问题

微软不允许以maven的方式下载该文件。

下载地址：

https://mvnrepository.com/artifact/com.microsoft.sqlserver/sqljdbc4/4.0

找到 FILES 部分的 jar，下载到本地。到下载目录执行命令：

mvn install:install-file -Dfile=sqljdbc4-4.0.0.jar -DgroupId=com.microsoft.sqlserver -DartifactId=sqljdbc4 -Dversion=4.0.0 -Dpackaging=jar

Magento 服务器负载居高不下问题排除

2026-06-23 21:48:40

上上周遇到的一个 Magento 服务器问题。

问题现象

服务器负载居高不下，MySQL 数据库 CPU 占用很高，从 show processlist 的结果看，看不出什么问题。但是通过统计执行的 SQL 总量看，每秒钟几千个 SQL 查询。而且偶尔有执行长时间的大型联表查询语句。而产品表有近两百万的数据量。

经过一顿毫无头绪的排除。大概定位到是 magento 索引失效的问题，需要重建索引。

但是，重建命令，看不到进度，第一次执行，不知道为什么失败了。于是尝试，逐个手动重建索引。

重建索引前停掉 php fpm

sudo lnmp php-fpm stop

主要是为了防止请求进来，继续造成系统高负载。

重建后再启动

sudo lnmp php-fpm start

执行命令

以产品跟属性的索引为例：

php bin/magento indexer:reindex catalog_product_attribute -vvv

也可以一次性执行多个：

$ php bin/magento indexer:reindex catalogrule_product catalogrule_rule catalog_category_product customer_grid design_config_grid inventory catalog_product_category cataloginventory_stock -vvv

执行结果

Design Config Grid index has been rebuilt successfully in 00:00:00
Customer Grid index has been rebuilt successfully in 00:00:00
Category Products index has been rebuilt successfully in 00:21:15
Product Categories index has been rebuilt successfully in 00:00:00
Catalog Rule Product index has been rebuilt successfully in 00:00:00
Stock index has been rebuilt successfully in 00:01:59
Inventory index has been rebuilt successfully in 00:00:00
Catalog Product Rule index has been rebuilt successfully in 00:00:00
Product Price index has been rebuilt successfully in 00:21:29
Catalog Search index has been rebuilt successfully in 01:14:03

那个 catalog_product_attribute Product EAV 执行时间最长，执行了三四天。所以最好在 screen 中执行。

查看索引状态

$ php bin/magento indexer:status
+---------------------------+----------------------+--------+-----------+---------------------+---------------------+
| ID                        | Title                | Status | Update On | Schedule Status     | Schedule Updated    |
+---------------------------+----------------------+--------+-----------+---------------------+---------------------+
| catalogrule_product       | Catalog Product Rule | Ready  | Schedule  | idle (0 in backlog) | 2026-06-14 09:28:02 |
| catalogrule_rule          | Catalog Rule Product | Ready  | Schedule  | idle (0 in backlog) | 2026-06-14 09:28:02 |
| catalogsearch_fulltext    | Catalog Search       | Ready  | Schedule  | idle (0 in backlog) | 2026-06-14 14:02:10 |
| catalog_category_product  | Category Products    | Ready  | Schedule  | idle (0 in backlog) | 2026-06-14 09:28:02 |
| customer_grid             | Customer Grid        | Ready  | Schedule  | idle (0 in backlog) | 2026-06-14 09:28:02 |
| design_config_grid        | Design Config Grid   | Ready  | Schedule  | idle (0 in backlog) | 2026-06-14 09:28:02 |
| inventory                 | Inventory            | Ready  | Schedule  | idle (0 in backlog) | 2026-06-14 09:28:02 |
| catalog_product_category  | Product Categories   | Ready  | Schedule  | idle (0 in backlog) | 2026-06-14 09:28:02 |
| catalog_product_attribute | Product EAV          | Ready  | Schedule  | idle (0 in backlog) | 2026-06-22 10:09:25 |
| catalog_product_price     | Product Price        | Ready  | Schedule  | idle (0 in backlog) | 2026-06-14 12:44:58 |
| cataloginventory_stock    | Stock                | Ready  | Schedule  | idle (0 in backlog) | 2026-06-14 09:28:02 |
+---------------------------+----------------------+--------+-----------+---------------------+---------------------+

重建索引后，系统负载确实明显降了下来。

排查的细节后续补充一下，今晚安装 RuoYi Vue 的环境，折腾了一晚上，明天要早起，先睡了。

七牛 CDN 域名免费证书续费报错：[400600] 前置订单未完成，请稍后重试

2026-06-19 22:51:07

今天在进行七牛 CDN 域名免费 SSL 证书续期时，发现不能直接续费了。会报错：

[400600] 前置订单未完成，请稍后重试

这个提示也太抽象了，咱能做个正常点的提示吗？

看了一下文档：

https://developer.qiniu.com/fusion/3905/ssl-certificate-faq

Q8: 免费证书到期后，续费报错：[400600] 前置订单未完成，请稍后重试点击查看，如何处理？

免费证书到期后，不需要续费，您重新申请购买新的免费证书即可。

Q7: 证书到期了可以自动续费吗？

证书到期现在不支持自动续费，需要重新购买新的证书，完成验证，证书签发后部署到CDN进行替换即可。

真是折腾，操作越来越麻烦。只能新建一个免费的证书了。

入职轮胎厂的培训周，day 3

2026-06-18 07:06:55

入厂培训的第三日，主要学习了厂规厂纪，及安全生产相关的规范。确实做的比较细致，而且各种真实案例。看来平时总结到位，且每次事故都有复盘和原因分析，这个难能可贵。至少比上家公司天天鼓吹自己管理先进，实则从来没有深入一线进行经验总结，都是假大空的战略规划。

每堂课都有一张笔答的试卷。这个形式很有效，可以避免培训课程变成走过场，而且手写一遍会加深记忆。类似于我记录笔记的过程。最后答完试题后，每张试题我都拍照留念，以备后续复习😅。

员工手册翻了一遍，学到了不少。

PCR 与 TBR

在轮胎行业，PCR 和 TBR 是两种最重要的轮胎分类，分别代表乘用车轮胎和商用车轮胎。

PCR (Passenger Car Radial)：乘用子午线轮胎。主要用于轿车、SUV、MPV等。特点是舒适静音、燃油经济性好，通常为半钢结构（胎体有钢丝带束层，胎帘是纤维）。
TBR (Truck and Bus Radial)：卡客车子午线轮胎。主要用于卡车、客车等重型商用车辆。特点是承载能力强、坚固耐用，通常为全钢结构（胎体和带束层均为钢丝）。

radial 是什么意思

在轮胎术语中，Radial（子午线）指的是一种轮胎内部帘布层的结构方式。你可以把它理解为轮胎的“骨架”排列技术。

结构特点（像地球经线）：帘布层的帘线从轮胎一侧胎圈笔直地延伸到另一侧胎圈，方向与胎面中心线呈90度排列。这就像地球的子午线（经线），因此得名。
关键支撑（加“腰带”）：因为帘线是竖着的，胎面容易变形，所以会在胎面下方紧紧包裹上几层高强度钢丝带束层（像腰带一样箍住），保证胎面平整。

相比老式的“斜交轮胎（Bias）”：

更耐用：高速行驶时发热小，不易爆胎，寿命更长。
更省油：胎面接地更平稳，滚动阻力小。
更舒适：胎壁相对柔软，能缓冲路面颠簸。

比如轮胎规格 205/55R16 里的“R”，就是指这条轮胎是“子午线结构”。现在市面上98%以上的轿车和卡车轮胎都是这种结构。😊

BPM

BPM 指的是 Business Process Management（业务流程管理）。

简单来说，它是一套软件系统，专门用来把公司的各种审批（如请假、报销、采购）搬到线上，实现自动化流转。你可以把它想象成一个“数字交通指挥官”：

画流程：管理员在系统里画好流程图（如：员工申请 → 主管审批 → 财务打款）。
自动推：申请人提交后，系统会自动把待办任务推送到当前审批人的账号或App上。
防遗漏：如果审批人忘了处理，系统会自动发出催办提醒；遇上紧急情况，还能一键“转交”或“加签”。
留痕迹：所有审批步骤、操作时间和修改记录都会被完整保存，方便事后追溯。

市面上常见的钉钉审批、企业微信等，底层核心都是BPM引擎在工作。

SunZhongWei | 孙仲维 修改