# TPCC测试方法—benchmarksql
## 一、环境准备
　　操作系统：openEuler 22.03 x86_64

　　前提条件：openGauss已经编译并安装成功，gsql可以正常连接数据库

　　需要的依赖：ant

```bash
sudo dnf install ant
```

### 1.1 创建新用户
　　连接数据库`gsql -r -p 5432`，创建远程连接用户tpcc，并授予SYSADMIN管理员权限。

```sql
CREATE USER tpcc PASSWORD 'Tpcc@123';
ALTER USER tpcc SYSADMIN;
create database tpccdb;
```

　　这里用户tpcc用于做benchmaksql的测试用户，测试数据库为tpccdb，该用户赋予管理员权限。

### 1.2 安装BenchMarkSQL
1. 下载并上传BenchMarkSQL 下载BenchMarkSQL源码包，并上传和解压。 下载地址：[https://sourceforge.net/projects/benchmarksql/](https://sourceforge.net/projects/benchmarksql/)
2. 将benchmarksql-5.0.zip 压缩包上传至服务器上并解压。 解压

```bash
unzip benchmarksql-5.0.zip
```

### 1.3 下载openGauss JDBC驱动
　　BenchMarkSQL使用JDBC驱动包，连续各种数据库，故需要下载openGauss对应版本的JDBC驱动包。

+ 下载地址：[https://opengauss.org/zh/download/](https://opengauss.org/zh/download/)


![](https://blog.lc044.love/static/img/eded6a5527da085cb3fe68158ffad6a1.image.webp)

　　上传openGauss-5.0.0-JDBC.tar.gz到benchmarksql-5.0/lib/postgres/路径，并解压。openGauss的JDBC驱动解压后有两个jar包（`postgresql.jar`和`opengauss-jdbc-5.0.0.jar`），解压前需要将benchmarksql-5.0/lib/postgres/路径下原有的`postgresql.jar`文件删除，然后将解压后的两个jar包复制到benchmarksql-5.0/lib/postgres/路径下。

```bash
cd ~/benchmarksql-5.0/lib/postgres/
# 删除原有的postgresql.jar
mv postgresql.jar postgresql.jar.bak
tar -xzvf openGauss-5.0.0-JDBC.tar.gz
```

### 1.4 编译BenchMarkSQL
```bash
cd ~/benchmarksql-5.0
ant
```

![](https://blog.lc044.love/static/img/ebfc752906ffa6c4f9ef963a8dd53c52.image.webp)

## 二、修改配置
### 2.1 创建openGauss的props文件
　　benchmarksql-5.0/run/ 路径下的 Props.*为BenchMarkSQL的测试配置文件，在生成测试数据和执行测试时，BenchMarkSQL都会使用该文件。

　　可复制已有的props.*模板，修改为可用于openGauss的配置文件。

```bash
cd ~/benchmarksql-5.0/run
cp props.pg props.opengauss
nano props.opengauss
```

　　写入如下信息，具体配置根据注释修改

```bash
db=postgres
driver=org.postgresql.Driver
// 数据库的ip、端口和数据库名
conn=jdbc:postgresql://127.0.0.1:33000/tpccdb
// 前面创建的数据库用户名
user=tpcc
// 数据库密码
password=Tpcc@123

// 数据仓数量
warehouses=100
// 数据创建工作线程数
loadWorkers=25

// 测试过程的连接终端数（并发数）
terminals=100
// 每个终端运行的事务数，该参数与下面的runMins是两种测试策略，所以设置每个终端运行的事务数之后测试时间必须设置为0
runTxnsPerTerminal=0
// 测试时间，如果设置了测试时间，那么runTxnsPerTerminal参数必须为0
runMins=15
//Number of total transactions per minute，0代表无限制
limitTxnsPerMin=0

//Set to true to run in 4.x compatible mode. Set to false to use the
//entire configured database evenly.
terminalWarehouseFixed=false

//The following five values must add up to 100
//The default percentages of 45, 43, 4, 4 & 4 match the TPC-C spec
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4

// Directory name to create for collecting detailed result data.
// Comment this out to suppress.
resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS
osCollectorScript=./misc/os_collector_linux.py
osCollectorInterval=1
// 服务器ssh连接的用户名和地址（Tpcc测试机必须跟数据库服务器设置ssh互信）
osCollectorSSHAddr=shuaikangzhou@127.0.0.1
// 监控的磁盘和网卡，可以设置多个，用空格隔开，网卡命名方式net_xxx，xxx是设备名,磁盘命名方式 blk_xxx，xxx是磁盘名
osCollectorDevices=net_eth4 blk_sdc
```

+ 网卡查看方式

```bash
ifconfig
```

![](https://blog.lc044.love/static/img/504c3ac164c90ba4ac51b24028cf42b8.image.webp)

这里网卡显示为zttddzk7rq，全拼写成 net_zttddzk7rq

+ 磁盘查看方式

```bash
lsblk
```

‍选择数据库数据存储目录所挂载的磁盘，这里显示整个根目录(/)都挂载到sdc磁盘了，所以磁盘名为blk_sdc


![](https://blog.lc044.love/static/img/145a75168cf11da30c2e518d6bece8d4.image.webp)

+ 如果服务器ssh用的不是默认端口需要修改benchmarksql-5.0/src/OSCollector/OSCollector.java文件修改之后需要重新编译

![](https://blog.lc044.love/static/img/2c13b2ee78ddf6baaf8d363ab89c4680.image.webp)
```bash
    if (sshAddress != null)
    {
        cmdLine.add("ssh");
        // cmdLine.add("-t");
        cmdLine.add(sshAddress);
        cmdLine.add("-p 2222");
    }
```

## 三、开始测试
### 3.1 生成测试数据。
```bash
cd ~/benchmarksql-5.0/run
./runDatabaseBuild.sh props.opengauss
```


![](https://blog.lc044.love/static/img/8fa84a2001acb481a59ea1913e279e0c.image.webp)

### 3.2 压力测试
```bash
 ./runBenchmark.sh props.opengauss
```


![](https://blog.lc044.love/static/img/74c21fb90984c76f9ba03e19fe56296e.image.webp)

　　测试完成之后会在当前目录下生成测试结果，位于./my_result_xxxx-xx-xx_xxxx文件夹下

![](https://blog.lc044.love/static/img/f22b7bbe6a18732a9ed5addd5bec895c.image.webp)

### 3.3 生产压测报告
　　该操作需要安装R语言的环境，生成报告之前需要检查一下R语言环境是否存在。

```bash
R --version
```

![](https://blog.lc044.love/static/img/1b9728f7849bf4c8b199c502cefa001b.image.webp)

　　如果没有R语言环境需要手动下载源码并编译

+ 生成报告

```bash
cd benchmarksql-5.0/run
./generateGraphs.sh my\_result\_2023-xx-xx\_xxxxxx
./generateReport.sh my\_result\_2023-xx-xx\_xxxxxx
```

+ 生成图片


![](https://blog.lc044.love/static/img/c337035e2395ef8dde4c8f63e5332ed9.image.webp)

+ 生成报告

![](https://blog.lc044.love/static/img/dbe90ccc987abda315b1dfcf5e211789.image.webp)

　　下载my_result_2023-05-04_142051文件夹到桌面，使用浏览器打开文件夹内的report.html文件


![](https://blog.lc044.love/static/img/2c735fc9a0f1c87b7cf60d050cbeeb71.image.webp)

### 3.4 清理数据
　　该操作会将数据库仓库全部删除，再次测试需要重新创建数据

```bash
./runDatabaseDestroy.sh props.opengauss
```

## 四、其他说明
### 4.1 修改openGauss监听地址
　　默认配置只能本机连接数据库，为了不影响性能，TPCC客户端尽量不要跟数据库在同一台机器上，此时需要修改数据库的配置以便局域网内的其他设备可以连接。

　　找到数据库的数据目录

1. **编辑** ****`pg_hba.conf`**** **配置文件** 添加连接配置

```bash
host    all             all             172.19.0.0/16            sha256
```

2. 编辑`postgresql.conf`文件 编辑配置文件，将：

```properties
listen_addresses = 'localhost'  # 或默认只监听127.0.0.1
```

 修改为：

```properties
listen_addresses = '*'  # 允许监听所有网络接口（包括局域网IP）
```

 也可以指定具体的局域网 IP（如`172.19.0.209`），但`*`更灵活。

3. 重启数据库

### 4.2 日志配置
　　benchmarksql-5.0/run/log4j.properties文件是日志文件的配置信息，可以修改这个配置将不同的日志输出到不同的文件里，方便后续解析日志信息

```plain
# log4j.rootLogger=TRACE, CONSOLE, E, T
log4j.rootLogger=DEBUG, CONSOLE, E, FILE  # 日志记录器的名称

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Threshold=INFO
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern= %d{HH:mm:ss,SSS} [%t] %-5p %x %C{1} : %m%n

log4j.appender.E=org.apache.log4j.RollingFileAppender
log4j.appender.E.Threshold=WARN
log4j.appender.E.File=benchmarksql-error.log
log4j.appender.E.MaxFileSize=100MB
log4j.appender.E.MaxBackupIndex=1
log4j.appender.E.layout=org.apache.log4j.PatternLayout
log4j.appender.E.layout.ConversionPattern= %d{HH:mm:ss,SSS} [%t] %-5p %x %C{1} : %m%n

log4j.appender.T=org.apache.log4j.FileAppender
log4j.appender.T.Threshold=TRACE
log4j.appender.T.File=benchmarksql-trace.log
log4j.appender.T.append=false
log4j.appender.T.layout=org.apache.log4j.PatternLayout
log4j.appender.T.layout.ConversionPattern= %d{HH:mm:ss,SSS} [%t] %-5p %x %C{1} : %m%n

# 文件输出配置
log4j.appender.FILE=org.apache.log4j.FileAppender   # 将日志写入文件里
log4j.appender.FILE.Threshold=DEBUG   # 日志的级别
log4j.appender.FILE.File=benchmarksql-debug.log   # 日志文件名
log4j.appender.FILE.DatePattern='.'yyyyMMdd_HHmmss
log4j.appender.FILE.Append=false   # true：不清空文件直接追加到文件末尾，false：先清空文件再写日志
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c - %m%n
```

### 4.3 统计内存占用
　　下面的配置可以将debug日志输出到benchmarksql-debug.log文件里

```plain
# 文件输出配置
log4j.appender.FILE=org.apache.log4j.FileAppender   # 将日志写入文件里
log4j.appender.FILE.Threshold=DEBUG   # 日志的级别
log4j.appender.FILE.File=benchmarksql-debug.log   # 日志文件名
log4j.appender.FILE.DatePattern='.'yyyyMMdd_HHmmss
log4j.appender.FILE.Append=false   # true：不清空文件直接追加到文件末尾，false：先清空文件再写日志
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c - %m%n
```

　　修改benchmarksql-5.0/src/client/jTPCC.java的最后一个函数，在倒数第三行添加`log.debug(informativeText);`就能将统计信息写入日志里

```java
synchronized private void updateStatusLine()
    {
    long currTimeMillis = System.currentTimeMillis();

    if(currTimeMillis > sessionNextTimestamp)
    {
        StringBuilder informativeText = new StringBuilder("");
        Formatter fmt = new Formatter(informativeText);
        double tpmC = (6000000*fastNewOrderCounter/(currTimeMillis - sessionStartTimestamp))/100.0;
        double tpmTotal = (6000000*transactionCount/(currTimeMillis - sessionStartTimestamp))/100.0;

        sessionNextTimestamp += 1000;  /* update this every seconds */

        fmt.format("Term-00, Running Average tpmTOTAL: %.2f", tpmTotal);

        /* XXX What is the meaning of these numbers? */
        recentTpmC = (fastNewOrderCounter - sessionNextKounter) * 12;
        recentTpmTotal= (transactionCount-sessionNextKounter)*12;
        sessionNextKounter = fastNewOrderCounter;
        fmt.format("    Current tpmTOTAL: %d", recentTpmTotal);

        long freeMem = Runtime.getRuntime().freeMemory() / (1024*1024);
        long totalMem = Runtime.getRuntime().totalMemory() / (1024*1024);
        fmt.format("    Memory Usage: %dMB / %dMB          ", (totalMem - freeMem), totalMem);

        System.out.print(informativeText);
        log.debug(informativeText);
        for (int count = 0; count < 1+informativeText.length(); count++)
        System.out.print("\b");
    }
    }
```

　　修改之后需要重新编译

```java
cd bencmarksql-5.0/
ant
```

　　可以写一个简单的脚本解析日志文件的内存占用情况

```java
2025-09-16 12:35:27 DEBUG jTPCC - Term-00, Running Average tpmTOTAL: 59875.17    Current tpmTOTAL: 39209184    Memory Usage: 333MB / 915MB 
```

　　新建一个Python文件：run/misc/memory.py 写入下面内容

```python
import re
import pandas as pd
import matplotlib.pyplot as plt
import os
import sys

def main():
    # 检查命令行参数
    if len(sys.argv) != 2:
        print("用法: python memory_usage_plot.py <日志文件路径>")
        sys.exit(1)
    
    # 获取命令行输入的日志文件路径
    log_file = sys.argv[1]
    
    # 验证文件是否存在
    if not os.path.exists(log_file):
        print(f"错误: 文件 '{log_file}' 不存在")
        sys.exit(1)
    
    # 用来存储数据
    timestamps = []
    used_mem = []
    total_mem = []
    
    # 匹配日志中时间和 Memory Usage
    pattern = re.compile(r"(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}).*Memory Usage: (\d+)MB / (\d+)MB")
    
    with open(log_file, "r") as f:
        for line in f:
            match = pattern.search(line)
            if match:
                timestamps.append(match.group(1))
                used_mem.append(int(match.group(2)))
                total_mem.append(int(match.group(3)))
    
    if not timestamps:
        print("警告: 未在日志文件中找到任何内存使用记录")
        sys.exit(0)
    
    # 构建 DataFrame
    df = pd.DataFrame({
        "timestamp": pd.to_datetime(timestamps),
        "used_mb": used_mem,
        "total_mb": total_mem
    })
    
    # 计算相对时间（分钟），从0开始
    start_time = df["timestamp"].iloc[0]
    df["minutes_since_start"] = (df["timestamp"] - start_time).dt.total_seconds() / 60
    
    # 绘制曲线
    plt.figure(figsize=(12, 6))
    plt.plot(df["minutes_since_start"], df["used_mb"], label="Used Memory (MB)", color="blue")
    plt.plot(df["minutes_since_start"], df["total_mb"], label="Total Memory (MB)", color="orange", linestyle="--")
    plt.xlabel("Minutes Since Start")
    plt.ylabel("Memory (MB)")
    plt.title("BenchmarkSQL Memory Usage Over Time")
    plt.legend()
    plt.grid(True)
    plt.tight_layout()
    
    # 获取日志文件所在目录
    log_dir = os.path.dirname(log_file)
    # 构建图片保存路径（与日志文件同目录）
    image_path = os.path.join(log_dir, "memory_usage_curve.png")
    
    # 保存图片
    plt.savefig(image_path, dpi=150)
    print(f"曲线已保存为 {image_path}")

if __name__ == "__main__":
    main()

```

　　运行脚本：

```python
python ./misc/memory benchmark-debug.log
```

　　此时就会在benchmark-debug.log所在的目录下生成一个内存占用图（memory_usage_curve.png）

![](https://blog.lc044.love/static/img/f8f7445b81741e9cc5d4d8069cbd57ae.image.webp)


## 五、自动化测试脚本


```bash
sh runTpcc.sh -a -c -w 200 -n 3
```

### 5.1 参数说明

* -a: 开启ATF，默认不开启
* -c: 重建数据仓，默认不重建（相关细节在server.sh里）
* -w k: 数据仓大小（仅支持200、400、1000），默认为200
* -n k: 连续测试k次，默认为1
* -m jvm_max_mem: 限制JVM最大堆内存，默认不限制

### 5.2 前置准备
1. 修改props.* 文件里的连接参数
2. 打开server.sh，根据教程修改下面几个变量

```bash
# 远程服务器信息 - 请根据实际情况修改以下信息

remote_server="zhousk@192.168.200.209"

# 远程服务器用户名和主机地址，例如：root@192.168.1.100，需要与本机设置互信

db_dir="/mnt/nvme2n1/zhousk/data/data_n1"
TABSPACE2_DIR="/mnt/nvme3n1/zhousk/data/data_n1"
TABSPACE3_DIR="/mnt/nvme4n1/zhousk/data/data_n1"

XLOG_DIR="/mnt/raid0/zhousk/data/data_n1/pg_xlog"

backup_dir="/mnt/nvme4n1/zhousk/backup/${warehouses}w"
```

1. benchmarksql测试机与数据库服务器配置互信

2. 创建原始数据，根据[教程](../README.md)分别生成仓数为100、200、1000的数据库，分别将整个数据库目录备份到backup_dir文件夹下

    例如：100仓的数据库目录为/mnt/nvme4n1/zhousk/backup/100w

3. 数据分盘，在不同硬盘上分别创建以下四个文件夹并把实际目录写到server.sh文件里

    * db_dir：测试数据库数据目录
    * TABSPACE2_DIR：数据表空间的软连接地址（在其他磁盘上）
    * TABSPACE3_DIR：另一个数据表空间的软连接地址
    * XLOG_DIR：xlog软连接地址

> PS: 为避免数据干扰每次测试前都会，删除四个文件夹下的数据然后将对应仓数的备份数据复制到db_dir下，然后创建四个软连接将数据分散到多个硬盘上

### 5.3 查看报告

使用`runTpcc.sh`之后每次测试完成之后都会在结果文件夹下生成一个 `report.html`, 需要将整个文件夹下载到本地才能查看，比较麻烦。

`app.py` 提供了一个网络服务器，可以通过浏览器查看测试报告

#### 5.4 使用方法

```bash
python3 app.py
```

在浏览器打开 `http://ip:8000` （ip为benchmarksql的ip地址）来查看报告


![](https://blog.lc044.love/static/img/a703e4c2df27f6b8258bd4db7d895a04.image.webp)

### 5.5 源代码

[https://github.com/LC044/BenchmarkSQL](https://github.com/LC044/BenchmarkSQL)
　　‍



TPCC测试方法—benchmarksql

## 一、了解 PaddleOCR

在当今数字化时代，数据安全与便捷性愈发受到重视。许多企业与个人在处理文档、图片等数据时，对文字识别有着强烈需求，却担忧数据在云端处理时的隐私泄露风险。



PaddleOCR 的私有部署方案应运而生，它允许用户将文字识别服务搭建在本地环境，极大地增强了数据的隐私性。通过在私有服务器或本地设备上部署，企业敏感文件、个人私密文档等无需上传至外部云端，有效避免了数据在传输与存储过程中的泄露风险。同时，私有部署带来了使用上的便利性，无需依赖不稳定的网络连接，用户可随时随地快速调用 OCR 服务，实现对各类文档的高效处理，提升工作效率。


PaddleOCR 是百度基于飞桨深度学习框架研发的一款开源 OCR 工具，旨在打造一套丰富、领先且实用的 OCR 工具库，打通数据准备、模型训练、压缩和推理部署的全流程。它采用深度学习技术，先对图片进行缩放、灰度化、去噪等预处理操作，以提高文字识别的准确率。接着，运用深度学习模型检测图片中的文字区域，并将其转换为电脑可识别的边界框。最后，利用另一个深度学习模型识别边界框中的文字，将其转化为电脑可识别的文本。接下来，我们将详细介绍如何使用 Docker 在本地进行 PaddleOCR 的部署，让您轻松搭建属于自己的高效文字识别系统。


## 二、使用 Docker 部署 PaddleOCR

### （一）配置Dockerfile文件

创建文件名为`Dockerfile`的文件。

参考官方的[安装教程](https://www.paddleocr.ai/main/version3.x/installation.html)可以直接从官方的镜像源拉取paddlepaddle镜像，然后下载paddleocr以及部署paddleocr需要的paddlex，安装完成之后接着使用paddleocr命令执行一次文字识别，该操作是为了初始化模型，会从官方直接下载模型文件。最后通过`paddlex`服务化部署paddleocr，可以通过https服务调用ocr接口。

```dockerfile
FROM ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/paddle:3.0.0

# 切换工作目录
WORKDIR /paddle

# # 安装 PaddleOCR 和 PaddleX 依赖
# RUN pip install paddlex
RUN pip install paddlex[ocr-core]
RUN paddlex --install serving
RUN paddleocr ocr -i https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_002.png \
    --use_doc_orientation_classify False \
    --use_doc_unwarping False \
    --use_textline_orientation False

# 默认命令：启动 PaddleX OCR 服务
CMD ["paddlex", "--serve", "--pipeline", "OCR"]
```

在 Dockerfile 所在目录执行：

```bash
docker build -t paddleocr:1.0 .
```

运行容器

```bash
docker run -d -p 9080:8080 --name paddleocr paddleocr:1.0
```

此时paddleocr服务就运行成功了，日志会输出以下内容


![image.png](https://blog.lc044.love/static/img/296cced381b433c61a2a54ffc604e25b.image.webp)

然后可以通过三、测试与验证来测试ocr效果，如果需要使用docker compose 部署可以参考下面内容。

### （二）配置Docker Compose 文件

创建docker-compose.yaml文件，然后把上面的`Dockerfile`文件和docker-compose.yaml文件放在一个文件夹下。

```yaml
services:
  paddleocr:
    build: .
    container_name: paddleocr
    stdin_open: true
    tty: true
    restart: always #重启策略
    volumes:
      - ./:/paddle
    shm_size: "8g"
    ports:
      - "9090:8080"   # 映射宿主机端口到容器
```

在docker-compose.yml所在目录执行：

```bash
docker-compose up -d  # -d表示后台运行
```

### （三）在绿联NAS上部署

#### 使用 Docker Compose 部署容器

在 UGOS Pro 系统上，推荐使用项目 Docker Compose 快速部署容器，适合需同时管理多个容器的场景，这种方法简化了容器的部署与管理工作。以下是使用 Docker Compose 部署 paddleocr 的详细步骤。

#### 在docker目录下创建一个空文件夹 paddleocr

将上面的`Dockerfile`和Docker Compose 配置文件上传到该文件夹。

#### 进入 Docker 项目界面

在 UGOS Pro 系统中，打开 Docker 应用，点击【项目】 \> 【创建】，启动项目创建向导。

#### 配置 Docker Compose 文件

在项目创建向导中，选择存放路径为前面创建的paddleocr文件夹，导出docker compose配置，点击`立即部署`，系统会自动拉取镜像并启动容器。

部署完成后执行下面的测试脚本。

## 三、测试与验证

### （一）运行测试案例

部署完成后，就可以对 PaddleOCR 进行测试了。我们先准备一张简单的测试图片，比如一张写有 “欢迎使用 PaddleOCR” 的白底黑字图片，假设图片名为 “test.jpg” 。

接下来，通过命令行或编写 Python 脚本来进行测试。如果使用 Python 脚本，可以按照以下步骤进行：

1. 打开文本编辑器，创建一个新的 Python 文件，比如 “[test_ocr.py](http://test_ocr.py)”。
2. 在文件中编写以下代码：

```Python
import base64
import requests

API_URL = "http://192.168.1.113:9090/ocr"

def ocr(image_path):
    with open(image_path, "rb") as file:
        file_bytes = file.read()
        file_data = base64.b64encode(file_bytes).decode("ascii")

    payload = {"file": file_data, "fileType": 1}

    response = requests.post(API_URL, json=payload)

    assert response.status_code == 200
    result = response.json()["result"]
    for i, res in enumerate(result["ocrResults"]):
        print(res["prunedResult"])
        ocr_img_path = f"ocr_{i}.jpg"
        with open(ocr_img_path, "wb") as f:
            f.write(base64.b64decode(res["ocrImage"]))
        print(f"Output image saved at {ocr_img_path}")
    return result

# 使用示例
if __name__ == "__main__":
    # 原始图片路径
    input_image_path = "./data/test.jpg"
    import time
    st = time.time()
    # 使用优化后的图片进行OCR识别
    result = ocr(output_image_path)
    et = time.time()
    for i, res in enumerate(result["ocrResults"]):
        # 打印识别结果
        print(res["prunedResult"]['rec_texts'])
    print(f'耗时：{et-st:.1f}s')

```

3. 保存文件，然后在命令行中运行该脚本。如果你的 Python 环境已经配置好，在命令行中进入到 “[test_ocr.py](http://test_ocr.py)” 所在的目录，运行命令 “python [test_ocr.py](http://test_ocr.py)” ，脚本就会读取图片，将其转换为 base64 编码后发送给 PaddleOCR 服务，并接收返回的识别结果。

### （二）检查识别结果

运行测试脚本后，我们需要检查识别结果是否准确。在脚本的输出中，会看到类似以下的内容：

```json
{'model_settings': {'use_doc_preprocessor': True, 'use_textline_orientation': True}, 'doc_preprocessor_res': {'model_settings': {'use_doc_orientation_classify': True, 'use_doc_unwarping': True}, 'angle': 0}, 'dt_polys': [[[49, 22], [96, 20], [98, 46], [51, 49]], [[51, 71], [98, 71], [98, 100], [51, 100]], [[51, 122], [98, 122], [98, 148], [51, 148]], [[53, 173], [99, 173], [99, 200], [53, 200]], [[51, 224], [98, 224], [98, 251], [51, 251]], [[49, 273], [99, 276], [97, 304], [47, 304]]], 'text_det_params': {'limit_side_len': 64, 'limit_type': 'min', 'thresh': 0.3, 'max_side_limit': 4000, 'box_thresh': 0.6, 'unclip_ratio': 1.5}, 'text_type': 'general', 'textline_orientation_angles': [0, 0, 0, 0, 0, 0], 'text_rec_score_thresh': 0.0, 'return_word_box': False, 'rec_texts': ['桌面', '下载', '文档', '图片', '音乐', '视频'], 'rec_scores': [0.99993896484375, 0.9999144673347473, 0.9977823495864868, 0.9996212720870972, 0.9995757937431335, 0.9998965859413147], 'rec_polys': [[[49, 22], [96, 20], [98, 46], [51, 49]], [[51, 71], [98, 71], [98, 100], [51, 100]], [[51, 122], [98, 122], [98, 148], [51, 148]], [[53, 173], [99, 173], [99, 200], [53, 200]], [[51, 224], [98, 224], [98, 251], [51, 251]], [[49, 273], [99, 276], [97, 304], [47, 304]]], 'rec_boxes': [[49, 20, 98, 49], [51, 71, 98, 100], [51, 122, 98, 148], [53, 173, 99, 200], [51, 224, 98, 251], [47, 273, 99, 304]]}
```

在这个结果中，“rec_texts” 字段就是识别出的文本内容，我们可以将其与图片中的实际文字进行对比，判断识别是否准确。这里识别出的 “欢迎使用 PaddleOCR” 与图片内容一致，说明识别是正确的。“rec_scores” 字段表示识别结果的置信度，取值范围是 0 到 1，越接近 1 表示置信度越高，识别结果越可靠，这里的置信度为 0.9987，说明识别结果的可信度很高。“dt_polys” 字段表示文字在图片中的位置，以四边形的四个顶点坐标来表示，通过这些坐标可以在图片上绘制出文字的位置框，进一步验证识别的准确性。如果识别结果不准确，可能是由于图片质量不佳、模型不匹配、参数设置不当等原因导致的，可以尝试对图片进行预处理、更换模型或调整参数来提高识别准确率。

### 

未来，PaddleOCR 在绿联 NAS 上的私有部署应用前景极为广阔，其强隐私性与便利性将进一步凸显。在文档处理方面，结合自动化脚本和其他办公工具，能够实现文档的自动分类、内容提取和关键词检索。例如，将 PaddleOCR 与 Python 的办公库相结合，当新文档存入绿联 NAS 时，可自动触发 PaddleOCR 进行文字识别，随后依据识别内容将文档分类至不同文件夹，大幅提升文档管理效率，且整个过程数据始终在本地，隐私安全得以保障。在图像分析领域，与图像识别技术结合，可实现对图片中文字和物体的同时识别与分析，应用于安防监控中的文字标识识别、智能相册中的文字信息提取等场景，让用户在本地即可快速处理分析图像，无需等待网络传输与云端处理。此外，还可探索 PaddleOCR 在多语言环境下的自动化翻译流程，将识别出的文字快速翻译成多种语言，满足跨国交流和文档处理的需求，全程在私有环境内运行，数据安全无虞。相信随着技术的不断发展和探索，PaddleOCR 在绿联 NAS 上的私有部署会发挥出更大价值，为我们的工作和生活带来更多便利与创新，在保障隐私的同时，提供高效、便捷的文字识别解决方案。

绿联NAS+Docker：解锁PaddleOCR高效文字识别新姿势

# openGauss通信协议
　客户端可以通过两种 "子协议" 来发送请求，分别是 `simple query` 和 `extened query`。使用 `simple query` 时，客户端发送字符串文本请求，后端收到后立即处理并返回结果（gsql）；使用 `extened query` 时，发送请求的过程被分为若干步骤，通常包括 Parse，Bind ， Execute和Sync。本文主要关注 `extened query`。
 
## 一、消息格式
　　客户端和服务端所有通信都通过消息流进行。消息的第一个字节标识消息类型，随后四个字节标识消息内容的长度（该长度包括这四个字节本身），具体的消息内容由消息类型决定。

![](https://blog.lc044.love/static/img/972f04fedcb2afc606c674868bc982e1.image.webp)

　　openGauss 目前支持如下客户端消息类型：

```c++
switch (qtype) {
        case 'a': /* Not reach : Trigger shipped to DN */
        case 'A': /* AC WLM */
        case 'b': /* Barrier */
        case 'B': /* bind */
        case 'c': /* copy done */
        case 'C': /* close */
        case 'D': /* describe */
        case 'd': /* copy data */
        case 'e': /* Thread ID */
        case 'E': /* execute */
        case 'f': /* copy fail */
        case 'F': /* fastpath function call */
        case 'g': /* GXID */
        case 'G': /* PGXCBucketMap and PGXCNodeId */
        case 'h': /* hybrid message query */
        case 'H': /* flush */
        case 'i': /* Instrumentation */
        case 'I': /* Push, Pop schema name */
        case 'j': /* Check gtm mode */
        case 'J': /* Trace ID */
        case 'k': /* Global session ID */
        case 'K': /* client conn driver net_time */
        case 'l': /* get and handle csn for csnminsync */
        case 'L': /* Link gc_fdw */
        case 'M': /* Command ID */
        case 'n': /* Committing */
        case 'N': /* Commit csn */
        case 'o': /* role name */
        case 'O': /* to reset openGauss thread in pooler stateless reuse mode */
        case 'p': /* Process Pid */
        case 'P': /* parse */
        case 'q': /* Query ID */
        case 'Q': /* simple query */
        case 'r': /* Plan ID with sync */
        case 'R': /* Reply collect info */
        case 's': /* Snapshot */
        case 'S': /* sync */
        case 't': /* Timestamp */
        case 'T': /* consistency point */
        case 'u': /* AUTONOMOUS_TRANSACTION simple query */
        case 'U': /* batch bind-execute */
        case 'V': /* client conn driver support trace info*/
        case 'W': /* WLM Control Group */
        case 'w': /* dynamic WLM */
        case 'x': /* imcs populate query */
        case 'X': /* terminate */
        case 'y': /* sequence from cn 2 dn */
        case 'Y': /* plan with params */
        case 'z': /* PBE for DDL */
        case 'Z': /* simple plan  */
        default:
            break;
}
```

　　服务端收到如上消息的处理流程可以参考 [PostgresMain](https://github.com/postgres/postgres/blob/bf68b79e50e3359accc85c94fa23cc03abb9350a/src/backend/tcop/postgres.c#L4277)。服务端发送给客户端的消息有如下类型（不完全）：

```java
switch (c) {
          case 'K': //receive dbTime
          case 'A': // Asynchronous Notify
          case '1': // Parse Complete (response to Parse)
          case 't': // ParameterDescription
          case '2': // Bind Complete (response to Bind)
          case '3': // Close Complete (response to Close)
          case 'n': // No Data (response to Describe)
          case 's':  // Portal Suspended (end of Execute)
          case 'C':  // Command Status (end of Execute)
          case 'D': // Data Transfer (ongoing Execute response)
          case 'E': // Error Response (response to pretty much everything; backend then skips until Sync)
          case 'I':  // Empty Query (end of Execute)
          case 'N': // Notice Response
          case 'S': // Parameter Status
          case 'Z': // Ready For Query (eventual response to Sync)
          case 'G': // CopyInResponse
          case 'H': // CopyOutResponse
          case 'c': // CopyDone
          case 'd': // CopyData
          default:
            throw new IOException("Unexpected packet type: " + c);
}
```

　　客户端处理如上服务端消息的流程可以参考 PostgreSQL libqp 的实现 [pqParseInput3](https://github.com/postgres/postgres/blob/c9d29775195922136c09cc980bb1b7091bf3d859/src/interfaces/libpq/fe-protocol3.c#L63)。

　　openGauss 通信协议包括两个阶段： `startup` 阶段和常规 `normal` 阶段。 `startup` 阶段，客户端尝试创建连接并发送授权信息，如果一切正常，服务端会反馈状态信息，连接成功创建，随后进入 `normal` 阶段。 `normal` 阶段，客户端发送请求至服务端，服务端执行命令并将结果返回给客户端。客户端请求结束后，可以主动发送消息断开连接。

　　`normal` 阶段，客户端可以通过两种 "子协议" 来发送请求，分别是 `simple query` 和 `extened query`。使用 `simple query` 时，客户端发送字符串文本请求，后端收到后立即处理并返回结果（gsql）；使用 `extened query` 时，发送请求的过程被分为若干步骤，通常包括 Parse，Bind ， Execute和Sync。

## 二、**Extended Query 处理流程**
　　在 openGauss 中，**Extended Query（扩展查询，JDBC默认协议）**  是一种通过多个步骤拆分 SQL 执行过程的协议，主要用于参数化查询，能有效避免 SQL 注入、提升重复执行效率。**Extended Query** 不允许在一个请求中包含多条 SQL 命令，否则会报语法错误 **（** Extended Query模式下**JDBC会自动拆分一条语句的多个SQL）** 。Extended Query 协议通常包括 5 个步骤，分别是 Parse，Bind，Describe（可选），Execute 和 Sync。以下分别介绍各个阶段的处理流程。


![](https://blog.lc044.love/static/img/8d23abc8e2cb8fc345b650af5caea21e.image.webp)

### 2.1. Parse（解析）：生成语法树
+ **作用**：客户端发送不带参数的 SQL 模板（如`SELECT * FROM users WHERE id = $1`），服务端收到该消息后，调用 `exec_parse_message` 函数进行处理，进行语法分析、语义分析和重写，同时会创建一个 Plan Cache 的结构，用于缓存后续的执行计划。![](https://blog.lc044.love/static/img/374335e5ca95978cf7fb24998256ef5b.image.webp)
+ **关键操作**：
    - 检查 SQL 语法是否正确（如关键字拼写、语句结构）。
    - 验证表、列等对象是否存在（语义校验）。
    - 生成解析树，存储在服务器的内存中，并返回一个**Parse Complete**消息（包含解析树的标识，如`Portal`或`Statement` ID）。
+ **示例**：客户端发送`Parse("SELECT * FROM users WHERE id = $1")`，服务器返回解析成功的确认。


### 2.2. Bind（绑定）：关联参数与执行计划
+ **作用**：客户端发送参数值（如`$1 = 123`），服务器将参数与解析树绑定，生成**执行计划**（Execution Plan）。openGauss 收到该消息后，调用 `exec_bind_message` 函数进行处理。为之前保存的 Prepared Statement 创建执行计划并将其保存在 Plan Cache 中，创建一个 `Portal` 用于后续执行。

> 在 openGauss 内核中，Portal 是对查询执行状态的一种抽象，该结构贯穿执行器运行的始终。
>


![](https://blog.lc044.love/static/img/b1071543ff660a21bb7818bcee366078.image.webp)

+ **关键操作**：
    - 校验参数类型是否与表字段匹配（如`id`是整数，`$1`不能是字符串）。
    - 基于参数值和数据库统计信息（如索引分布），优化器生成最优执行计划（如选择索引扫描还是全表扫描）。
    - 生成一个**Portal**（可理解为 “执行上下文”），包含绑定后的执行计划，返回`Bind Complete`消息。
+ **示例**：客户端发送`Bind(参数: [123])`，服务器将`123`与`$1`绑定，生成针对`id=123`的执行计划。

### 2.3. Execute（执行）：执行查询并返回结果
+ **作用**：客户端触发执行已绑定的 Portal，服务器执行执行计划，返回结果。`Execute` 消息中可以指定返回的行数，若行数为 0，表示返回所有行。

![](https://blog.lc044.love/static/img/a4ac10ef0d479f546b0db9c2dce70c53.image.webp)

+ **关键操作**：
    - 按照执行计划执行数据操作（如查询、插入、更新）。
    - 若为查询语句，将结果集分批返回给客户端（可通过`Fetch`控制返回行数）。
    - 若为写操作（如`INSERT`），执行事务日志记录和数据页更新。
+ **示例**：客户端发送`Execute(Portal ID)`，服务端收到消息后，执行 `Bind` 阶段创建的 Portal，执行结果通过 `DataRow` 消息返回给客户端，执行完成后发送 `CommandComplete`消息。![](https://blog.lc044.love/static/img/eabdbf92439790ba803eb73d486b32f8.image.webp)msg示例：INSERT 0 1

### 2.4. Sync（同步）：结束当前查询流程
+ **作用**：客户端发送`Sync`消息，服务器清理本次查询的资源，结束当前会话的查询流程。
+ **关键操作**：
    - 释放 Portal 占用的内存资源（解析树、执行计划等）。
    - 向客户端返回`ReadyForQuery`消息，表明当前会话处于 “就绪状态”，可接收新的查询。
+ **示例**：客户端发送`Sync`，服务器清理资源，等待下一次查询请求。

### 2.5. 批量管线与 Sync
　　对于一次执行的多条SQL语句，JDBC会自动将语句拆分成多个单独的SQL语句，每条SQL语句都独立执行Parse/Bind/Describe/Execute流程

```java
String sql = "INSERT INTO users (name, age) VALUES ('Alice', 30);select * from users where age=?;select * from users;select * from users;select * from users;select * from users;";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setInt(1, 30); 
pstmt.execute();
```

![](https://blog.lc044.love/static/img/594959d0e43911a5328a1e042779f1bf.image.webp)

+ 为了减少往返延迟，JDBC 驱动通常将多条语句的 Parse/Bind/Describe/Execute 消息依次**排队发送**（pipelining），而不是一次一收一发，如果数据量小的话仅需一次RTT即可完成通信。
+ 当所有语句对应的 Execute 都发出后，客户端发送一个 **Sync** 消息，表示“这一批所有命令都发完了，请一次性返回结果，最后给我一个 ReadyForQuery”。
+ **服务器 → 客户端**
    - 按照收到的命令顺序依次返回 ParseComplete、BindComplete、RowDescription（若有）、DataRow、CommandComplete……
    - 在最后，返回 **ReadyForQuery**，表示事务状态可查（空闲/活动/回滚），客户端可开始下一次交互。

　　‍



openGauss通信协议

## 1 内容及目的

openGauss-jdbc调试方法，便于快速搭建调试环境

## 2 配置环境过程

操作系统：openEuler22.03 X86

前提要求：

- 有可用的openGauss数据库

## 3 实践过程

### 3.1 安装依赖

软件及环境依赖要求如下：

| 软件及环境要求     | 推荐版本   |
| -------------------- | ------------ |
| maven              | 3.6.1      |
| java               | 1.8        |
| Git Bash (Windows) | 无推荐版本 |

```bash
sudo dnf update
sudo dnf install -y java-1.8.0-openjdk-devel
# 安装完成后，可通过以下命令验证是否安装成功：
java -version
```

#### 安装 Maven 3.6.1

1. 访问[Maven 官方下载页面](https://maven.apache.org/download.cgi)
2. 在页面中找到 “Maven 3 archives”，点击进入，找到 3.6.1 版本并下载对应的压缩包，推荐下载`.tar.gz`格式的文件。
3. 在 openEuler 系统中创建一个文件夹用于存放 Maven 安装包，例如：

    ```bash
    mkdir ~/maven
    cd ~/maven
    tar -zxvf apache-maven-3.6.1-bin.tar.gz
    ```

4. 配置环境变量，编辑`~/.bachrc`文件：

    ```bash
    nano ~/.bachrc
    ```
    
    在文件末尾添加以下内容：

    ```bash
    export MAVEN_HOME=/a-dev/maven/apache-maven-3.6.1
    export PATH=$MAVEN_HOME/bin:$PATH
    ```
   
    保存并退出编辑，然后执行`source ~/.bashrc`使配置生效。

5.  验证安装，执行命令：

    ```bash
    mvn -v
    ```

若显示 Maven 版本信息，则表示安装成功。

### 3.2 安装vscode插件

在vscode插件市场里安装以下插件，注意如果是调试代码在服务器上，则必须在**服务器**上的vscode安装该扩展（图中LOCAL-INSTALLED中的是本地vscode安装的插件，SSH：IP-INSTALLED中显示的是服务器中安装的插件，黄色按钮表示可以将插件安装到服务器上）

- Extension Pack for Java
- Debugger for Java
- Maven for Java
- Project Manager for Java
- Test Runner for Java

![image.png](https://blog.lc044.love/static/img/3bb459a177cba8d02ca9f883366a38b2.image.webp)

### 3.3 编译jdbc

1. 克隆代码并编译

    ```bash
    mkdir ~/proj
    cd ~/proj
    git clone https://gitcode.com/opengauss/openGauss-connector-jdbc.git
    cd openGauss-connnector-jdbc
    sh build.sh
    ```

    编译成功之后会显示

    ![](https://blog.lc044.love/static/img/a7038129608b22b872cbf17b6024495b.image.webp)

    编译后的jar包在output目录下

2. 编写测试代码

    新建测试文件夹

    ```bash
    mkdir -p pgjdbc-client/src/main/java/com/example/
    cd pgjdbc-client/src/main/java/com/example/
    ```

    新建测试文件 `PostgresTest.java`

    ```java
    package com.example;

    import java.sql.*;

    public class PostgresTest {
        public static void main(String[] args) {
            // 数据库连接信息
            String url = "jdbc:postgresql://localhost:33000/tpccdb";
            String username = "tpcc";
            String password = "tpcc@123";

            // SQL查询语句
            String sql = "SELECT * FROM users";

            try (Connection conn = DriverManager.getConnection(url, username, password);
                 Statement stmt = conn.createStatement();
                 ResultSet rs = stmt.executeQuery(sql)) {

                System.out.println("数据库连接成功！");
                System.out.println("服务器版本: " + conn.getMetaData().getDatabaseProductVersion());

                System.out.println("\n查询结果:");
                while (rs.next()) {
                    int id = rs.getInt("id");
                    String name = rs.getString("name");
                    double salary = rs.getDouble("age");
                    System.out.printf("ID: %d, 姓名: %s, 年龄: %.2f%n", id, name, salary);
                }

            } catch (SQLException e) {
                System.err.println("数据库操作失败: " + e.getMessage());
                e.printStackTrace();
            }
        }
    }    
    ```
    ![](https://blog.lc044.love/static/img/2850339e039a395b3420fbe3542e816f.image.webp)

3. 配置Maven依赖

    ```java
    cd ~/proj/opengauss-connector-jdbc/pgjdbc-client/
    ```

    在`pgjdbc-client`目录下创建`pom.xml`文件，写入下面的配置信息

    ```xml
    <project xmlns="http://maven.apache.org/POM/4.0.0"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                                 http://maven.apache.org/maven-v4_0_0.xsd">

        <modelVersion>4.0.0</modelVersion>
        <parent>
            <groupId>com.huawei</groupId>
            <groupId>pgjdbc-aggregate</artifactId>
            <version>42.2.5</version>
        </parent>
        <artifactId>pgjdbc-client</artifactId>

        <dependencies>
            
            <dependency>
                <groupId>org.opengauss</groupId>
                <artifactId>opengauss-jdbc</artifactId>
                <version>7.0.0-RC2</version>
            </dependency>
        </dependencies>
        
    </project>
    ```

    其中parent字段的groupId、groupId、version内容要与`openGauss-connector-jdbc`路径下的`pom.xml`里的内容完全对应

    ![](https://blog.lc044.love/static/img/e78354b938330b497994de61b3291f7c.image.webp)
    
    dependency字段的groupId、groupId、version内容要与`openGauss-connector-jdbc/pgjdbc`路径下的`pom.xml`里的内容完全对应。

    ![](https://blog.lc044.love/static/img/31f2f7d2bbcf7177dfee6058bd6388bf.image.webp)

    修改`openGauss-connector-jdbc/pom.xml`

    ```xml
      <modules>
        <module>pgjdbc</module>
        
        <module>pgjdbc-client</module> 
      </modules>
    ```

### 3.4 运行和调试代码

配置好上面的Maven依赖后，使用vscode打开`~/proj/openGauss-connector-jdbc/`文件夹，等待初始化一段时间。

正确加载完成后侧边栏最上面会显示有三个Java projects，三个maven项目

![image.png](https://blog.lc044.love/static/img/a8622cc0794e911b302284fca6ea4f20.image.webp)

此时打开`~/proj/opengauss-connector-jdbc/pgjdbc-client/PostgresTest.java`文件，main函数上面就会显示Run|Debug两个按钮

![](https://blog.lc044.love/static/img/efe4c08330a0d3aba5c14964f0a32877.image.webp)

点击`Run`就会直接运行main函数

![image.png](https://blog.lc044.love/static/img/38eb9ca2165fb1a29fe216a5756798c6.image.webp)

设置好断点，点击`Debug`即可进行调试（可以直接在pgjdbc下的驱动源码打断点）

![](https://blog.lc044.love/static/img/65d40e8898ada6fbf907ba9678fc9eb2.image.webp)

![](https://blog.lc044.love/static/img/08830e7de76d5b6770ec2ae9f4b02e30.image.webp)

## 4 参考资料

1. [豆包](https://www.doubao.com/chat/)
2. [ChatGPT](https://chatgpt.com/?model=auto)

openGauss-JDBC 调试方法

# 服务器网关切换后域名解析故障排查实录

## 一、故障现象：IP能通，域名却“失踪”了？

上周在维护测试环境时遇到一个诡异的网络问题：某服务器（主机A）出现**能ping通外网IP（如8.8.8.8），但无法ping通域名** 的异常现象。其他配置未变更，仅网关从`172.19.0.150`改为`172.19.0.179`。这种“能通IP不通域名”的症状，直觉指向DNS解析链路异常，但具体问题点需要一步步拆解。

![](https://blog.lc044.love/static/img/5520f3a31bc534f2ea6ce017b16b85e8.image.webp)

毫无疑问，这个问题肯定是 DNS 的问题，但是 DNS 哪出了问题，却非常诡异。

## 二、初步排查：定位DNS解析的“断链点”

### 0. **更换网关，DNS解析正常**

更换另一个网关，网络恢复正常了，说明是网关的问题，那么问题就来了，一般来说 DNS 解析是跟网关没有关系的，网关有问题的话应该 Ping 不通 IP，只更换网关恢复正常说明 DNS 配置又没问题，这就是诡异的点：**网关跟DNS到底有什么关系**。

**ChatGPT这么说：**

![](https://blog.lc044.love/static/img/fc0a0106b0be56d5195852f3e6e94b8d.image.webp)

### 1. **DNS配置验证：先看基础设置**

* **查看当前DNS服务器**

  ```bash
  cat /etc/resolv.conf  
  # 输出nameserver 8.8.8.8（已手动设置公共DNS）
  ```

  ✅ 确认主机已正确配置DNS服务器（8.8.8.8），但问题依旧存在，说明配置无错，需排查网络通路。

### 2. **路由与连通性测试：ping与traceroute的双重验证**

* **测试DNS服务器连通性**

  ```bash
  ping 8.8.8.8  # 通！说明ICMP协议可达
  traceroute 8.8.8.8  # 路由路径正常，无明显丢包
  ```

  ✅ 物理链路和基础路由正常，但域名解析仍失败，问题聚焦到**DNS协议层面**。

### 3. **DNS解析实测：用工具撕开“表象”**

* **手动触发解析请求**

  ```bash
  nslookup baidu.com  # 超时无响应
  dig baidu.com  # 同样卡住，无返回结果
  ```

  ❌ 直接证据：DNS查询未成功获取响应，说明请求可能未送达或被拦截。


## 三、深度诊断：抓包工具揭露“协议级封锁”

### 1. **tcpdump抓包：监控DNS流量细节**

执行抓包命令后再次发起解析请求：

```bash
sudo tcpdump -i enp2s0f0 port 53 -n
```

**关键输出分析**：

* **UDP请求**：主机向8.8.8.8发送了UDP 53端口的A记录查询（`A? baidu.com`），但**无任何响应包**。
* **TCP请求**：尝试使用TCP协议重新查询（`dig +tcp baidu.com`），抓包显示**三次握手成功，且DNS服务器返回了解析结果**（包含baidu.com的IP地址）。

🔍 **核心结论**：

* UDP 53端口的DNS请求被网关或链路设备拦截，导致解析失败；
* TCP 53端口未受限制，说明问题出在**协议级过滤**（常见于防火墙对UDP DNS的封锁）。

## 四、网关特性分析：iKuai路由器的“特殊规则”

由于故障网关为**iKuai（爱快）路由器**，结合其功能特性进一步排查：

### 1. **防火墙策略检查**

登录iKuai管理后台（`http://172.19.0.179`），进入 **安全设置 &gt; 防火墙规则**，发现一条针对**UDP协议、目标端口53**的出站拦截规则。该规则默认阻断内网主机通过UDP协议访问外部DNS服务器，以防止DNS放大攻击，但误判导致正常解析请求被拦截。

### 2. **规则调整与验证**

* **修改规则**：将拦截动作改为“允许”，并指定目标端口为53（UDP）。
* **重启网络服务**：确保规则生效。
* **复测解析**：

  ```bash
  dig baidu.com  # 秒级返回解析结果，问题解决！
  ```

## 五、技术总结：从现象到本质的排查逻辑

### 1. **故障链还原**

`网关切换` → `触发UDP 53端口拦截规则` → `DNS查询请求（UDP）无法回包` → `域名解析失败`。
关键点：**UDP与TCP协议的差异化处理**——多数防火墙默认允许TCP 80/443等常用端口，但可能对UDP协议实施更严格的策略。

### 2. **通用排查方法论**

* **分层验证**：按“物理层→网络层→传输层→应用层”顺序排查，先确认IP连通性，再聚焦协议细节。
* **工具优先**：善用`ping/traceroute/dig/tcpdump`等工具，通过抓包获取原始流量数据，避免主观臆断。
* **设备特性适配**：不同厂商的网络设备（如iKuai、华为、Cisco）可能有默认安全策略，需结合官方文档分析规则逻辑。

## 六、延伸思考：DNS解析的“攻防博弈”

当前网络环境中，DNS常成为安全策略的“敏感点”：

* **运营商层面**：部分ISP会拦截非官方DNS请求，强制使用自有解析服务；
* **企业防火墙**：为防范数据泄露，可能限制UDP 53端口，仅允许通过HTTP(S)/TLS加密通道传输DNS数据（如DoH/DoT）。

**应对建议**：

* 若遇UDP封锁，可临时使用TCP解析（`dig +tcp`）或部署DNS加密工具（如cloudflared）；
* 长期方案需与网络管理员协同，在安全策略与业务需求间找到平衡点。

## 结语

这次故障排查看似围绕“DNS解析”，实则涉及网络协议特性、设备策略配置、安全规则适配等多个技术维度。作为运维人员，保持“用数据说话”的习惯（如抓包分析），比依赖经验判断更能快速定位问题。下次遇到类似“能通IP不通服务”的场景，不妨从协议层开始抽丝剥茧，往往能柳暗花明。

服务器网关切换后域名解析故障排查实录

👨🏻‍💻这是一个充满知识💬的链接，快点进来看看你的好友给你分享了什么干货吧❣️