cancel
Showing results for 
Search instead for 
Did you mean: 

How to define the optimal value of SUBSCRIPTION_CACHE_SIZE?

doris_karapici
Participant
0 Kudos
487

Dear SAP community experts,

One important parameter related to the total memory size reserved for caching the provisioning data into each rater and updater is the SUBSCRIPTION_CACHE_SIZE. As this parameter is on both updater and rater, is there any dependency when setting the value of each instance? (for example updater 25MB is not recommended with rater 2GB). Do they depend on each other? What should be a reasonable value of this parameter when dealing with 1M provider contracts?

Any idea how you find the memory size needed for a single provider contract?
I couldn't find any helping information in the tunning guide of SAP CC.

Thank you,
Doris

Accepted Solutions (1)

Accepted Solutions (1)

francois_thimon
Product and Topic Expert
Product and Topic Expert

Hi Doris,

The Tuning guide of CC 5.0 SP 6 does contain a procedure to help determine the required capacity of the subscription cache.
The chapter is entitled "Determining the size of the cached structures":
https://help.sap.com/docs/Convergent_Charging/4c9aeffd94de48f8ba0253b7e1e6e50f/d1b252c7284e4f6eaec57...

It doesn't exactly tell you how to estimate the size of an individual contract, but it describes a procedure to populate a blank database with a sample set of real-looking subscribers, and then to monitor your caches so as to compute the space they occupy. From that, you can deduce the space that will be required for the complete database, once it's fully populated (assuming that your future subscribers keep the same structure as the one you've planned).

Regarding your other question: the rater and the updater process the same subscribers and contracts, but they indeed hold slightly different objects (because the updater needs only what's needed for provisioning activities, while the rater has additional overhead for its charging operations).
So, the capacity required for an updater and for the raters (combined together) is comparable, but slightly larger for the raters.
If you're in doubt, it's consequently safer to run the Tuning guide's procedure separately for each combination of instance type/cache type.
At any moment, you may also use admin+ to monitor the "_CACHE_STATUS" indicators (e.g., SUBSCRIPTION_CACHE_STATUS, GUIDING_CACHE_STATUS), to confirm that your estimations are still valid, and that your instances are never experiencing "victimisation".
Note: "victimisation" is what happens when a cache is insufficiently sized: the instance then has to discard objects from its memory so as to reclaim space and reload other objects from the database. This is particularly costly, performance-wise, and it must be avoided as much as possible.

Can you please let us know if you need more details about all this?

Best regards.

François
SAP Convergent Charging Support

doris_karapici
Participant
0 Kudos

Hi Francois,

thanks a lot for the detailed answer. It really helped me and everyone in the community to understand it better. I somehow overlooked the section on "Determining the size of the cached structures". It is now far way more understandable and helped me a lot with the settings of the SUBSCRIPTION_CACHE_SIZE for the updater and rater.

The SUBSCRIPTION_CACHE_STATUS of the rater was these values. From the Documentation, these show the:

  • vmap: The number of objects removed from the cache because there are not enough slots in the cache
  • vmem: The number of objects removed from the cache because there is not enough memory in the cache

The fact that the vmap is not 0 means that there are objects that are removed from the cache because there is not enough memory slots, but how to interpret this? The SUBSCRIPTION_CACHE_SIZE is too big?



Thank you,
Doris

Answers (1)

Answers (1)

francois_thimon
Product and Topic Expert
Product and Topic Expert

Hi Doris,

Thanks a lot too for your feedback.

As you mentioned, "vmem" refers to the memory, and increases when the cumulated size of the object slots is larger than the available space while, on the other hand, "vmap" refers to the cache's "map", and indicates that there aren't enough available slots to load all your objects.
That "map" is the index used by the cache to reference the objects that are currently held in the memory.
The capacity of this index is therefore the number of "slots" (i.e., the number of objects that can be held simultaneously). It is computed when the cache is initialised, and is the ratio between the configured size of the cache (XX_CACHE_SIZE parameter) and the declared average size of the expected objects (XX_AVERAGE_SIZE for the basic objects, or XX_AVG_XX_SIZE for the session-related objects).

In the documentation, this is described in chapter "Modifying the provisioning cache":
https://help.sap.com/docs/Convergent_Charging/4c9aeffd94de48f8ba0253b7e1e6e50f/30ce9d29c99742e19b9e2...

There, you'll find details about:
- how to declare the expected average size of your objects (i.e., by setting GUIDING_ENTRY_AVERAGE_SIZE, SUBSCRIPTION_OBJECT_AVERAGE_SIZE, or any relevant XX_AVERAGE_SIZE parameter)
- how to monitor the actual average size of your objects ("eavg" column, in the cache status)
- the consequences of having an inadequate average size (either "vmap" or "vmem", depending upon whether your slots are too large/small, numerous/few)

So, to address your current "vmap" issue, you certainly need to adjust SUBSCRIPTION_OBJECT_AVERAGE_SIZE, to get closer to your current "eavg" value, and also make sure that the overall cache size is sufficient to hold all the resulting slots.

Additional note: the caches are also subdivided into "cache instances" (or "sub-caches"). If the settings mentioned above aren't sufficient, you may also need to adjust the XX_CACHE_INSTANCES parameters, to complete your fine-tuning.
Feel free to ask for more guidance if you need to address this situation progressively.

Best regards.

François
SAP Convergent Charging Support