谈MFT性能问题(8.15)

对于Oracle MFT的传输性能问题，我实际上博客前面文章上都谈到过，今年主要还是想谈下问题跟踪思路。

对于近期我们在做MFT传输通道配置的时候发现了传输性能问题，一个是传输很慢，一个是传输管道很容易被卡死不动，持续很长时间都不再进行传输。而出现这种问题的时候我们究竟应该采用一种什么样的问题分析和解决思路才是关键。

首先对于一个MFT文件传输，我们在前期也尝试了多种配置，最后统一采用了单线程传输，每次默认拉取两个文件的传输配置方式，在前面的MFT传输配置和实施中该配置基本没有出现问题，也很稳定。采用单线程传输最大的好处就是资源之间相互隔离互不影响，不容易出现相互之间的抢占情况。虽然速率上可能比多线程慢一点，但是完全可以接受。

在传输配置出现性能问题后，首先我们应该看下对于其他的传输是否都是这个配置，其他的传输是否有问题？如果其他传输都没有问题，那么说明我们先不应该马上去做参数配置的调整，而应该先考虑其他方面的影响因素。对于一个MFT传输而言，从边界划分的角度我们很容易看到的就是包括了：

1. 源端SFTP服务器的配置，操作系统类型，SFTP的端口，源端SFTP默认的配置。

2. 传输网络本身性能如何

3. MFT Server本身的传输模板参数配置

在出现这个问题后我们进行检查，发现直接在MFT Server上进行Get文件操作速度也相当慢，那么这很可能就是网络本身的性能问题。然后我们去排查网络性能，最终发现网络性能并没有问题，而是源端采用了的Windows Server来搭建的SFTP，而将该SFTP迁移到Linux Server后，再进行Get发现速率上已经没有问题。

在速率上没有问题后，我们重新对MFT传输配置模板进行部署，在部署完成后仍然会发现传输被卡死的情况。在出现这种情况后，我们开始不断的调整MFT参数配置，其中包括了如下：

1. 由单线程传输修改配置为多线程传输

2. 修改多线程的线程数

3. 修改每次拉取文件的最大引发文件数量

我们对这三个参数做了多次修改，但是发现最终问题仍然没有解决掉。然后我们又开始考虑是否是SFTP的端口配置有问题，是否是集群有问题等等。

但是我们忽视了一个关键点，即在MFT上已经配置了很多的传输，而其它已经配置的传输通道并没有出现问题，如果是端口或集群问题那么应该影响到所有的通道才对。我们去不断调整MFT传输参数配置本身就不合理，而更多的应该考虑是否是源端SFTP Server配置或网络的问题导致。

但是这仅仅是我们的假设，这种假设会很多，如果按照假设一个个去排查往往会相当的耗费时间，而这个时候的关键在于当出现异常或问题的时候，即使MFT管控台上面没有相应的异常提示，但是也会有具体的服务器日志文件，应该有相关的异常记录。

在出现异常或问题的时候，首先就应该排除服务器或异常日志，这个是最基础和最原则的思路。

在排查日志的时候，我们发现一个异常日志

Could not publish file as endpoint has been de-activated.

具体在oracle support网站的说法是

The below exception is being thrown when the source in the transfer is an SFTP server and files are not transferred to target。

Referred the document (Doc ID 2083811.1) . As per solution provided , the ESS libraries are installed for the mft instance. Still the issue occured. 

If the mft server is restarted then all the files will be transferred and files get deleted gfrom ftp server(if archive/delete is selected). This issue does not occur regularly. 

该问题对应bug 29526370，而oracle提供了补丁，在打完补丁后发现卡死的问题不再出现。但是传输速度和性能问题仍然存在，即差不多30分钟才能够传输2个G左右的文件。但是我们直接get的时候速率在30M左右。

即问题仍然没有解决，采用单线程传输，传输速率差不多在1M/S，传输仍然很慢。即现在的问题只是慢的问题，而不再存在传输卡死的问题。

在get速度正常情况下，MFT传输配置也采用的历史验证过的参数配置，但是传输仍然很慢。那么更好的思路还是应该去检查源端SFTP服务器本身的配置情况。而最可能的仍然是存在几个点。

1. 源端SFTP服务器本身本身用的linux本地盘，而是采用的windows磁盘做的镜像映射

2. 源端SFTP服务器本身配置和性能如何？是否存在性能本身不行，同时还在SFTP上进行打包的情况

3. 源端的SFTP采用的端口是否存在问题？

3. 源端的SFTP的参数配置是否有问题，是否存在相关的限速配置等。

个人理解这些都是我们需要进一步排查的关键点，而不是马上去调整MFT传输配置参数。毕竟这组配置参数在前面历史文件传输中已经得到过验证，而且实际上并没有问题。

对于Oracle MFT我们很早就发现一个问题，虽然MFT是一个端到端的文件传输工具，但是实际上MFT管控台能够看到的文件传输实例已经是文件已经被拉取到MFT Server上后才会启动文件传输实例，也就是说在从源端拉文件到MFT Server上这段过程完全是黑盒同时也没法监控。这也导致了我们排查MFT问题相当困难，只能够是提出各种假设，然后再逐一去验证假设是否成立和排除错误假设。