Any application can have performance problems if the infrastructure isn’t sized for the load that is being used for. This article discusses this in more detail and how to help prevent the database becoming a performance problem on your Maximo system.
Incorrect assumption - “IBM will deliver a perfectly tuned system for my installation”
When the IBM developers build the Maximo software they don’t know how customers will use the application so they provide a standard set of indexes and SQL. I regularly talk to IBM developers and show them real life use cases that they could not have foreseen.
The standard configuration suits a lot of customers but there will always be situations where the performance needs to be tweaked particularly when customisations/configurations have been deployed.
IBM publish a best practice guide to configure Maximo for the best performance.
This guide is essential reading for 7.6 installations. This has been updated from 7.5 and a number of important settings have been updated e.g. the amount of memory required for JVMs.
“The importance of considering the load on the database”
I meet inexperienced support teams who start building BIRT reports and deploying lots of escalations without considering the potential impact on the database. The Maximo software can’t judge the potential impact of user configurations so it can’t warn you if a change is going to cause significant problems.
It is important to remember that the database will have been sized for a specific load. That load should have been defined as part of the requirements gathering process. If the requirements didn’t capture the full load then Maximo uses are likely to experience performance problems.
Non-technical example of how overload can occur
A party planner books 3 tables at a small restaurant for a small family gathering for the closest family.
The problems occur when attendees bring other family members e.g. children and friends. People at the party will find that they struggle to move / do things. As the numbers grow it is clear that a hall should have been booked.
The same is true of any undersized system.
Where could extra load come from?
I have investigated a number of different performance problems and these are some of the common non-Maximo causes I have found:
If you have an external team installing/upgrading Maximo then it is essential that they are told about all the external requirements.
Discuss support procedures and ask where external load could be coming from.
The external team should also analyse the production system and ensure that they have a good understanding about what SQL is being executed on the database and what is submitting it. It is very dangerous to assume that Maximo is the only process executing SQL against an established database.
Why is it so important to know these details?
If the server isn’t specified correctly then the following symptoms may be seen:
How to avoid a performance problem
- Tune every customisation that is put into production
- Review the SQL that is being deployed and optimise it. If you don't know how to optimise SQL then see my article here about skills to develop
- Get involved during the design process and check that the design isn’t going to create unnecessary load on the databases
- Warn developers of problem areas e.g. tables with large numbers of rows
- Be suspicious of designs that use escalations to query the database every minute just to find new records.
#Maximo#AssetandFacilitiesManagement