Limiting time data is cached

Answered

Comments

2 comments

  • Avatar
    Moti Granovsky

    Hi Kevin,

    Fantastic analysis and description of your situation!

    There are 4 ways you could approach this issue, and they aren't mutually exclusive:

    1. Separate the build process from the query engine by creating a dedicated build node, which would decrease instances of two parts competing for a limited resource and isolate the builds from the more volatile environment, ensuring that even if a conflict occurs builds will not be impacted.
    2. Create automation to monitor cube usage, and use Sisense APIs to stop or restart cubes that aren't in use. Cubes clear their cache when they are stopped (the entire process is shut down), and they do auto-start when queried. You could achieve this by either listening to JAQL queries incoming to the server or possibly by other means such as monitoring certain logs.
    3. Contact Sisense Support staff to investigate why this conflicts occur - as you've mentioned yourself, generally Sisense will flush the lesser-used cache to make room for new queries, and the issues you're experiencing stem from a conflict in resource management under specific conditions.
    4. Submit a feature request for a configurable cache life per cube

    Thanks,

    1
    Comment actions Permalink
  • Avatar
    Ian Tebbutt

    Hi Moti,

          We also see this issue where a single cube use then hogs memory, you mention 'listening to JAQL queries incoming to the server' - can you give pointers how that could be done?

    Ian

    0
    Comment actions Permalink

Please sign in to leave a comment.