Energy Efficiency Evaluation of Local and Offloaded Data Processing
- 1. Energy Efficiency Evaluation of Local and Offloaded Data Processing Victor Prokhorenko, Muhammad Ali Babar
- 2. Cyber-foraging • Borrow and utilise resources more efficiently – CPU – Storage • Latency considerations • Privacy considerations • Energy considerations – Send – Wait for processing to complete – Receive
- 3. Databases • MongoDB – JSON-like document oriented • Redis – In-memory key-value storage • Cassandra – Wide-column store • MySQL – Traditional relational SQL database
- 4. YCSB - Yahoo! Cloud Serving Benchmark • Java-based extensible workload generator • Multiple database plugins – Over 40 NoSQL, SQL and JDBC-enabled databases • Multiple parameters – Number of records – Number of operations – Data distribution – Record size – Record contents
- 5. Core Workloads • Workload A - Update heavy workload ● 50% read, 50% write • Workload B - Read mostly workload ● 95% read, 5% write • Workload C - Read only • Workload D - Read latest workload • Workload E - Short ranges • Workload F - Read-modify-write
- 6. Core Workloads - Sequence • Generate and load data into the database • Workload A • Workload B • Workload C • Workload F • Workload D (Changes number of records in the database) • Flush database contents • Load generated data into the database • Workload F
- 7. Energy measurement • CPU on the client side • Server side energy is considered “unlimited” • RAPL technology • Software model developed by Intel • High precision • Provides readings in Joules
- 8. Experimental Setup: Hardware • Regular laptop (Mid-range CPU) • Powerful node (High-end CPU) • Cloud infrastructure
- 9. Experiment setup: scenarios • Close proximity – 1.5ms • Long distance – 50ms
- 10. Local processing
- 12. Local vs. close-proximity offloading (mid-range CPU)
- 13. Local vs. close-proximity offloading (high-end CPU)
- 14. Power consumption for workload A vs. threads
- 15. Conclusion and lessons learnt • Redis is very intolerant to high latency • Redis is unsuitable for workload E (short ranges) • Data offloading only makes sense under two conditions • Weak local CPU and significantly more powerful remote CPU • Low network latency • RAPL readings may overflow quickly on powerful CPUs (~20 minutes) • 100% CPU utilisation is not achieved by all databases • Network transmission and encryption overheads are negligible (~2%)
- 16. Future work directions and enhancements • Other CPU architectures and types (AMD, ARM) • Fine-grained measurements Rest of system energy usage tracking – RAM – Disk – Rest of the system • Consider other Operating Systems – OS-specific configuration tweaking • Tweaking databases configuration parameters
- 17. CRICOS 00123M