Skip to Main Content
InterSystems Ideas
We love hearing from our users. Tell us what you want to see next and upvote ideas from the community.
* Bugs and troubleshooting should as usual go through InterSystems support.
Status Will not implement
Categories InterSystems IRIS
Created by Yaron Munz
Created on Jun 8, 2023

Specific cache buffers per DB

Today, if we want to make sure a specific database is more in-memory than others, we can built is as a 16K or 32K block size (while all others are the default 8K block size) and then assign an amount of "cache buffers" to 16K block DBs.

I would like to see for ANY database, the ability to have a separate "cache buffers" allocation. This will allow having better control on data that is more frequently used without the need to change the block size (which is sometimes not sutiable for the data structures on that DB)

  • ADMIN RESPONSE
    Apr 23, 2024

    Thank you for submitting the idea. Based on information from our experts the status of your idea was changed to "Will not implement". Please look for details in the comments on the idea. Good luck!

  • Benjamin De Boe
    Reply
    |
    Apr 23, 2024

    Hi Yaron,

    thanks for your suggestion, but we won't be implementing this idea, as it's the kind of super fine grained level of control that is at odds with out general goal of making the product easier to use and decrease the config surface. The LRU cache should work just fine in the vast majority of scenarios.

    This said, there are some low-level enhancements to the cache eviction algorithm in the pipeline, but they're all deep in the kernel and won't introduce any new configuration settings.

    Thanks,
    benjamin

  • Yaron Munz
    Reply
    |
    Oct 25, 2023

    Timo,
    >> "does not have suitable amount of memory available"
    Having "enough" memory for cache buffers is not always possible (not applicable for very large-scale environments that has many databases with hundreds or thousands of terabytes in size) on cloud usually VMs are "tied" to a "family type" (the fact that I "want" 100TB of memory might end with a 1000 cores machne that I don't need and is too expensive).

    In some cases, as mentioned by Dmitry, a specific DB would need 0% buffers (not to be cached at all) but other Db's that might be small (e.g. 100GB) might be accessed very often, hence need a 100% buffers availability.

    Allocating X blocks of buffers to any Db can make wonders with performance (for systems that have complex datasets that are being mapped between many Db's).




  • Admin
    Vadim Aniskin
    Reply
    |
    Oct 23, 2023

    @Yaron Munz, you have comments on your idea. Please answer them to help your idea to be promoted.

  • Dmitry Maslennikov
    Reply
    |
    Jul 4, 2023

    I have a scenario, where I would like to have something like this.

    In a project, I have a lot of streams stored in the database, but the access speed to them is not critical. But, it eats too much memory in buffers, just because it's accessed and. So, it would be nice to be able to rate, how much of buffer can be used by this database, I would cut it to 0. So, only critical data would keep be stored in the buffer, even with less frequency of usage.

  • Timo Lindenschmid
    Reply
    |
    Jul 3, 2023

    I am not sure i understand the issue you are trying to solve here.

    IRIS/Cache caching is always trying to keep the latest accessed block in buffers, only removing the least used block if buffers are needed. So this sounds like you are trying to work around an environment that does not have suitable amount of memory available for the workload its used for. Else your highly accessed data will always stay in memory.