Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Doug,

Thank you so much for the piece of advice.

For clearance, I need to export LDR_CNTRL before oninit? And that is instead of setting up large pages?

Next, what size of memory considered large?

When IFX_LARGE_PAGES is enabled, the use of large pages can offer significant performance benefits in large memory configurations.

Is 610GB large?

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Yes - just export LDR_CNTRL when starting "oninit" so it doesn't affect anything else. That predates large page support in Informix on AIX. We have that on all the AIX systems we support. None of those have as much memory as yours, so I would think large pages (Informix will use 16MB) must be a good thing for you. We use the equivalent "huge pages" on all Linux systems regardless of size.

Doug,

Thank you so much for the piece of advice.

For clearance, I need to export LDR_CNTRL before oninit? And that is instead of setting up large pages?

Next, what size of memory considered large?

When IFX_LARGE_PAGES is enabled, the use of large pages can offer significant performance benefits in large memory configurations.

Is 610GB large?

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Doug,

Thank you!

One more question, if you don't mind. Which metrics, from OS or IDS, might indicate that we have a positive impact on performance?

Yes - just export LDR_CNTRL when starting "oninit" so it doesn't affect anything else. That predates large page support in Informix on AIX. We have that on all the AIX systems we support. None of those have as much memory as yours, so I would think large pages (Informix will use 16MB) must be a good thing for you. We use the equivalent "huge pages" on all Linux systems regardless of size.

Doug,

Thank you so much for the piece of advice.

For clearance, I need to export LDR_CNTRL before oninit? And that is instead of setting up large pages?

Next, what size of memory considered large?

When IFX_LARGE_PAGES is enabled, the use of large pages can offer significant performance benefits in large memory configurations.

Is 610GB large?

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Yes - just export LDR_CNTRL when starting "oninit" so it doesn't affect anything else. That predates large page support in Informix on AIX. We have that on all the AIX systems we support. None of those have as much memory as yours, so I would think large pages (Informix will use 16MB) must be a good thing for you. We use the equivalent "huge pages" on all Linux systems regardless of size.

Doug,

Thank you so much for the piece of advice.

For clearance, I need to export LDR_CNTRL before oninit? And that is instead of setting up large pages?

Next, what size of memory considered large?

When IFX_LARGE_PAGES is enabled, the use of large pages can offer significant performance benefits in large memory configurations.

Is 610GB large?

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Doug,

How to make sure that LDR_CNTRL has been taken into action?

Yes - just export LDR_CNTRL when starting "oninit" so it doesn't affect anything else. That predates large page support in Informix on AIX. We have that on all the AIX systems we support. None of those have as much memory as yours, so I would think large pages (Informix will use 16MB) must be a good thing for you. We use the equivalent "huge pages" on all Linux systems regardless of size.

Doug,

Thank you so much for the piece of advice.

For clearance, I need to export LDR_CNTRL before oninit? And that is instead of setting up large pages?

Next, what size of memory considered large?

When IFX_LARGE_PAGES is enabled, the use of large pages can offer significant performance benefits in large memory configurations.

Is 610GB large?

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

You can check the environment of a process with "ps eww":

https://www.ibm.com/support/pages/verification-environment-settings-running-process-under-aix

Not sure otherwise how you prove it's effective.

Doug,

How to make sure that LDR_CNTRL has been taken into action?

Yes - just export LDR_CNTRL when starting "oninit" so it doesn't affect anything else. That predates large page support in Informix on AIX. We have that on all the AIX systems we support. None of those have as much memory as yours, so I would think large pages (Informix will use 16MB) must be a good thing for you. We use the equivalent "huge pages" on all Linux systems regardless of size.

Doug,

Thank you so much for the piece of advice.

For clearance, I need to export LDR_CNTRL before oninit? And that is instead of setting up large pages?

Next, what size of memory considered large?

When IFX_LARGE_PAGES is enabled, the use of large pages can offer significant performance benefits in large memory configurations.

Is 610GB large?

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Doug,

I found a way to prove if LDR_CNTRL is effective.

svmon -S -O filtercat=shared,shmid=on,mpss=on

Without the setting it shows s(mall, 4K) and m(edium, 64K) pages.

After restart small pages all gone.

You can check the environment of a process with "ps eww":

https://www.ibm.com/support/pages/verification-environment-settings-running-process-under-aix

Not sure otherwise how you prove it's effective.

Doug,

How to make sure that LDR_CNTRL has been taken into action?

Yes - just export LDR_CNTRL when starting "oninit" so it doesn't affect anything else. That predates large page support in Informix on AIX. We have that on all the AIX systems we support. None of those have as much memory as yours, so I would think large pages (Informix will use 16MB) must be a good thing for you. We use the equivalent "huge pages" on all Linux systems regardless of size.

Doug,

Thank you so much for the piece of advice.

For clearance, I need to export LDR_CNTRL before oninit? And that is instead of setting up large pages?

Next, what size of memory considered large?

When IFX_LARGE_PAGES is enabled, the use of large pages can offer significant performance benefits in large memory configurations.

Is 610GB large?

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Thanks, Dennis - that's good to know, and also works for me.

Have your memory header corruptions reduced, or is it too early to say?

------------------------------
Doug Lawry
Oninit Consulting
------------------------------


Original Message:
Sent: Tue August 13, 2024 05:34 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

I found a way to prove if LDR_CNTRL is effective.

svmon -S -O filtercat=shared,shmid=on,mpss=on

Without the setting it shows s(mall, 4K) and m(edium, 64K) pages.

After restart small pages all gone.

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 08:40 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

You can check the environment of a process with "ps eww":

https://www.ibm.com/support/pages/verification-environment-settings-running-process-under-aix

Not sure otherwise how you prove it's effective.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 09, 2024 08:30 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

How to make sure that LDR_CNTRL has been taken into action?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 05:00 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Yes - just export LDR_CNTRL when starting "oninit" so it doesn't affect anything else. That predates large page support in Informix on AIX. We have that on all the AIX systems we support. None of those have as much memory as yours, so I would think large pages (Informix will use 16MB) must be a good thing for you. We use the equivalent "huge pages" on all Linux systems regardless of size.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 09, 2024 04:48 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

Thank you so much for the piece of advice.

For clearance, I need to export LDR_CNTRL before oninit? And that is instead of setting up large pages?

Next, what size of memory considered large?

When IFX_LARGE_PAGES is enabled, the use of large pages can offer significant performance benefits in large memory configurations.

Is 610GB large?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 03:44 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 09, 2024 03:20 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

Could you please give more details on AIX's large pages?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 03:07 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Thu August 08, 2024 06:12 AM
From: Art Kagel
Subject: Large memory segment vs smaller ones

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Doug,

Do I need any changes in ONCONFIG before running `oninit` with LDR_CNTRL?

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Hi Dennis.

1. Yes: "vmo -p -o v_pinshm=1".
2. You must have RESIDENT 2 or more for large pages as they must be pinned.
3. The "rsam" pool is in the dynamic segment. You need RESIDENT 2 or more.
4. It doesn't sound like the problem is with the buffer pool but the "rsam" pool. Your BTR is fine anyway.
5. I will leave Art to answer that!

I wasn't sure whether large pages were supported by IDS 11.70 on AIX, but this old forum thread implies they are:
http://old.iiug.org/forums/ids/index.cgi/noframes/read/26661

Can you share an example assert file?

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Doug,

Do you need the whole 1G AF file?

Hi Dennis.

1. Yes: "vmo -p -o v_pinshm=1".
2. You must have RESIDENT 2 or more for large pages as they must be pinned.
3. The "rsam" pool is in the dynamic segment. You need RESIDENT 2 or more.
4. It doesn't sound like the problem is with the buffer pool but the "rsam" pool. Your BTR is fine anyway.
5. I will leave Art to answer that!

I wasn't sure whether large pages were supported by IDS 11.70 on AIX, but this old forum thread implies they are:
http://old.iiug.org/forums/ids/index.cgi/noframes/read/26661

Can you share an example assert file?

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Probably! Will message you privately for that.

------------------------------
Doug Lawry
Oninit Consulting
------------------------------


Original Message:
Sent: Fri August 16, 2024 06:43 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

Do you need the whole 1G AF file?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 16, 2024 06:16 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Hi Dennis.

1. Yes: "vmo -p -o v_pinshm=1".
2. You must have RESIDENT 2 or more for large pages as they must be pinned.
3. The "rsam" pool is in the dynamic segment. You need RESIDENT 2 or more.
4. It doesn't sound like the problem is with the buffer pool but the "rsam" pool. Your BTR is fine anyway.
5. I will leave Art to answer that!

I wasn't sure whether large pages were supported by IDS 11.70 on AIX, but this old forum thread implies they are:
http://old.iiug.org/forums/ids/index.cgi/noframes/read/26661

Can you share an example assert file?

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 16, 2024 05:13 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 03:44 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 09, 2024 03:20 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

Could you please give more details on AIX's large pages?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 03:07 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Thu August 08, 2024 06:12 AM
From: Art Kagel
Subject: Large memory segment vs smaller ones

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com

`onstat -g mem` shows two "ovrfl-buff0" the biggest segments.

name         class addr             totalsize        freesize         #allocfrag #freefrag
ovrfl-buff0  V     700001040001040  67913740288      4864             2          2
ovrfl-buff0  V     700001040002040  63615004672      4864             2          2
res-buff0    R     7000003625de040  52791328768      4864             2          2
resident     R     70000004006a040  13461045248      4864             2          2
ovrfl-buff3  V     700001f0fc01040  10240024576      4864             2          2
mt           V     700001f0fc25a58  1072594944       8056
rsam         V     700001f0fe3a040  965901864        12394168         959051     4448
global       V     700001f0fc02040  798392320        2968104          3211921    5160
mt           V     700001f0fc23040  634150912        21905768         3244389    211923
aio          V     700001f18b2c040  219742208        1103752          18281      3014

What are those segments?

How can 67,913,740,288 bytes of the 1st ovrfl-buff0 take place between addresses 700001040001040 and 700001040002040?

------------------------------
Sincerely,
Dennis
------------------------------


Original Message:
Sent: Fri August 16, 2024 06:51 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Probably! Will message you privately for that.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 16, 2024 06:43 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

Do you need the whole 1G AF file?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 16, 2024 06:16 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Hi Dennis.

1. Yes: "vmo -p -o v_pinshm=1".
2. You must have RESIDENT 2 or more for large pages as they must be pinned.
3. The "rsam" pool is in the dynamic segment. You need RESIDENT 2 or more.
4. It doesn't sound like the problem is with the buffer pool but the "rsam" pool. Your BTR is fine anyway.
5. I will leave Art to answer that!

I wasn't sure whether large pages were supported by IDS 11.70 on AIX, but this old forum thread implies they are:
http://old.iiug.org/forums/ids/index.cgi/noframes/read/26661

Can you share an example assert file?

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 16, 2024 05:13 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 03:44 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 09, 2024 03:20 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

Could you please give more details on AIX's large pages?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 03:07 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Thu August 08, 2024 06:12 AM
From: Art Kagel
Subject: Large memory segment vs smaller ones

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com

Dennis -

Have you configured your BUFFERPOOLs to extend automatically, i.e. are you using the "extendable" keyword in the BUFFERPOOL parameter?  I am not sure if this was available in 11.70.

Do you have dbspaces defined with page sizes for which there is no BUFFERPOOL entry and you are using the "default" bufferpool?

`onstat -g mem` shows two "ovrfl-buff0" the biggest segments.

name         class addr             totalsize        freesize         #allocfrag #freefrag
ovrfl-buff0  V     700001040001040  67913740288      4864             2          2
ovrfl-buff0  V     700001040002040  63615004672      4864             2          2
res-buff0    R     7000003625de040  52791328768      4864             2          2
resident     R     70000004006a040  13461045248      4864             2          2
ovrfl-buff3  V     700001f0fc01040  10240024576      4864             2          2
mt           V     700001f0fc25a58  1072594944       8056
rsam         V     700001f0fe3a040  965901864        12394168         959051     4448
global       V     700001f0fc02040  798392320        2968104          3211921    5160
mt           V     700001f0fc23040  634150912        21905768         3244389    211923
aio          V     700001f18b2c040  219742208        1103752          18281      3014

What are those segments?

How can 67,913,740,288 bytes of the 1st ovrfl-buff0 take place between addresses 700001040001040 and 700001040002040?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 16, 2024 06:51 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Probably! Will message you privately for that.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 16, 2024 06:43 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

Do you need the whole 1G AF file?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 16, 2024 06:16 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Hi Dennis.

1. Yes: "vmo -p -o v_pinshm=1".
2. You must have RESIDENT 2 or more for large pages as they must be pinned.
3. The "rsam" pool is in the dynamic segment. You need RESIDENT 2 or more.
4. It doesn't sound like the problem is with the buffer pool but the "rsam" pool. Your BTR is fine anyway.
5. I will leave Art to answer that!

I wasn't sure whether large pages were supported by IDS 11.70 on AIX, but this old forum thread implies they are:
http://old.iiug.org/forums/ids/index.cgi/noframes/read/26661

Can you share an example assert file?

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 16, 2024 05:13 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 03:44 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 09, 2024 03:20 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

Could you please give more details on AIX's large pages?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 03:07 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Thu August 08, 2024 06:12 AM
From: Art Kagel
Subject: Large memory segment vs smaller ones

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com

Mike,

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

All dbspaces are 4K or 16K.

Dennis -

Have you configured your BUFFERPOOLs to extend automatically, i.e. are you using the "extendable" keyword in the BUFFERPOOL parameter?  I am not sure if this was available in 11.70.

Do you have dbspaces defined with page sizes for which there is no BUFFERPOOL entry and you are using the "default" bufferpool?

`onstat -g mem` shows two "ovrfl-buff0" the biggest segments.

name         class addr             totalsize        freesize         #allocfrag #freefrag
ovrfl-buff0  V     700001040001040  67913740288      4864             2          2
ovrfl-buff0  V     700001040002040  63615004672      4864             2          2
res-buff0    R     7000003625de040  52791328768      4864             2          2
resident     R     70000004006a040  13461045248      4864             2          2
ovrfl-buff3  V     700001f0fc01040  10240024576      4864             2          2
mt           V     700001f0fc25a58  1072594944       8056
rsam         V     700001f0fe3a040  965901864        12394168         959051     4448
global       V     700001f0fc02040  798392320        2968104          3211921    5160
mt           V     700001f0fc23040  634150912        21905768         3244389    211923
aio          V     700001f18b2c040  219742208        1103752          18281      3014

What are those segments?

How can 67,913,740,288 bytes of the 1st ovrfl-buff0 take place between addresses 700001040001040 and 700001040002040?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 16, 2024 06:51 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Probably! Will message you privately for that.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 16, 2024 06:43 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

Do you need the whole 1G AF file?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 16, 2024 06:16 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Hi Dennis.

1. Yes: "vmo -p -o v_pinshm=1".
2. You must have RESIDENT 2 or more for large pages as they must be pinned.
3. The "rsam" pool is in the dynamic segment. You need RESIDENT 2 or more.
4. It doesn't sound like the problem is with the buffer pool but the "rsam" pool. Your BTR is fine anyway.
5. I will leave Art to answer that!

I wasn't sure whether large pages were supported by IDS 11.70 on AIX, but this old forum thread implies they are:
http://old.iiug.org/forums/ids/index.cgi/noframes/read/26661

Can you share an example assert file?

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 16, 2024 05:13 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 03:44 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Fri August 09, 2024 03:20 AM
From: Dennis Melnikov
Subject: Large memory segment vs smaller ones

Doug,

Could you please give more details on AIX's large pages?

------------------------------
Sincerely,
Dennis


Original Message:
Sent: Fri August 09, 2024 03:07 AM
From: Doug Lawry
Subject: Large memory segment vs smaller ones

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

------------------------------
Doug Lawry
Oninit Consulting


Original Message:
Sent: Thu August 08, 2024 06:12 AM
From: Art Kagel
Subject: Large memory segment vs smaller ones

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com

Hi Dennis.

1. Yes: "vmo -p -o v_pinshm=1".
2. You must have RESIDENT 2 or more for large pages as they must be pinned.
3. The "rsam" pool is in the dynamic segment. You need RESIDENT 2 or more.
4. It doesn't sound like the problem is with the buffer pool but the "rsam" pool. Your BTR is fine anyway.
5. I will leave Art to answer that!

I wasn't sure whether large pages were supported by IDS 11.70 on AIX, but this old forum thread implies they are:
http://old.iiug.org/forums/ids/index.cgi/noframes/read/26661

Can you share an example assert file?

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

BTW, between 'large' assertions--I mean those that are logged in online.log--the server throws 'small' ones, i.e. files of 700+ bytes size, that appear in DUMPDIR only, like this one:

12:10:06  Found during mt_shm_free 1
12:10:06  Pool 'rsam' (0x700001f0fe3a040)
12:10:06  Bad block header 0x700003c9c048ea8
blk-64
0700003c9c048e68: 0e000079 38091cf1 0010197c 00000e0e   ...y8... ...|....
0700003c9c048e78: 0700003c 9c048ea8 0700003c 9c048e08   ...<.... ...<....
0700003c9c048e88: 00000000 00000040 00000000 0001a2af   .......@ ........
0700003c9c048e98: 00000150 00000008 00000000 00000000   ...P.... ........
blk+64
0700003c9c048ea8: 0e000079 28011c91 0010197c 00000e0e   ...y(... ...|....
0700003c9c048eb8: 0700003c 9c048ee8 0700003c 9c048e68   ...<.... ...<...h
0700003c9c048ec8: 00000000 00000040 00000000 00001e84   .......@ ........
0700003c9c048ed8: 00000151 00000008 00000000 00000000   ...Q.... ........

Hi Dennis.

1. Yes: "vmo -p -o v_pinshm=1".
2. You must have RESIDENT 2 or more for large pages as they must be pinned.
3. The "rsam" pool is in the dynamic segment. You need RESIDENT 2 or more.
4. It doesn't sound like the problem is with the buffer pool but the "rsam" pool. Your BTR is fine anyway.
5. I will leave Art to answer that!

I wasn't sure whether large pages were supported by IDS 11.70 on AIX, but this old forum thread implies they are:
http://old.iiug.org/forums/ids/index.cgi/noframes/read/26661

Can you share an example assert file?

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Art,

What are the two undocumented parameters to tweak?

Unfortunately, LDR_CNTRL with 64K pages did not bring our prod server desired stability, so now I'm going to move forward to 16M pages.

1. Do I need setting v_pinshm=1 for Informix?
2. Provided AIX doesn't page out large pages, why still use RESIDENT to lock segments in memory?
3. We are suffering RSAM pool memory buffer header corruptions. As buffer-header table resides in resident segment of shared memory, does it make sense to allocate large pages for that segment only and thus set RESIDENT=1?
4. While we have Buffer Turnover Rate 5.75/hr, should I enlarge BUFFERPOOL to lower the BTR and buffer-header table access rate as well?
5. BTW, how to lower Bufwaits Ratio for 16K cache?

BUFFERPOOL      default,buffers=3500000,lrus=500,lru_min_dirty=0.20,lru_max_dirty=0.50
BUFFERPOOL      size=4K,buffers=45000000,lrus=500,lru_min_dirty=0.06,lru_max_dirty=0.14
BUFFERPOOL      size=16K,buffers=625000,lrus=500,lru_min_dirty=2.00,lru_max_dirty=5.00

Art Kagel's newratios.ksh output:

Metric Ratio Report For 4K Cache
      Bufwaits Ratio:             1.120000%
        Buffer Turnover Rate:         5.81/hr
        Used Buffer Turnover Rate:    5.81/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr

Metric Ratio Report For 16K Cache
        Bufwaits Ratio:             7.350000%
        Buffer Turnover Rate:         1.63/hr
        Used Buffer Turnover Rate:    1.63/hr
        Experimental BTR #2:          1.08/hr
        Experimental BTR #3:          1.90/hr

Metric Ratio Report Summary For All Caches
        ReadAhead Utilization:      43.200000%
        Bufwaits Ratio:             4.030000%
        Buffer Turnover Rate:         5.75/hr
        Used Buffer Turnover Rate:    5.75/hr
        Experimental BTR #2:          1.04/hr
        Experimental BTR #3:          1.86/hr
        Lock Wait Ratio:            0.00000%
        Sequential Scan Ratio:      1.24000%

https://www.ibm.com/docs/en/informix-servers/14.10?topic=products-ifx-large-pages-environment-variable

https://www.ibm.com/docs/en/aix/7.3?topic=performance-large-pages

You will need RESIDENT 2 or -1 as large pages are pinned.

There is another approach on AIX (not as effective but easier):

export LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

The default is only 4K.

Doug,

Could you please give more details on AIX's large pages?

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

Hi Dennis.

Also, have you allocated huge pages on Linux or enabled large pages on AIX? That might help with your rsam memory block header corruptions.

------------------------------
Doug Lawry
Oninit Consulting
------------------------------


Original Message:
Sent: Thu August 08, 2024 06:12 AM
From: Art Kagel
Subject: Large memory segment vs smaller ones

Dennis:

One segment is better than many, so whenever you see several virtual segments it is best to increase SHMVIRTSIZE to incorporate all of that into a single initial segment unless you know that the increase was caused by an unusual event such as a large session that runs say once a quarter.

Art

------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com