Troubleshooting
Problem
This document discusses the limit on size of an IBM i user profile, the different types of entries in a profile, and the limit on the number of those entries.
Resolving The Problem
Question
Is there a limit on the size of an IBM i user profile? If yes, what is this limit? Is there a limit on the total size of all pointers to objects owned by a user profile? If yes, what is this limit, and how many objects does that translate into?
Answer
This note applies to all releases of the IBM i OS. Through V4R3M0, a user profile was limited to 1,048,574 entries. At V4R4M0, the profile was changed to where it could hold 5,000,000 entries though the OS/400 still supported both sizes of profiles. At V5R1M0 the system was changed so that as the installation was done, profiles were changed as needed so that all had the format that supported 5,000,000 entries. At V5R2M0 the profile was again enlarged so it could hold 10,000,000 entries. As with the prior release, all profiles have the same format and same maximum number of entries. Additionally, at V5R1M0 for profiles that own, have private authority to, or are the primary group profile for an object on an IASP, an additional 5 (or 10 in V5R2) million entries are available to that specific profile (but those additional entries can be used only for objects on that specific IASP. They are not available for use by objects in the system ASP. If a profile has entries for two IASPs, there are 5 or 10 million entries for each such IASP depending upon release level.
The user profile does have a finite size; however, it is composed of two sections. It is not easy to determine the maximum number of entries. The main sections consist of an index and a table. There are several limits associated with a user profile. The usual reason a user profile fills up is because the table fills up. The table holds 1,048,574, 5 million or 10 million entries depending on release level. The maximum size for a user profile is about 48 megabytes (this was true for the 1,048,574 entry table).
At 6.1, the limit on entries for the profile increased from 10 million to 50 million. 50 million is still the current limit at 7.4 and 7.5.
Resolution
Storage is used by user profiles for the following reasons:
Is there a limit on the size of an IBM i user profile? If yes, what is this limit? Is there a limit on the total size of all pointers to objects owned by a user profile? If yes, what is this limit, and how many objects does that translate into?
Answer
This note applies to all releases of the IBM i OS. Through V4R3M0, a user profile was limited to 1,048,574 entries. At V4R4M0, the profile was changed to where it could hold 5,000,000 entries though the OS/400 still supported both sizes of profiles. At V5R1M0 the system was changed so that as the installation was done, profiles were changed as needed so that all had the format that supported 5,000,000 entries. At V5R2M0 the profile was again enlarged so it could hold 10,000,000 entries. As with the prior release, all profiles have the same format and same maximum number of entries. Additionally, at V5R1M0 for profiles that own, have private authority to, or are the primary group profile for an object on an IASP, an additional 5 (or 10 in V5R2) million entries are available to that specific profile (but those additional entries can be used only for objects on that specific IASP. They are not available for use by objects in the system ASP. If a profile has entries for two IASPs, there are 5 or 10 million entries for each such IASP depending upon release level.
The user profile does have a finite size; however, it is composed of two sections. It is not easy to determine the maximum number of entries. The main sections consist of an index and a table. There are several limits associated with a user profile. The usual reason a user profile fills up is because the table fills up. The table holds 1,048,574, 5 million or 10 million entries depending on release level. The maximum size for a user profile is about 48 megabytes (this was true for the 1,048,574 entry table).
At 6.1, the limit on entries for the profile increased from 10 million to 50 million. 50 million is still the current limit at 7.4 and 7.5.
Resolution
Storage is used by user profiles for the following reasons:
| 1. | Each MI object that the user profile owns takes one logical entry. |
| 2. | Each MI object that the user profile has a private authority to takes one logical entry. |
| 3. | Each user profile which has a private authority to an MI object takes one logical entry in the user profile which owns the MI object. This is the one that is usually the cause of problems for customers with full user profiles. |
| 4. | Each logical entry which is subsequently deleted still consumes some space required to track it as a free entry. A profile does not fill up when it contains free entries. |
Note that database files are composites of several MI objects, and there are entries in the user profile for each of the composite pieces. For example, a *FILE object has a minimum of three object owned entries; one for the file object and two for each member of the file. If an index is built over the file, there is an additional entry for each member in the file. A file with 100 members will have a minimum of 201 object-owned entries plus 100 more if an index is built over the file. There are additional internal objects that may be also be associated with the file. If this file has private authorities, there is a private authority for each of the MI objects (not just for the external *FILE object). Granting private authorities to DB files may cause the owning user profile to grow very rapidly and would be a good place to start when trying to resolve this type of problem.
Each user profile has two repositories for the above information. The data is kept in a machine index for quick access and is also kept more durably in a table. The table is used primarily for rebuilding the index, because machine indexes are quite volatile following a system crash.
The index and table space objects allocate storage as authorities, primary group authorities, and ownership are added to a user profile. The storage for these space objects is expanded as required.
The physical size limit of a user profile is about 48 MB, 16 MB for the table and the index can grow as large as it needs to hold the 1.048,574 entries. When the table is full, the index is usually around 32 MB.
Note that all of the above has to do with the physical size of the user profile object and the MCH2804 message that can occur when it becomes full. This has nothing to do with the MAXSTG parameter associated with the user profile which refers to the amount of storage that can be occupied by the objects it owns. Therefore, it is quite possible for a user profile with *NOMAX to be receiving MCH2804 exceptions.
When a user profile becomes full (or the customer thinks it is too large), there are some things that can be done.
Each user profile has two repositories for the above information. The data is kept in a machine index for quick access and is also kept more durably in a table. The table is used primarily for rebuilding the index, because machine indexes are quite volatile following a system crash.
The index and table space objects allocate storage as authorities, primary group authorities, and ownership are added to a user profile. The storage for these space objects is expanded as required.
The physical size limit of a user profile is about 48 MB, 16 MB for the table and the index can grow as large as it needs to hold the 1.048,574 entries. When the table is full, the index is usually around 32 MB.
Note that all of the above has to do with the physical size of the user profile object and the MCH2804 message that can occur when it becomes full. This has nothing to do with the MAXSTG parameter associated with the user profile which refers to the amount of storage that can be occupied by the objects it owns. Therefore, it is quite possible for a user profile with *NOMAX to be receiving MCH2804 exceptions.
When a user profile becomes full (or the customer thinks it is too large), there are some things that can be done.
| 1. | Transfer ownership of objects the user profile owns to some other user profile. This removes one entry for each MI object, and one entry for each user profile which has a private authority to the MI object. This is probably the choice that gets the most mileage. |
| 2. | Revoke some of the user profile's private authority to various objects. While private authorities exist for functional reasons, they come with a cost. They take up room, they have a performance penalty, and they cause longer save times. |
Both of the above items will reduce the number of active entries in the user profile. However, the physical size of the user profile may not change for the following reasons (this is normal):
| 1. | In the user profile table, the deleted entries now exist as free entries. |
| 2. | In the index, other entries have been created to locate the free entries within the table. |
| 3. | In the index, the entries have been removed. However, unless all entries within the same logical page of the machine index have been removed, that entire page still appears as used. Free space within it can only be reused for similar entries. That is, entries whose data content is similar enough to that of the removed entries that the path to the entry would take it to the same logical page. |
As authorities and ownership are removed from a user profile, the entries are removed and create free space. This creates free entries that are immediately re-usable. The space is used by similar entries that fit the same logical space.
The freed entries in the index and the table are removed over time. When size limits are reached, the table and the index are compressed to see if room can be found before reporting the user profile is full. Also during user profile recovery (IPL and reclaim storage) the profiles are compressed.
The index space and table space for a user profile does not get rebuilt automatically. These spaces are rebuilt when they become damaged or out of sync. A regular IPL or abnormal IPL does not automatically rebuild the user profile unless the spaces are damaged or no longer synchronized.
The freed entries in the index and the table are removed over time. When size limits are reached, the table and the index are compressed to see if room can be found before reporting the user profile is full. Also during user profile recovery (IPL and reclaim storage) the profiles are compressed.
The index space and table space for a user profile does not get rebuilt automatically. These spaces are rebuilt when they become damaged or out of sync. A regular IPL or abnormal IPL does not automatically rebuild the user profile unless the spaces are damaged or no longer synchronized.
[{"Type":"MASTER","Line of Business":{"code":"LOB68","label":"Power HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CHyAAM","label":"Security"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"6.1.0;7.1.0;7.2.0;7.3.0;7.4.0;7.5.0"}]
Historical Number
10061758
Was this topic helpful?
Document Information
More support for:
IBM i
Component:
Security
Software version:
6.1.0, 7.1.0, 7.2.0, 7.3.0, 7.4.0, 7.5.0
Operating system(s):
IBM i
Document number:
642893
Modified date:
07 October 2024
UID
nas8N1018495
Manage My Notification Subscriptions