Performance Management Q&A
summary
PolarDB reports one-sided RDMA writes of about 4–6 microseconds at 4KB and an experiment showing roughly 44% lower cost per query by cutting required cores from ~13,000 to ~7,800 for a four‑phase retail workload. Memory disaggregation uses a database‑specific LRU for buffer pools rather than OS‑wide policies. Adding a PSP layer adds a few tens of milliseconds but stays local in network topology. BPF GPU profiling runs kernel‑level, low‑overhead sampling but lacks operator/tensor context.
AI-written summary · about
chapters (11)
- 0:00Performance Management Q&A
- 0:34RDMA costs and performance in Polar DB
- 3:09PHP layer latency impact
- 5:16Noisy neighbors in Blade Runner
- 7:05BPF GPU memory profiling benefits
- 8:30Libra Sigma open source plans
- 9:33Finding referenced blog posts
- 9:53Pricing Polar DB pay-as-you-go
- 11:19Memory disaggregation in Polar DB
- 13:05Common performance issues and patterns
- 14:52Closing
related talks
38mEfficient Ceph Performance Troubleshooting in Production Using eBPF
22mPinpoint Ceph Bottleneck Out of Cluster Behavior Mists
01h 00mSystems @Scale Summer Q&A Week 4
39mUsing EBPF to Develop a Powerful Tool for Diagnosing Ceph Performance Issues
34mThe Missing Metrics: Measuring Memory Interference in Cloud Native Systems
21mZero Overhead Monitoring for Cloud-native Infrastructure using RDMA
05mProject Lightning Talk: Spiderpool Unlocks Fine-Grained RDMA Observability for AI Inference
26mProfiling Mastery: Decode Your Data and Elevate Observability