Created attachment 1055393 [details] Backported patch for RHEL OSP5 Description of problem: One of our customers has a performance problem with Keystone. The problem is that they face a lot of Keystone requests per second (using Swift), and Keystone runs into timeouts sometimes because it can't keep up with the amount of requests. The problem is that there is only a single Keystone process running. This was fixed shotly after the Icehouse release: https://review.openstack.org/#/c/42967/ I created a diff for RHEL6/OSP5 based on that commit, that can be applied directly on the system (patch attached). Version-Release number of selected component (if applicable): RHEL6, OSP5. How reproducible: Always. Steps to Reproduce: 1. /etc/init.d/openstack-keystone start Actual results: Single keystone process. Expected results: Multiple keystone processes, for example: $ pstree -c keystone keystone-all─┬─keystone-all ├─keystone-all ├─keystone-all ├─keystone-all ├─keystone-all └─keystone-all Additional info: my question is how to proceed in this case. The customer has a premium support level. - is there a chance to backport this patch to RHEL OSP5 and publish updated RPMS? - or shall we deliver the patch directly to the customer to fix this issue asap?
needinfo? alan, what is the policy on backporting this far?
I just verifed patch for this issue is part of the build openstack-keystone-2014.1.5-2.el6ost Looking at commit message for patch that brings in this functionality it notes it adds 2 config options public_workers=N and admin_workers=N This patch adds two configuration options, public_workers=N and admin_workers=N, that determine the number of keystone-all processes that handle requests for keystone's public and admin WSGI applications respectively.
*** Bug 1261543 has been marked as a duplicate of this bug. ***
This indeed requires setting the public_workers and admin_workers config options to something > 1 to see multiple processes.
This was resolved in the current release of openstack-keystone for RHEL OSP 5