-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
[improvement](jdbc catalog)Optimize JDBC Catalog refresh to reduce frequent client creation. #40261
Conversation
…equent client creation.
Thank you for your contribution to Apache Doris. Since 2024-03-18, the Document has been moved to doris-website. |
run buildall |
TPC-H: Total hot run time: 49349 ms
|
TPC-DS: Total hot run time: 212666 ms
|
ClickBench: Total hot run time: 30.7 s
|
Load test result on machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
|
run buildall |
TPC-H: Total hot run time: 48837 ms
|
TPC-DS: Total hot run time: 212065 ms
|
ClickBench: Total hot run time: 31.41 s
|
Load test result on machine: 'aliyun_ecs.c7a.8xlarge_32C64G'
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
In the previous JDBC Catalog refresh behavior, each refresh would close and recreate the JdbcClient. During this process, we observed that some JDBC drivers create classloader-level shared threads when the JdbcClient is repeatedly instantiated. These threads cannot be garbage collected. Since we use the JdbcClient as the context class loader for the JDBC driver, frequent creation leads to a buildup of non-recyclable shared threads in the JVM. This PR changes the refresh behavior to update the cache only, rather than recreating the client. Recreating the client is unnecessary when the Catalog configuration has not changed.