2024年马上就结束了，终于在结束前解决了困扰许久的一个问题：kettle的Pentaho Repository 资源库异常卡顿。所以在此也梳理、记录下2024年的最后一个大问题。
项目场景
工作中一个重要内容是数据中心项目，也就必不可少的要用到ETL技术，项目选用的是kettle工具来实现数据中心的ETL需求。
kettle资源库是类似于TFS、GIT等代码管理工具；不同的是kettle资源库是用来管理kettle的ktr，kjb文件。具备内容管理、版本管理、依赖完整性检查等用途。
kettle资源库
kettle的资源库又分为以下3种
|-----------------------------|----------------------------------------------------------|------------|
| 资源库类型 | 描述 | 适用性 |
| Database Repository（数据库资源库） | kettle的资源文件存储到数据库中 | 适合团队协同开发管理 |
| File Repository（文件资源库） | kettle的资源文件存储到本地 | 适合个人本地练习 |
| Pentaho Repository | 需要部署kettle的服务端，kettle的资源文件存储在服务端。具备内容管理、版本管理、依赖完整性检查等用途。 | 适合团队协同开发管理 |
所负责的项目使用的是Pentaho Repository类型资源库；其实有看到网上很多朋友对Pentaho Repository的评价不高，很多文章都推荐使用Database Repository类型资源库。起初在kettle8.3及之前的版本，Pentaho Repository类型资源库确实体验感不好，非常卡顿！但是从9.2版本开始，Pentaho Repository类型资源库的体验感其实非常不错了，使用流畅的基础上再加上强大的管理功能让我们坚定的选择了Pentaho Repository类型资源库。
但是此次的问题是我负责的项目上使用的9.4版本的Pentaho Repository类型资源库使用起来莫名其妙卡顿，卡的佛系的人都要摔鼠标的那种卡。具体体现举例如下：
1、kettle客户端在连接服务端的Pentaho Repository资源库时，需要几十秒甚至几分钟才能连上；
2、在打开kettle的转换或者作业时，有时卡顿，有时不卡顿；
3、在保存kettle的转换或者作业时，每次都卡顿；
4、导入一个5M大小的资源库，甚至需要10分钟才能完成导入；
........
这些问题，让小伙伴们苦不堪言。实在无奈，我让大家先临时使用本地资源库进行ETL开发，但几百甚至上千个ETL转换作业管理起来实在是难受。在技术总监看了两次表达了"欸，其他项目都是没问题的，怎么你这不行..."的观点后，我开始了自研之路 ~
问题排查
先说下问题解决前的Pentaho Repository资源库情况。
|------------------|----------------------------|
| 项目 | 描述 |
| Pentaho Server版本 | Pentaho Server 9.4.0.0-343 |
| 操作系统 | Anolis OS 8.9（龙蜥） |
| 操作系统内核 | rhel |
| 内存 | 32G |
| CPU | Intel至强金牌，8核 |
| 平台 | 华为云 |
| kettle客户端版本 | pdi-ce-9.3.0.0-428 |
对于这种卡顿问题，我也梳理了下几个方向开始排查：
|----|---------------|
| 序号 | 方向 |
| 1 | 客户端与服务端的版本不一致 |
| 2 | JVM内存太小 |
| 3 | 磁盘读写速度太慢 |
| 4 | IO速度太慢 |
| 5 | 网络问题，传输速度太慢 |
| 6 | 其他 |
下面就开始了逐步排查：
1、客户端与服务端的版本不一致
重新下载了9.4的kettle客户端，客户端配置与资源库用户配置完成后，第一步连接资源库就还是老样子开始卡顿；然后开始测试ETL开发、保存转换、导入资源库，均和之前的效果一致，卡顿的不得了。所以这个方向不对，解决失败。
2、JVM内存太小
Pentaho Server是用tomcat发布的，所以会从JVM内存这个方向上考虑。但和一个tomcat颇有研究的同事聊完后，了解了tomcat会自动调配内存。而且其他项目的服务在发布时也从未调整过初始内存大小。所以这个方向不对，解决失败。
3、磁盘读写速度太慢
使用dd命令测试磁盘读写速度，测试发现磁盘读写速度每秒300多M，读写速度正常。所以这个方向不对，解决失败。
bash
[root@ETLServer home]# dd if=/dev/zero of=/home/testfile bs=1M count=1024 conv=fdatasync,notrunc status=progress
记录了1024+0 的读入
记录了1024+0 的写出
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.84533 s, 377 MB/s4、 IO速度太慢
因为在打开资源库文件和保存时也会涉及到IO，所以怀疑磁盘与CPU及内存之间的通信接口的性能是不是存在问题。于是使用iostat命令测试服务器的IO性能，发现其实服务器首先是没什么IO，其次是仅有的IO体现出的性能并没有问题。因为从iostat的输出上，等待是小于平均每次设备IO操作的服务时间的。所以这个方向不对，解决失败。
ETL服务器IO性能
我曾经也见过一台数据库服务器IO性能极差，可以分享给大家做对比：
IO性能极差的服务器iostat输出
5、网络问题
在上述基本资源配置排查完后，开始排查网络。其实我潜意识里不认为网络有问题，因为很多数据库服务器和应用服务器都同属于一个网段，路由追踪发现其实都是只跳了两个路由。但实在是没招了，所以用wireshark在服务端和客户端同时抓包开始分析。
这次还真发现了一个问题，就是每次保存kettle转换时，总会固定有个seq位1的包延迟。但是对比发包和收包发现网络传输速度没有问题，是服务端那边响应太慢。
所以网络问题这个方向也不对，解决失败。
6、其他
经过上面的排查，感觉已经黔驴技穷了，实在不知道还能有什么方向去思考。于是无聊期间在自己本地的VMware虚拟机上部署了台centos7，然后发布了Pentaho Server资源库服务。用客户端连接以后，发现速度很快，体验感很好。这个时候突然想起了高中生物书上的对比实验法，既然发布的程序是一样的，IO、磁盘、网络、内存都没问题；那么有问题的只能是---------华为云平台或者国产龙蜥8.9！
于是我找到负责服务器的老师，和他讨论此事。服务器老师说，除了华为云平台还可以从VMware上给我划一台服务器，但是国产龙蜥不能换，因为会有检查，但龙蜥的操作系统还是可以给我选择红帽的内核。我咬咬牙点头，那就先换到VMware上试试。
很快，在VMware上给划了台龙蜥8.9。我快速发布完Pentaho Server，然后我非常紧张的去打开Pentaho Server的web配置用户，在打开web的一瞬间，我觉得这次成了！因为以前打开web都非常慢，这次非常快！然后客户端连到Pentaho Server资源库，开始测试打开、修改、保存转换，导入导出资源库；一切都非常的流畅！
这个时候已经非常激动了，但还是决定苟一会儿。在多台设备上都测试没有问题后，终于长长的呼出一口气~ 终于解决了！
问题总结
但要说为什么Pentaho Server在华为云上不行，我不知道。我只是通过不断的测试排查，最终定位到了云平台上。当排除了所有的可能选项后，那个看似不可能的选项也是正确的。
至于华为云究竟哪里存在问题，后续研究明白了会再来和大家汇报分享。
提前祝大家2025新年快乐！🎇🎇🎇