Maximo Manage System Properties: A Performance and Governance Deep Dive

System properties in Maximo Manage are the silent levers that shape every transaction, every integration, and every user experience in the platform. They are also the most under-governed configuration surface in the entire stack. Most organizations treat them as a technical detail that lives in the System Properties application, owned by nobody, reviewed rarely, and changed without much forethought. The result is a configuration layer that drifts, accumulates technical debt, and silently shapes the user experience in ways that nobody fully understands.

This article treats system properties as a first-class operational artifact. It provides a working taxonomy for grouping properties by impact, a performance-focused baseline that you can use as a starting point, and a governance framework that you can use to bring the configuration layer under control. The guidance is grounded in the IBM performance best practices documentation, the MAS Performance Wiki, and the practical experience of teams that have run Maximo at scale for years.

The intended audience is Maximo administrators, performance engineers, and MAS architects. The article assumes a working knowledge of Maximo Manage, the WebSphere Liberty runtime, and the underlying database (Db2, Oracle, or SQL Server). It does not assume any particular industry or asset base, and the guidance is general enough to apply to most production environments.

A Taxonomy of System Properties by Impact

The default way to think about system properties is by name or by application area. The mxe.* prefix covers core system behavior. The webclient.* prefix covers the UI behavior. The report.* prefix covers BIRT reporting. This grouping is useful for technical navigation, but it is not useful for governance. A property like mxe.db.url is technically grouped with mxe.* but operationally has very different implications than mxe.db.sql.log.

A better grouping is by impact. The impact-based taxonomy groups properties by the kind of experience they create, not by the code module they belong to. The taxonomy proposed in this article has six impact groups:

Flow — Properties that shape how work moves through the system. Examples include mxe.workorder.autoassign, mxe.workflow.maxescalations, and mxe.webclient.collapseAllSections. These properties shape whether work orders get auto-assigned, how escalations are routed, and how dense the user interface feels.

Trust — Properties that shape how users trust the data they see. Examples include mxe.display.sequence, mxe.int.classstructureid, and mxe.db.sql.log. These properties shape whether IDs are shown to users, whether classification IDs are exposed, and whether SQL is logged.

Documentation — Properties that shape how field documentation and help text are presented. Examples include mxe.webclient.helpurl, mxe.webclient.doclinkurl, and mxe.doclink.doctypes. These properties shape how users access help and how they link to external documentation.

Hierarchy Understanding — Properties that shape how users navigate the asset and location hierarchies. Examples include mxe.useAssethierarchies, mxe.useLocationhierarchies, and mxe.tree.fetchlimit. These properties shape whether hierarchies are presented, and how deep the tree view can drill.

Automation — Properties that shape how cron tasks, escalation rules, and integration triggers fire. Examples include mxe.crontask.donotrun, mxe.int.escalation.maxretries, and mif.cron.interval. These properties shape whether automation runs at all, and how often.

Governance — Properties that shape authentication, authorization, and audit. Examples include mxe.auth.passwordpolicy, mxe.sso.ltpa.timeout, and mxe.report.password.disable. These properties shape security posture and are often subject to regulatory requirements.

The value of the impact-based grouping is that it makes system properties discussable with business users. A conversation about mxe.webclient.collapseAllSections is technical. A conversation about whether the UI feels dense or spacious is operational. The latter is the conversation that drives real decisions.

The Performance Baseline: What Every Maximo Manage Environment Should Look Like

The IBM performance best practices documentation provides detailed guidance on every layer of the stack, from the JVM to the database. The guidance can be overwhelming, so this section distills it into a working baseline that applies to most production environments.

Application Server Tuning. Maximo 8.x in Maximo Manage runs on WebSphere Liberty Base 21.0.0.5 with OpenJ9. WebSphere Liberty 18.0.0.1 and later versions increase thread capacity faster to handle peak loads, and this automatic tuning works well for most environments. If you need to override the defaults, adjust coreThreads and maxThreads in the server.xml. A reasonable starting point is coreThreads=64 and maxThreads=192 for a production-grade deployment, but the right values depend on the workload profile and the number of CPU cores allocated to the pod.

JVM Options. The most important JVM options for Maximo Manage are the heap size and the garbage collection policy. A production-grade Maximo Manage pod should have a minimum heap of 8 GB and a maximum heap of 16 GB, with the G1 garbage collector enabled. The -Xmn option should be set to 25% of the maximum heap, and the -XX:MaxGCPauseMillis should be set to 200 milliseconds. For environments with very large heaps (32 GB or more), consider the ZGC garbage collector instead, which has lower pause times.

Bundle Separation. Maximo Manage offers different bundle types for the application server: all, UI, MEA, report, and cron. Separate UI, cron, MIF, and report workloads into different bundle types to prevent resource conflicts within the same JVM or pod. A typical production deployment has at least three bundles: a UI bundle for end-user traffic, a cron bundle for scheduled tasks, and a report bundle for BIRT report generation. The MIF bundle can be combined with the cron bundle if MIF traffic is light.

Database Disk Performance. Disk performance is critical for database performance. The IBM guidance specifies disk throughput greater than 250 MB per second and IOPS from 10 IOPS per GB to 100 IOPS per GB, depending on volume size. To measure disk performance on Linux, use the dd command:

# Measure sequential write throughput
dd if=/dev/zero of=/tmp/test bs=1M count=1024 oflag=direct

# Measure random read IOPS
fio --name=randread --ioengine=libaio --direct=1 \
    --filename=/dev/sda --bs=4k --size=2G \
    --rw=randread --iodepth=64 --runtime=30 --time_based

If your measured throughput or IOPS falls below the recommended values, you have a disk performance problem that no amount of JVM tuning will fix.

Database Connection Pool. The database connection pool is one of the most common sources of performance issues in Maximo Manage. The default pool size is too small for most production workloads. A reasonable starting point is a maximum of 100 connections per pod, with a minimum of 10. The pool should be sized to match the number of concurrent requests, not the number of users. If the pool is exhausted, requests will block, and the UI will feel slow. Monitor the pool utilization with the mxe.db.connectionpool system property and the WebSphere Liberty connection pool metrics.

Db2 and SQL Server Specific Tuning

The two most common database platforms for Maximo Manage are Db2 and Microsoft SQL Server, and the tuning guidance is different for each. The following subsections summarize the most important settings.

Db2 Configuration

The first setting is the workload registration. Set db2_workload=maximo for db2set. This registers Maximo-specific optimizations with Db2, including query optimizer hints and memory allocation patterns. Do not change the default values for DB2_OVERRIDE_NUM_CPUS and DB2_OVERRIDE_THREADING_DEGREE; these are calculated based on the container memory limit.

The second setting is the WLM admission control. Verify that the Db2 database configuration variable WLM_ADMISSION_CTRL is set to NO. WLM admission control can throttle incoming connections, which is appropriate for some workloads but harmful for Maximo. Maximo benefits from being able to submit as many concurrent queries as it needs.

The third setting is the monitor switches. Turn off all Db2 monitor switches except timestamp in the database manager configuration. When you need monitor data, enable the switches only for the session, then turn them off after data collection. This reduces the overhead of monitoring and improves performance.

The fourth setting is the sequence cache. Set maxsequence cache to 50. Maximo uses sequences extensively, and the sequence cache reduces the number of disk reads required to fetch the next sequence value.

The fifth setting is the tablespace organization. For Db2 Warehouse, update the configuration with db2 update db cfg using DFT_TABLE_ORG ROW, because Maximo Manage requires row-organized tables. The default is column-organized, which is not compatible with Maximo.

The sixth setting is the archiving policy. Maximo Manage does not support MPP or table partitioning. Archive records older than one year, because Maximo Manage does not support MPP or table partitioning. The archiving policy should be part of the operational runbook, not an afterthought.

-- Update Db2 configuration for Maximo Manage
UPDATE DB CFG FOR MAXDB USING DFT_TABLE_ORG ROW;
UPDATE DB CFG FOR MAXDB USING WLM_ADMISSION_CTRL NO;
UPDATE DB CFG FOR MAXDB USING MAXSEQUENCE_CACHE 50;

-- Verify the configuration
GET DB CFG FOR MAXDB;

SQL Server Configuration

The first setting is the compatibility level. Set the compatibility level to the earlier version to preserve the execution plan if the Maximo database was upgraded and performance degraded. The compatibility level should match the version of Maximo that you are running. For MAS 9.x, the recommended compatibility level is SQL Server 2019 (150).

The second setting is the isolation level. Use snapshot isolation to reduce blocking:

ALTER DATABASE MAXDB
SET ALLOW_SNAPSHOT_ISOLATION ON;

ALTER DATABASE MAXDB
SET READ_COMMITTED_SNAPSHOT ON;

The third setting is tempdb placement. Place tempdb on dedicated high-speed disks. tempdb is used heavily by Maximo for sorting and joining, and a slow tempdb will degrade query performance significantly.

The fourth setting is index maintenance. After migrating Maximo from version 7, refresh index statistics. In some cases, you may also need to rebuild indexes. A weekly index maintenance job is a good starting point, and it can be run as a cron task inside Maximo or as a SQL Server Agent job.

Network and Load Balancing

Network latency is often overlooked in Maximo Manage performance tuning, but it is one of the most important factors. The IBM guidance specifies that latency should be below 50 milliseconds for any production environment, and below 10 milliseconds for environments with high transaction volumes. For cloud deployments, place the database and Red Hat OpenShift cluster in the same region and availability zone whenever possible.

The load balancer policy also matters. Lab testing shows that the roundrobin policy performs better than the default leastconn policy for Maximo Manage. The leastconn policy is designed for long-lived connections, but Maximo uses short-lived HTTP connections, and the roundrobin policy distributes them more evenly. To change the policy, update the OpenShift route configuration:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: maximo-manage
  annotations:
    haproxy.router.openshift.io/balance: roundrobin
    haproxy.router.openshift.io/timeout: 60s

The load balancer timeout should be set to at least 60 seconds. Maximo Manage can take longer than 30 seconds to respond under heavy load, and a 30-second timeout will cause spurious failures.

System Property Governance: A Practical Framework

The most important step in bringing system properties under control is to create a system property baseline. The baseline is a curated list of properties that have a visible impact on the user experience, the integration behavior, or the performance profile. The baseline should include the following fields for each property:

• Property name — the full system property name (e.g., mxe.db.url)
• Current value — the value currently in production
• Default or expected value — the value that IBM recommends
• Environment — the environment in which the value applies (dev, test, prod)
• Functional area — the application or module (e.g., Work Order Tracking)
• Impact group — one of the six impact groups described above
• Business or user impact — a plain-language description of what the property changes
• Owner — the person or team responsible for the property
• Last reviewed date — when the property was last reviewed
• Related test scenario — the test case that validates the property's behavior
• Requires Live Refresh or restart — whether changing the property requires a Live Refresh or a server restart
• Related incident or change — any incident or change record that references the property

The baseline should be reviewed quarterly. The review should focus on properties that have changed in the last quarter, properties that have had incidents, and properties that are approaching a deprecation milestone. The review should be attended by at least one representative from each impact group.

The baseline should also be version-controlled. Every change to a system property should be a change record in your ITSM system, with a clear description of what changed, why it changed, and how it was tested. The change record should reference the test scenario in the baseline.

For properties that have a visible user impact, consider creating a user-facing description. The description should explain what the property does, why it matters, and what the user can expect. The user-facing description is the document that the help desk references when a user asks why the UI looks the way it does.

Common Pitfalls and Field-Tested Patterns

The most common pitfall in system property management is the undocumented change. An administrator changes a property to fix an immediate problem, the property is not documented, and six months later nobody remembers why the property was changed. The undocumented change is the source of most "ghost" configuration issues.

The second most common pitfall is the property change without testing. Some properties are benign, but others have far-reaching consequences. The mxe.db.sql.log property, for example, is harmless in dev but can degrade production performance by 30% or more. Every property change should be tested in a non-production environment first, with a representative load test.

The third most common pitfall is the property that "just works" in one environment but breaks in another. This usually happens because the property depends on a path, hostname, or credential that is hard-coded. The fix is to use environment variables or externalized configuration for anything that differs between environments.

The first field-tested pattern is the "small changes, big impact" review. Periodically, the configuration team should review the system properties for small changes that could have a big impact. The "small changes, big impact" review is a known practice in the Maximo community, and it is one of the most effective ways to improve the user experience without a major upgrade.

The second field-tested pattern is the impact-based baseline. Instead of grouping properties by name, group them by impact. The impact-based baseline makes the configuration discussable with business users, and it is the basis for a real governance conversation.

The third field-tested pattern is the property diff between environments. Every quarter, generate a diff between the dev, test, and prod property sets. The diff will surface properties that have drifted, properties that have been added to one environment but not the others, and properties that have been deleted in one environment but not the others. The diff is the basis for a configuration reconciliation exercise.

Practical Implications

The practical implications of treating system properties as a first-class operational artifact are significant. For administrators, the implication is that they need to take ownership of the property baseline, and they need to participate in the quarterly review. For performance engineers, the implication is that they need to include property configuration in their performance testing. For architects, the implication is that they need to design the system property layer for externalization, so that environment-specific values do not have to be baked into the deployment.

For executives, the implication is that the system property layer is a source of operational risk. A property that is misconfigured in production can cause a wide range of issues, from slow performance to data corruption. The property layer should be treated with the same rigor as the database schema, the integration layer, and the security configuration.

For the broader Maximo community, the implication is that the property layer deserves more attention. The IBM documentation is comprehensive, but it is not curated. A community-maintained property baseline, organized by impact, would be a valuable resource for the entire community.

Bottom Line

System properties are the most under-governed configuration surface in Maximo Manage, and they shape every transaction, every integration, and every user experience. The default way of thinking about them, by name or by application area, is not useful for governance. The impact-based taxonomy, organized into flow, trust, documentation, hierarchy understanding, automation, and governance, is the right starting point.

The performance baseline described in this article is a starting point, not a destination. Every environment is different, and the right values depend on the workload, the hardware, and the user expectations. The important thing is to have a baseline, to track the deviations, and to review the deviations quarterly.

The governance framework, with the property baseline, the version control, the change records, and the quarterly review, is the operational discipline that makes the baseline sustainable. Without governance, the baseline will drift, and the configuration layer will revert to the default state of under-management.

The bottom line: system properties are not a technical detail. They are a strategic asset. Treat them that way.