症状:

所有新的构建扫描和工件扫描都按预期工作。但是，旧的构建扫描不起作用。

特别是在两个队列中indexExistingContent负责通过索引存储库触发的现有构件的索引。

这些案例背后的原因是什么?

• Artifactory和Xray之间的通信可能由于某种原因丢失，这导致请求卡在索引队列中。
• 如果资源不足以2022世界杯阿根廷预选赛赛程让x射线服务器处理大量并发扫描请求。

故障排除步骤:

Step-01:

由于RabbitMQ负责索引任务，因此有必要验证RabbitMQ数据库服务器的状态，以了解问题的根本原因。

检查RabbitMQ的消息队列，特别是indexExistingContent尽管Artifactory和Xray之间没有活动的事务，但仍然持有更多的消息。如果消息数更多，可能是RabbitMQ服务器在处理请求时卡住了。对Xray服务器执行停止操作，并检查RabbitMQ是否仍在运行。netstat -tulpn将显示RabbitMQ是否仍在监听端口5672。

如果该服务仍在此端口上侦听，则需要清除该进程并重新启动Xray服务。这可能有助于我们清除被卡住的信息。

Step-02:

如果上述方法不能改善行为，我们需要检查是否有过时的条目仍然阻塞相应的数据库表。

登录PostgreSQL数据库，验证event_states表格SELECT * from event_states;

要查找特定于特定存储库路径的条目，可以使用以下命令。SELECT * from event_states where art_path LIKE '';

如果最近没有调用活动扫描，但表显示表示相关存储库和构建引用的项，则表明存在问题。我们需要清除卡住的条目，然后针对现有内容调用新的扫描。在执行删除这些过时条目之前，请确保服务已停止(x射线)并且没有活动扫描正在进行中。从event_states中删除art_path LIKE '%REPO_NAME%'和action = 'created';

重要提示:
尽管我们执行这个查询是为了清除陈旧的进程，但考虑到执行查询可能需要时间和资源利用率，建议在预定的维护窗口[或]以外的工作时间执行这个查询。

Step-03:

如果尽管清除了相关构建的过时条目，问题仍然存在，我们需要检查DB是否有任何导致DB性能下降的死元组。您可以使用以下命令来识别失效元组(如果有的话)。
选择schemaname,
relname,
n_tup_ins,
n_tup_upd,
n_tup_del,
n_live_tup,
n_dead_tup,
last_vacuum,
last_autovacuum,
last_analyze,
last_autoanalyze
从pg_stat_all_tables
WHERE schemaname = 'public order by n_dead_tup desc ';

如果存在死元组，则对数据库执行真空任务会有所帮助。始终建议在咨询dba之后和非工作时间执行此类真空任务。