Since we won't auto-scale, we need to experiment with resource allocation for main and scholarly_articles graphs on the same tainted nodes.
The QLever team recommends starting by giving the databse a number of threads that is 2x the cores available. We need to validate how this maps to k8s.
Internal and external traffic patterns are significantly different, both in terms of query classes (latencies) as well as throughput (internal scholarly endpoint serves 2 orders of magnitude more requests than external ones). We expect to end up with different constraints and configs.
Goal:
- We should test and document our choices, and have a process in place for periodic review.
- Set qlever memory request == limit so each pod gets a non-overcommitted,
eviction-safe memory footprint instead of a Burstable 32Gi->100Gi (main)
- Increase number of replicas to > 1 in both datacenters.
Questions:
What is a good partitioning (memory/cores) for main and scholarly dbs running on the same node?