类别

版本

故障排除

本文概述了RapidMiner Server的常见问题。

切换Java分布

在切换Java发行版时,例如从Oracle JDK到OpenJDK,需要清理JBoss的临时文件。为此,请确保RapidMiner服务器已关闭。操作完成后,进入RapidMiner Server安装目录,删除<安装目录> /独立/ tmp文件夹或其内容。

增加ActiveMQ工作目录

如果您使用的是我们的嵌入式ActiveMQ代理,这是默认设置,那么下面的操作就适用了。

ActiveMQ存储数据和日志文件(以. log的工作目录中的文件扩展名)RapidMiner Server/AI Hub主目录rapidminer-server-home /数据/代理/.ActiveMQ在内部使用它们来一致地管理消息。一个ActiveMQ实例可以保存对多个日志文件的引用,并且只在它们不再使用时才会删除它们。如果在ActiveMQ之间来回发送大量消息,例如频繁提交作业或设置多个调度,工作目录就会增大。

如果手动删除日志文件,那么可能会丢失像挂起的作业这样的消息。我们建议您不删除日志文件.相反,我们建议你定期检查目录的大小,它应该总是低于50GB,因为ActiveMQ有一个默认的50GB的工作目录大小限制,之后将停止正常工作,例如,不再提交作业,您的作业将不会执行。

解决这种情况主要有两种方法:

  1. 让ActiveMQ的清理机制为你处理它或者
  2. 让RapidMiner AI Hub删除所有消息每一个应用程序开始。

使用ActiveMQ的清理机制

为了确保ActiveMQ将自动清理大多数日志文件,您需要确保作业不再提交到任何队列,并且任何队列上都没有挂起的作业,例如,通过清除RapidMiner AI Hub队列页面上的队列并暂停任何活动调度。如果是这种情况,那么内部清理机制将自动删除未使用的日志文件。

您还可以通过调整属性来更改每个日志文件的默认大小broker.activemq.embeddedBroker.journalMaxFileLength = 256execution.properties设置文件的最大大小,单位为MB128MB, ActiveMQ将自动分配和占用启动。

默认情况下,ActiveMQ将每5秒检查一次它是否可以清除未使用的日志文件。如果这个间隔对于你的设置来说太高了,你可以通过调整属性将其降低到1秒broker.activemq.embeddedBroker.cleanupInterval = 1000(以毫秒为单位)并观察日志文件现在是否被正确清理。

在启动时清除代理的工作目录

请注意,以下操作是破坏性操作,所有提交的和挂起的作业(所有挂起的消息)都将被丢弃,因此请确保所有调度在之前已停止,并且队列中不再有提交的作业。

RapidMiner AI Hub嵌入式代理提供了在每次应用程序启动时自动清除代理工作目录的方法。如果您知道在重新启动后不需要保留挂起的作业,例如,当它们通过调度自动添加时,这是很有用的。

你应该只有在真正有必要时才使用启动即擦机制或者如果部署的磁盘空间资源有限。

确保遵循以下步骤:

  1. 确保没有重要的挂起作业或尚未完成的作业队列。您可能希望暂停调度页面上的所有调度,等待所有挂起的作业执行。
  2. 关闭RapidMiner AI Hub。
  3. 前往execution.propertiesrapidminer-server-home /配置/文件夹并添加属性broker.activemq.embeddedBroker.wipeWorkDir = true启用擦除功能每一个重启
  4. 启动RapidMiner AI Hub。
  5. 恢复在重新启动AI Hub之前暂停的任何计划。
  6. 删除添加的属性execution.properties或者设置为如果你不想每次重启都擦。

下面的步骤描述了如何从ActiveMQ中确定仍然在积极使用的日志文件,并且仅针对高级用户。使用ActiveMQ的自动清理和/或wipe-on-start功能上面描述的是更安全的方法,应该优先考虑。

您可以通过设置该属性深入了解ActiveMQ的内部结构log.level.org.apache.activemq.store.kahadb =跟踪execution.properties文件。日志现在将包含关于哪个ActiveMQ队列/主题仍在引用哪个日志文件的信息,以及为什么它没有自动清理它们。您现在可以决定手动删除哪个日志文件。更多信息可以在ActiveMQ官方文章中找到“为什么清理后KahaDB日志文件仍然存在”

Zip Dump不包含文件夹的全部内容

远程存储库的zip转储机制很可能会意外中止包含大文件的文件夹,并返回一个不完整的zip文件。这是因为底层JBoss默认配置了300秒的事务超时。为了克服这个问题,你需要增加事务超时值:

  1. 打开文件standalone.xml.它位于配置/RapidMiner服务器主目录
  2. 定位标签< coordinator-environment缺省超时= " 300 " / >
  3. 增加了默认超时取值为较大的数字,例如从300到3000秒。

如果zip转储机制仍然意外中止,请尝试将超时时间增加到更高的数字。

当不再需要zip转储机制时,我们建议再次将事务超时值设置为较低的值,以避免在其他地方产生不必要的副作用。