[ English | 日本語 | Deutsch | Indonesia ]
当事情运行缓慢时该怎么办¶
当您从各种服务获得缓慢的响应时，很难知道从哪里开始查找。首先要检查的是缓慢的程度：是特定于单个服务，还是在不同服务之间有所不同？如果您的问题仅限于特定服务，则可以通过重新启动该服务来暂时解决，但这通常只是解决症状而不是实际问题。
这是来自经验丰富的操作员的一些关于可能导致缓慢的常见问题的集合。但是，它并非旨在成为一个详尽的列表。
OpenStack Identity 服务¶
如果 OpenStack Identity 服务响应缓慢，可能是因为 token 表变得很大。可以通过运行 keystone-manage token_flush 命令来解决此问题。
此外，对于 Identity 相关问题，请参考 SQL 后端 中的提示。
OpenStack Image 服务¶
OpenStack Image 服务可能会因与 Identity 服务相关的问题而变慢，但如果使用的后端存储的连接速度慢或存在其他问题，Image 服务本身也可能会变慢。例如，您的后端 NFS 服务器可能已经停止运行。
OpenStack Block Storage 服务¶
OpenStack Block Storage 服务类似于 Image 服务，因此首先检查与 Identity 相关的服务和后端存储。此外，Block Storage 和 Image 服务都依赖于 AMQP 和 SQL 功能，因此在调试时请考虑这些因素。
OpenStack Compute 服务¶
与 OpenStack Compute 相关的服务通常相当快，并且依赖于几个后端服务：Identity（用于身份验证和授权）和 AMQP（用于互操作性）。与服务相关的任何缓慢通常与其中一个有关。此外，与所有其他服务一样，SQL 被广泛使用。
OpenStack Networking 服务¶
OpenStack Networking 服务中的缓慢可能是由其依赖的服务引起的，但也可能与物理或虚拟网络有关。例如：不存在或未正确绑定到接口的网络命名空间；已挂起或未运行的 DHCP 服务器；物理电缆被断开；交换机配置不正确。在调试 Networking 服务问题时，首先验证所有物理网络功能（交换机配置、物理电缆等）。在验证物理网络后，检查所有 Networking 服务是否正在运行（neutron-server、neutron-dhcp-agent 等），然后检查 AMQP 和 SQL 后端。
AMQP 代理¶
无论您使用哪个 AMQP 代理，例如 RabbitMQ，都存在一些常见问题，这些问题不仅会降低操作速度，还会导致实际问题。有时，为服务排队的消息会停留在队列中而未被消费。这可能是由于死掉或停滞的服务造成的，通常可以通过重新启动 AMQP 相关服务或 OpenStack 服务来解决。
SQL 后端¶
无论您使用 SQLite 还是 RDBMS（例如 MySQL），SQL 互操作性对于正常运行的 OpenStack 环境至关重要。使用文件作为后端时，大或碎片化的 SQLite 文件可能会导致缓慢。锁定的或长时间运行的查询可能会导致大多数 RDBMS 服务的延迟。在这种情况下，不要立即终止查询，而是查看它，看看它是否是某个挂起的问题，或者只是需要自行完成的长时间运行的问题。RDBMS 的管理不在本文档的范围内，但应注意的是，正常运行的 RDBMS 对于大多数 OpenStack 服务至关重要。
