Comment 6 for bug 1032633
Revision history for this message
| Adam Young (ayoung) wrote Re: [Bug 1032633] Re: Keystone's token table grows unconditionally when using SQL backend. | #6 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
On 04/05/2014 01:43 PM, Andrew Mann wrote:
> A CLI command is an interesting stopgap, but on a heavily utilized
> OpenStack installation with automated tools operating against OpenStack,
> this has a high manual maintenance cost. Surely there is some better
> default that lies in the middle ground between keeping tokens for ever
> and ever and requiring a manual removal of tokens?
>
> As a reference point, I wasn't even aware this was an issue, until one
> of our test deployments of grizzly using a limited IO system started
> acting horribly (30 second response times). After tracing the problem
> from nova to keystone to mysql, I found a 442,000 row token table with
>> 440,000 expired tokens. I went and checked our havana test on a
> somewhat beefier system and found > 1M rows.
>
> This issue is a timebomb for any production OS install.
>
CRON the CLI job. There is no reason to try and integrate a scheduler
into Keystone.