Message viewer 'Source' and 'Target' drop down menus very slow
This is embarrassing. I should know how to do this but I have forgotten.
I know the slowness of the 'Source' and 'Target' parameters in Message message viewer being slow to load is caused by the Bitmap indices of Ens.MessageHeader.
I know I need to run the 'bitmap index clean up' routine for Ens.MessageHeader to fixed the issue.
What I forget is how to do this?
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY...
Any advice or suggestions appreciated.
Kind regards,
Stephen
It has been a while since I had a similar issue, but I usually rebuild the indices from within the SQL portal which appears to be described in the link you provided under Building Indices with the Management Portal.
Thanks for the quick response!
Have you tried rebuilding the indexes from the SQL portal. it seems achievable without downtime, but I worry about load.
WRC recommended do ##class(%SYS.Maint.Bitmap).OneClass("Ens.MessageHeader",1,0), but suggested running it at a slower time of day because it would take 1 CPU out of action, and load a lot of data from disk into global buffers.
I'm guessing rebuilding the indexes would add more load because it is less specific. Probably not a huge deal in quiet times.
I'm doing some testing and will post my results.
Kind regards,
Stephen
Thanks,
I'm Health Connect 17.1 - so not too old .
This is interesting as I already have Ens.Util.Tasks.Purge running daily to purge messages more than 30 days old.
I've raised a support call on this with WRC so I'll update soon.
Stephen
Yes, that should be safe to do with a running production.
I would caution against using the management portal to rebuild indices on a live system. Please see the word of warning from the documentation you linked:
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSQLOPT_indices#GSQLOPT_indices_build_smp
"Do not rebuild indices while the table’s data is being accessed by other users. To rebuild indices on an active system, see below."
Further along on the page you can find more information about safe index rebuilding practices on a live system. I would recommend sticking to %SYS.Maint.Bitmap as that is safe to run on an active system.
Yeah, that makes sense. I have yet to need to rebuild indices in a live environment, but good to know. Thanks!
Hello Stephen,
That documentation you linked to put you on the right track! If you click on the %SYS.Maint.Bitmap link it will take you to the class reference which contains some examples of how to run the bitmap cleanup:
https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25SYS.Maint.Bitmap
eg.
d ##class(%SYS.Maint.Bitmap).Namespace("Samples",1,1,"2014-01-17 09:00:00")
d ##class(%SYS.Maint.Bitmap).OneClass("BitMap.Test",1,1)
This utility was only added to the product around version 2015, I believe. It should run automatically as part of an Ensemble message purge. If you need to perform this maintenance on an older version, rebuilding the index can be done though this is a more involved process, especially on a live system.
If needed, you can reach out to the WRC who can provide a utility that performs a similar function to %SYS.Maint.Bitmap for older versions.
Hope that helps!
I *believe* I can safely do the following to my test and live instances command line;
zn "PRODUCTION"do ##class(%SYS.Maint.Bitmap).OneClass("Ens.MessageHeader",1,0)I'm checking with WRC
Thank you to the community members who responded and Andrew Harris of InterSystems UK(WRC)
I have combined the question and answer I received from Andrew and the community as an article:
https://community.intersystems.com/post/speeding-source-and-target-drop-downs-message-viewer