kettle经验篇：Pentaho Repository 类型资源库卡顿问题

        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，读写速度正常。所以这个方向不对，解决失败。

[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/s

4、 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新年快乐！🎇🎇🎇