谈OracleMFT文件传输性能调整(9.3)

对于Oracle MFT在前面已经专门有博客文章介绍过，MFT是Oracle本身应用于端到端大文件传输的一个解决方案，支持文件传输加解密，多线程并行传输，支持断点和重试，支持端到端文件传输过程的监控等，底层仍然是基于JMS消息中间件进行。

在对MFT文件传输进行配置和部署后，最近发现一个新问题就是，MFT文件传输本身出现对源目录不进行监听的问题，往往只有重新部署MFT后才能够重传，而且有时候重新部署MFT传输还不行，需要对整个MFT Server服务器进行重启才可以。

在对MFT日志的排查中，重点发现如下一些问题点：

第一是反馈说JMS消息获取的时候块大小超过了10M，具体不清楚为何会出现这种情况，暂时只有考虑将JMS消息发送的块接收大小修改为20M。

对于cannot polling file or pick up file的问题，从Oracle Support网站知识库，可以找到一个类似的问题，里面的描述内容为：

ESS Jobs In MFT Are Stuck In Active State (文档 ID 2369720.1) ， 在这篇文章里面有提到，ESS jobs in MFT are stuck in Active state , 和我们遇到的情况类似，涉及到补丁程序，Patch 26798713 ,因为我们还是先对所有的MFT Server服务器增加了该补丁。在12.2.1.3版本上可以打该补丁。

做了以上处理后，感觉还是有问题，最后发现我们认为MFT文件没有传输，而实际情况是由于MFT Server抓取源端服务器的文件流，由于网速太慢导致耗时很长，实际上整个MFT并没有卡死而只是处于了等待状态。

其次，我们查找Oracle官方网站，找到调节MFT Server性能一个关键文章说明：

https://docs.oracle.com/middleware/1213/corER/mft.htER99974

https://docs.oracle.com/middleware/1213/adapters/develop-soa-adapters/GUID-D9F90C07-D09D-4AA5-8DB1-99AA993B43FB.htm#TKADP9516

这两篇重要文章，主要说明了：

If MFT is not able to pick up files even after polling frequency is expired, you need to tune the remote FTP/SFTP/FILE type sources. MFT uses the JCA Adapters underneath for all of these source types. Refer to the SOA adapter recommendations listed under "Oracle JCA Adapter Framework Performance and Tuning" in Understanding Technology Adapters.

即如果你发现过了轮询的时间间隔，对于MFT仍然不去获取源端目录文件的时候，你就需要对远程的FTP/SFTP/FILE等类型的源适配进行调整。这里面涉及到ThreadCount和SingleThreaded两个重要参数：

ThreadCount（默认值是-1）

问题说明：A high priority endpoint is downloading files slowly because of insufficient threads in the global pool. 全局线程池没有可用的线程来进行处理。

SingleThreaded（是否单线程，默认值False）

问题说明：In rare cases, you may not want to use global threads or allocate a separate thread pool for a low-priority end point. 少数情况，你可能并不想使用全局线程池或分配一个独立线程池给低优先级传输。

解决建议：将该值设置为true，启用单线程传输。

我们再来看下对这两个值的详细说明：

The inbound design for File and FTP Adapters is based on a producer/consumer model where each deployment of a composite application (with inbound File/Ftp Adapter service) results in the creation of a single poller thread and an optional number of processor threads.

对于FTP适配器其的Inbound设计是基于生产/消费者模型，每个复合应用的每一次部署都会创建一个独立的轮询线程和可选数量的处理器线程。

The following steps highlight the default threading behavior of File and Ftp Adapters:

The poller thread periodically scans for files in the input directory based on a configured polling frequency。轮询线程基于配置的轮询频率对源端目录进行轮询。

For each new file that the poller detects in the inbound directory, the poller enqueues information such as file name, file directory, modified time, and file size into an internal system-wide in-memory queue.

对于轮询器在入站目录中检测到的每个新文件，轮询器将文件名、文件目录、修改时间和文件大小等信息放入系统范围内的内存队列中。

A global pool of processor threads (four in number) wait to process from this in-memory queue.

一个处理器线程的全局池(数量为4个)等待从这个内存队列进行处理。

The items in the in-memory queue are dequeued and processed by these threads; processing includes translation of file content into XML and publishing to SOA infrastructure, followed by post-processing, for example, deletion/archival of the file.

内存队列中的项由这些线程去队列和处理;处理包括将文件内容转换为XML并发布到SOA基础设施，然后进行后处理，例如删除/归档文件。

This is the default threading behavior for both the File and FTP Adapters.

上面是默认的处理方式。

However, you can change this behavior by configuring either a ThreadCount or SingleThreadModel property in the inbound jca configuration file. 你可以修改这两个参数来改变默认处理方式。

为ThreadCount指定一个有限的值会导致特定的文件/FTP适配器入站服务变为分区线程模型，其中每个服务接收自己的内存队列和自己的一组专用处理器线程。

Because the processor threads themselves come from the SOA Work manager, they consume memory/CPU time and hence this property must be configured carefully. Recommendation is to start with a value of 2 and slowly increase the speed as required; the system, however, sets the upper bound for this configuration of ThreadCount at 40.

因为处理器线程本身来自SOA工作管理器，它们消耗内存/CPU时间，因此必须仔细配置此属性。建议从2开始，按要求慢慢增加速度;然而，系统将这个ThreadCount配置的上限设置为40。

Setting SingleThreadModel as true in the JCA configuration results in the poller assuming the role of the processor. In other words, the poller scans the inbound directory and processes the files in the same thread (one after another).

在JCA配置中将SingleThreadModel设置为true会导致轮询器承担处理器的角色。换句话说，轮询器扫描入站目录并处理同一线程中的文件(一个接一个)。即获取文件和处理文件到目标端是同一个线程。

This parameter is particularly useful if you want to throttle the system. You can also use this parameter if you want to process files in a specific order (for example, process files in descending order of last modified time)

如果您想控制系统，这个参数特别有用。如果希望按照特定的顺序处理文件(例如，按照上次修改时间的降序排列的进程文件)，还可以使用此参数。

根据以上描述可以很清楚的看到，如果有一个部署的MFT配置，在源端同时存储大量的文件的时候，如果MFT配置本身有采用的默认值，那么全局线程池的所有线程都会被用来处理该MFT源端目录文件。这直接将导致部署的其它MFT配置根本无法从线程池获取到可用线程来进行处理的问题。