-
Notifications
You must be signed in to change notification settings - Fork 590
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow configuring number of vnode per streaming job #15900
Comments
What's the current behavior of creating a materialized view with default parallelism in a cluster that has more than 256 CPUs? e.g. is it that more than 256 actors will be created but only 256 of them is actually working |
The parallelism was intended to be limited by the vnode count of 256, but there appear to be some edge cases. I will address that. 😄 risingwave/src/meta/src/rpc/ddl_controller.rs Lines 1316 to 1324 in 1e84852
|
Not resolved but only workarounded by #15941. Thus reopen. |
Time to work on this! |
It's worth mentioning that the
|
To achieve this, it appears that we are essentially providing support for different vnode count for different jobs. Then doing joins on these MVs can be tricky: we need to reimagine the A simpler approach is to always treat old clusters with unmodifiable 256 vnodes. Then only fresh clusters can benefit from this change. Note that the value still remains immutable after the cluster initializes. |
Test plan:
|
Test is added in #19250. I believe we can close this issue now. 💋 |
In #3579, we discussed whether to adopt a vnode number other than 256 to achieve a better balance between scanning performance and maximal parallelism in a cluster. For quite some time afterwards, we find 256 works pretty well so the task was postponed.
Recently, we have observed some users running a RisingWave cluster with thousands of cores. While this is exciting, the performance of a single streaming job is unsurprisingly limited by the hardcoded vnode count of 256. I think instead of diving into the possibility of runtime dynamic or per-job vnode count,
a low-hanging fruit could be allowing users configuring the vnode count on cluster startup as an immutable system parameter.Thanks to #6513 and #8385, this seems to be made easy. However, it's still worth noting that the vnode count is limited by the algorithm of row-id generator since #9135.UPDATE: decide to support per-job vnode count, so that...
The text was updated successfully, but these errors were encountered: