|
Can anyone think of a reason dbstop may take a long time to run, with high CPU? Is it likely to be the final CHECKPOINT, and if so, why? All the properties and options look normal, but (alas) I don't have realtime access to the servers. |
|
Shutting down also disconnects & rolls back all transactions. If you have a very large uncommitted transaction, it can take a long time to roll it back. I would normally expect checkpoints to be IO intensive rather than CPU intensive. If you still suspect the checkpoint, are they using an SSD and an enormous cache? These seem unlikely since they are using 5.x software... In any case, IO to SSD is fast enough that you would probably see lots of CPU and you'd need an enormous (and very dirty) cache to make the checkpoint take a long time. You could try to do a manual checkpoint before shutting down and seeing if you observe the same high-cpu behaviour. I think the rollback is more likely. 1
> large uncommitted transaction Yes, of course, excellent! I am guessing that a large SELECT PROPERTY ( 'RollbackLogPages' ) would predict a slow dbstop, correct? (yes, normally that's a DB_PROPERTY thing, but not in 5.5 :)
(01 Feb '18, 12:53)
Breck Carter
Replies hidden
1
Inevitable suggestion: I'd recommend to test with the latest 5.5.05 EBF, 5.5.04 is so old:)
(01 Feb '18, 13:56)
Volker Barth
|
Wow, where is that "ancient" tag? :)
is it possible to stop DB with SQL? (I don't know)
STOP ENGINE engine-name UNCONDITIONALLY; ...which does exist in V5.5.
I will suggest it, thanks.