search

risingwavelabs / risingwave

SQL engine for event-driven workloads. Perform streaming analytics, or build event-driven applications, real-time ETL pipelines, and feature stores in minutes. Unified streaming and batch processing. PostgreSQL compatible.
https://www.risingwave.com/slack
Apache License 2.0
6.73k stars 552 forks source link

A more accurate metric for calculating S3 operation cost #10951

Open lmatz opened 1 year ago

lmatz commented 1 year ago

SCR-20230714-ipj

https://grafana.test.risingwave-cloud.xyz/d/EpkBw5W4k/risingwave-dev-dashboard?from=168926058[…]&var-namespace=li0k-nexmark-q16-affinity-heartbeat-2

The metric is supposed to calculate the accumulated cost, i.e. cost in total over a period of time. But it keeps fluctuating, i.e. up and down, which seems abnormal, as accumulated cost should only go up.

Per the dashboard, the cluster keeps running the query continuously and it seems no crashes and no recovery.

The purpose is to calculate the cost in addition to the pure performance metrics such as throughput, to derive the performance-cost effectiveness for Risingwave

cc: @hzxa21 @zwang28

Edit: The compactor restarted. This is likely as we adjust down the memory for compactor to 2GB. But without adjusting max_compactor_task_multiplier from 2 to 1/1.5, it does OOM sometimes.

Edit: Probably just keep the count of operations, and leave cost calculation to the audience as the cost of different object store is different.

github-actions[bot] commented 1 month ago

This issue has been open for 60 days with no activity.

If you think it is still relevant today, and needs to be done in the near future, you can comment to update the status, or just manually remove the no-issue-activity label.

You can also confidently close this issue as not planned to keep our backlog clean. Don't worry if you think the issue is still valuable to continue in the future. It's searchable and can be reopened when it's time. 😄