UV 14.2.1 uvconfig N_AFT, N_AFT_SECTION and N_AFT_SECTION_BUCKET

Those example numbers are (of course) invalid, as the N_AFT_SECTION_BUCKET value must be a prime number larger than N_AFT_SECTION.

A more valid example for N_AFT of 15000 is N_ACT_SECTION set to 31 and N_AFT_SECTION_BUCKET set to 37. This produces a higher ration of 483.87 files per SECTION but a similar 13.08 files per SECTION BUCKET.

If you plan to set N_AFT to 15000, I suggest starting with N_AFT_SECTION=17 and N_AFT_SECTION_BUCKET=71. Both values are prime, and the bucket count is greater than the section count.

If the table was full, these settings give an average of about 12.4 AFT entries per bucket:

15000 / (17 * 71) = 12.4

With the defaults N_AFT=5000, N_AFT_SECTION=17, and N_AFT_SECTION_BUCKET=23 give an average of 12.8 AFT entries per bucket. These are starting values, actual sizing depends on the application’s peak AFT usage and distribution.

You can review AFT usage with uvs_stat, select 2 (Static Control Area), 1 (AFT), then 9 (Analyze AFT and display statistics). The report shows a snapshot of section and bucket contents. It can help identify usage or distribution patterns, but it does not measure section lock contention.  Uneven counts alone are not a reason to increase N_AFT_SECTION. If considering a higher section count, compare performance under similar load.

For an estimated average:

AVG_FILES_PER_BUCKET = N_AFT / (N_AFT_SECTION * N_AFT_SECTION_BUCKET)

AVG_FILES_PER_BUCKET is not a uvconfig parameter. If you want the average to be at least a target value, choose a prime N_AFT_SECTION_BUCKET greater than N_AFT_SECTION and no greater than:

N_AFT / (N_AFT_SECTION * target AVG_FILES_PER_BUCKET)

For example, with 23 sections and a target average of 12:

15000 / (23 * 12) = 54.35

The largest prime greater than 23 and no greater than 54 is 53, giving an estimated average of about 12.3 entries per bucket. Using 59 would be at about 11 for an average.

Thanks ​@Brian Kupzyk for your detailed response.

I was interested to see you suggest keeping N_AFT_SECTION at 17 and just increase the N_AFT_SECTION_BUCKET value.

The default uvconfig entry for the setting is:

# N_AFT_SECTION - Number of sections in the AFT.

N_AFT_SECTION 17
So there is no real guidance on how to set the value there, providing an implied expectation to not change it

The description in the “What_You_Need_to_Know_When_Moving_from_UniVerse_11_to_14.pdf” is:

N_AFT_SECTION (Default: 17)
Specifies the number of sections in the AFT. Dividing the table into sections allows 
concurrent access by different UniVerse processes, improving performance.
• If you increase N_AFT, consider increasing this value as well.
• Recommended: Use a prime number less than N_AFT / 2.

So the guidance there to consider an increase N_AFT_SECTION when N_AFT is increased also added weight to the our decision to adjust N_AFT_SECTION.

We use a 100 user system as our base configuration. This results in our setting NUSERS to 1453, much higher than the default uvconfig setting of 256.

So my thinking in adjusting the N_AFT_SECTION setting was that with our NUSERS setting over 5.6 times larger than the default we should be considering a larger N_AFT_SECTION setting to reduce the section lock contention.

The document “universe_administering_universe_on_windows_and_unix_platforms_version_14.2.1” give the following guidance for N_AFT_SECTION :

The default value is 17. You can increase the number of sections using this 
parameter, but ensure that the new value is greater than 0, less than 
N_AFT/2, and be a prime number. It is recommended that you increase this 
number in small increments and review the results using the uvsysmon 
utility. 

So I am still not clear on when I should be considering adjusting N_AFT_SECTION.

Is the driving factor for increasing N_AFT_SECTION purely based on section lock contention/performance measurement?

Performance measurement can be a fluffy art.

Are there specific performance measurement tools now available in 14.2.1 that can help to determine if/when N_AFT_SECTION lock contention is an issue that needs addressing?

Two commands to use when considering an increase to N_AFT_SECTION:

uvsysmon — Check the Aft line under LATCHING STATISTICS, especially collisions, retries, and retry percentage across repeated samples. These are aggregate AFT latch statistics, not section-specific.
uvs_stat -> 2 -> 1 -> 9 - Shows section and bucket contents as a snapshot; it does not measure lock waits.
If AFT latch collisions/retries are sustained and coincide with slower opens under a representative workload, test a modest increase to N_AFT_SECTION and compare against the same workload. These tools don’t isolate section-lock contention, and I don’t know of a documented numeric threshold that automatically calls for a change. Then recalculate N_AFT_SECTION_BUCKET using the bucket-sizing rule.

With AVG_RECS_PER_BUCKET=12:

Also apply the requirement that N_AFT_SECTION_BUCKET be prime and greater than N_AFT_SECTION.