症状:

所有新的构建扫描和工件扫描都能正常工作。但是，旧的构建扫描不能工作。

特别是在这两个队列中indexExistingContent负责重新索引存储库所触发的现有工件的索引。

这些案件背后的原因可能是什么?

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

故障排除步骤:

Step-01:

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

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

如果服务仍然在这个端口上监听，我们需要清除进程并重新启动Xray服务。这可能会帮助我们清除卡住的信息。

Step-02:

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

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

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

如果最近没有调用活动扫描，但表显示了表示相关存储库和构建引用的条目，则表明存在问题。我们需要清除卡住的条目，然后针对现有内容调用新的扫描。在执行删除这些陈旧条目之前，请确保服务已停止(x射线)，并且没有正在进行的活动扫描。DELETE from event_states where art_path LIKE '%REPO_NAME%' and 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协商后并在非业务时间执行这种清理任务。