Stuart:

What do you have VP_MEMORY_CACHE_KB set to?

Also, does "onmode -F" remove the unused segments?

Art

Stuart:

What do you have VP_MEMORY_CACHE_KB set to?

Also, does "onmode -F" remove the unused segments?

Art

Stuart:

What do you have VP_MEMORY_CACHE_KB set to?

Also, does "onmode -F" remove the unused segments?

Art

Stuart:

Yes, RALLOC_MODE is a diagnostic setting only used temporarily on advice from tech support to help them diagnose specific suspected memory issues. It has been known to cause memory allocation issues of its own in the past.

You should unset that.

Art

Stuart:

Yes, RALLOC_MODE is a diagnostic setting only used temporarily on advice from tech support to help them diagnose specific suspected memory issues. It has been known to cause memory allocation issues of its own in the past.

You should unset that.

Art

Stuart:

For performance reasons, I do recommend that my clients set VP_MEMORY_CACHE_KB, yes. The reason that I asked is that if you set it to DYNAMIC it can cause memory storms such as you have experienced, but that was only the default setting for a short time and a few v11.70 releases before the default was set to STATIC solving that problem when unset.

For reference, I set my server to:

VP_MEMORY_CACHE_KB 4096,STATIC 

and use that as an initial setting for clients that do not have it set already. You can monitor its use with onstat -g vpcache

This reserves 4MB (1024 4K blocks) from the central memory pool for each CPU VP to use for query processing without having to go to the central pool (as long as that is enough). Any allocations of more memory to process complex queries are still returned to the pool, but that 4MB remains reserved. DYNAMIC mode allows the engine to dynamically increase that reserve which can cause the central pool to become exhausted triggering the addition of more shared segments.

(Note that the documentation says that the setting is the total across all VPs, but that is wrong, it is the setting for each VP.)

Art

Stuart:

Yes, RALLOC_MODE is a diagnostic setting only used temporarily on advice from tech support to help them diagnose specific suspected memory issues. It has been known to cause memory allocation issues of its own in the past.

You should unset that.

Art

Stuart:

For performance reasons, I do recommend that my clients set VP_MEMORY_CACHE_KB, yes. The reason that I asked is that if you set it to DYNAMIC it can cause memory storms such as you have experienced, but that was only the default setting for a short time and a few v11.70 releases before the default was set to STATIC solving that problem when unset.

For reference, I set my server to:

VP_MEMORY_CACHE_KB 4096,STATIC 

and use that as an initial setting for clients that do not have it set already. You can monitor its use with onstat -g vpcache

This reserves 4MB (1024 4K blocks) from the central memory pool for each CPU VP to use for query processing without having to go to the central pool (as long as that is enough). Any allocations of more memory to process complex queries are still returned to the pool, but that 4MB remains reserved. DYNAMIC mode allows the engine to dynamically increase that reserve which can cause the central pool to become exhausted triggering the addition of more shared segments.

(Note that the documentation says that the setting is the total across all VPs, but that is wrong, it is the setting for each VP.)

Art

Stuart:

Yes, RALLOC_MODE is a diagnostic setting only used temporarily on advice from tech support to help them diagnose specific suspected memory issues. It has been known to cause memory allocation issues of its own in the past.

You should unset that.

Art

Stuart:

For performance reasons, I do recommend that my clients set VP_MEMORY_CACHE_KB, yes. The reason that I asked is that if you set it to DYNAMIC it can cause memory storms such as you have experienced, but that was only the default setting for a short time and a few v11.70 releases before the default was set to STATIC solving that problem when unset.

For reference, I set my server to:

VP_MEMORY_CACHE_KB 4096,STATIC 

and use that as an initial setting for clients that do not have it set already. You can monitor its use with onstat -g vpcache

This reserves 4MB (1024 4K blocks) from the central memory pool for each CPU VP to use for query processing without having to go to the central pool (as long as that is enough). Any allocations of more memory to process complex queries are still returned to the pool, but that 4MB remains reserved. DYNAMIC mode allows the engine to dynamically increase that reserve which can cause the central pool to become exhausted triggering the addition of more shared segments.

(Note that the documentation says that the setting is the total across all VPs, but that is wrong, it is the setting for each VP.)

Art

Stuart:

For performance reasons, I do recommend that my clients set VP_MEMORY_CACHE_KB, yes. The reason that I asked is that if you set it to DYNAMIC it can cause memory storms such as you have experienced, but that was only the default setting for a short time and a few v11.70 releases before the default was set to STATIC solving that problem when unset.

For reference, I set my server to:

VP_MEMORY_CACHE_KB 4096,STATIC 

and use that as an initial setting for clients that do not have it set already. You can monitor its use with onstat -g vpcache

This reserves 4MB (1024 4K blocks) from the central memory pool for each CPU VP to use for query processing without having to go to the central pool (as long as that is enough). Any allocations of more memory to process complex queries are still returned to the pool, but that 4MB remains reserved. DYNAMIC mode allows the engine to dynamically increase that reserve which can cause the central pool to become exhausted triggering the addition of more shared segments.

(Note that the documentation says that the setting is the total across all VPs, but that is wrong, it is the setting for each VP.)

Art

Hi Stuart,

Glad to see that the problem was resolved.

During investigations of memory issues, Informix support will often request that RALLOC_MODE be set to POOL.  

While there might be a slight increase in memory usage we have not seen this result in many new segments to be added.

Do you remember when RALLOC_MODE POOL was set within the onconfig file? 

Stuart:

For performance reasons, I do recommend that my clients set VP_MEMORY_CACHE_KB, yes. The reason that I asked is that if you set it to DYNAMIC it can cause memory storms such as you have experienced, but that was only the default setting for a short time and a few v11.70 releases before the default was set to STATIC solving that problem when unset.

For reference, I set my server to:

VP_MEMORY_CACHE_KB 4096,STATIC 

and use that as an initial setting for clients that do not have it set already. You can monitor its use with onstat -g vpcache

This reserves 4MB (1024 4K blocks) from the central memory pool for each CPU VP to use for query processing without having to go to the central pool (as long as that is enough). Any allocations of more memory to process complex queries are still returned to the pool, but that 4MB remains reserved. DYNAMIC mode allows the engine to dynamically increase that reserve which can cause the central pool to become exhausted triggering the addition of more shared segments.

(Note that the documentation says that the setting is the total across all VPs, but that is wrong, it is the setting for each VP.)

Art

Hi Stuart,

Glad to see that the problem was resolved.

During investigations of memory issues, Informix support will often request that RALLOC_MODE be set to POOL.  

While there might be a slight increase in memory usage we have not seen this result in many new segments to be added.

Do you remember when RALLOC_MODE POOL was set within the onconfig file? 

Stuart:

For performance reasons, I do recommend that my clients set VP_MEMORY_CACHE_KB, yes. The reason that I asked is that if you set it to DYNAMIC it can cause memory storms such as you have experienced, but that was only the default setting for a short time and a few v11.70 releases before the default was set to STATIC solving that problem when unset.

For reference, I set my server to:

VP_MEMORY_CACHE_KB 4096,STATIC 

and use that as an initial setting for clients that do not have it set already. You can monitor its use with onstat -g vpcache

This reserves 4MB (1024 4K blocks) from the central memory pool for each CPU VP to use for query processing without having to go to the central pool (as long as that is enough). Any allocations of more memory to process complex queries are still returned to the pool, but that 4MB remains reserved. DYNAMIC mode allows the engine to dynamically increase that reserve which can cause the central pool to become exhausted triggering the addition of more shared segments.

(Note that the documentation says that the setting is the total across all VPs, but that is wrong, it is the setting for each VP.)

Art