When Does a User Profile Become a Bottleneck?

I’ve worked with several clients recently where a user profile, which could be a group profile, has become a major system bottleneck. This issue has taken two forms:

• Performance issues that occur because many objects are created and deleted for a single owning user profile
• Availability issues because a user profile hits the limit on the maximum number of entries

Performance and Seize Contention

When you have a single user profile that is used for major applications, be aware that when you create or delete objects, the system must update the owning user profile. When the system updates the owning user profile, it uses what is called a “seize.” A seize is a Licensed Internal Code serialization mechanism to ensure the integrity of internal data structures. If you create and/or delete many objects owned by a single user profile, you can encounter seize contention.

I have seen several instances where a single profile owns all objects for a major application. Often times, an application makes extensive use of creating work files and other objects in QTEMP; these objects are then deleted when the jobs ends. During peak business timeframes, seize contention on a single profile can cause severe application performance problems. The resolution often requires reworking applications to reduce the number of objects that are created and deleted on the fly.

Collection Services data will show seize contention if this occurs. You can drill down to find the impacted jobs, but you can’t get more detailed information from Collection Services. Job Watcher data is required for detailed analysis and will reveal the object being waited upon is the user profile.

Maximum Number of Entries

The system has a hard limit on the maximum number of entries for a user profile. This limit is documented in the “Security limits” of the “Maximum capacities” section of IBM Documentation (the Knowledge Center). This limit is 50,000,000 entries and consists of the following, as described by IBM documentation:

“A user profile contains four categories of entries: 1) every object owned by the profile, 2) every private authority the profile has to other objects, 3) every private authority to objects owned by this profile that other profiles have, and 4) every object for which this profile is the primary group. The sum of these categories equals the total number of entries for the profile.”

As an environment gets larger and larger, having a single user profile that owns a large number of objects, or has private authority to a very large number of objects, can result in hitting this system limit. When this occurs, MCH2804 – Tried to go larger than storage limit for object &1 – occurs and the application fails. This can be disastrous in a busy production environment.

Using authorization lists or group profiles can reduce the number of private authorities, but if the issue is due to owned objects, having a single profile own many objects can become a severe problem. Remember, objects in the IFS are included in the owned objects and if you are not managing your IFS usage, this can result in an unexpected surprise.

The Print Profile Internals (PRTPRFINT) command can be used to generate a report on the number of owned objects for a user profile. You can print a report of all user profiles at a specified percent full, or you can print a report for a specific user profile. If you have an environment involving a single user profile owning application objects, a good proactive step is to use this command to determine your risk factor before you encounter issues. From my investigation, it looks like this command was added in IBM i 7.1.

Today, there is no SQL interface to the information provided by PRTPRFINT, but an RFE has been submitted requesting this support.

System Health Services can be used to track system limits. The SQL_SIZING table, which has a row for each limit, includes this:

Sizing ID:  18600
Sizing Name:  MAXIMUM NUMBER OF ENTRIES FOR A USER PROFILE
Sizing Value: 50000000

However, the system health services do not appear to track this limit as this limit is not listed in the System Health Services documentation. I hope that IBM will start tracking this limit.

---