Hi,

we had this a couple of years ago in our Ocata cloud, in our case memcached was not configured correctly. Since you might be experiencing another memcached issue according to your other thread [1] it could be worth double-checking your memcache configuration.

Regards, Eugen

[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017196...

Zitat von melanie witt melwittt@gmail.com:

On 9/10/20 21:15, Tony Liu wrote:

...

Hi,

I built a Ussuri cluster with 3 controllers and 5 compute nodes. OpenStack CLI ran pretty fast at the beginning, but gets slower over time along with increased workloads. Right now, it takes about 30s to list 10 VMs. The CPU, memory and disk usage are on those 3 controllers are all in the range. I understand there are many API calls happening behind CLI. I'd like to figure out how this 30s is consumed, which call is the killer. Any guidance or hint would be helpful.

To see the individual calls made by OSC and troubleshoot the reason for the slowness, you can use the --debug option:

$ openstack --debug server list

Besides that, there is something that I know of that can be slow: the flavor and image name lookup. This happens if you have a Large Number of flavors and/or images. There are a couple of options you can use to make this faster:

$ openstack server list --name-lookup-one-by-one

This will make OSC lookup flavors and images only once per unique flavor/image in the list and uses the cached value for subsequent appearances in the list [1]. I think this should have been made the default behavior when it was introduced but it was nacked and accepted only as opt-in.

The other option skips name lookup altogether and shows UUIDs only instead of names [2]:

$ openstack server list --no-name-lookup

Hope this helps, -melanie

[1] https://docs.openstack.org/python-openstackclient/ussuri/cli/command-objects... [2] https://docs.openstack.org/python-openstackclient/ussuri/cli/command-objects...