You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please answer these questions before submitting your issue.
In order to accurately debug the issue this information is required. Thanks!
What version of JDBC driver are you using?
3.22.0
What operating system and processor architecture are you using?
Linux x64
What version of Java are you using?
amazoncorretto:17.0.7
What did you do?
We have an Arrow Flight SQL service (Arrow 14.0.0) that allows users to execute SQL queries and we're currently using the (shaded) Snowflake JDBC driver to execute the query, convert the results into Arrow, and stream the results back. We're currently using -Dio.netty.maxDirectMemory=0 -Xms4G -Xmx4G -XX:MaxDirectMemorySize=2G and limiting our pods at 9G of ram, but we're still hitting the k8s OOM killer due to excessive use of direct memory.
What did you expect to see?
Our total memory usage should stay at or below 6G
Can you set logging to DEBUG and collect the logs?
I did this but didn't see any logs related to Snowflake's Arrow memory handling
I know our "local" non-shaded Arrow + Netty are respecting our max direct memory limit, so my current hypothesis is that the problem lies in Snowflake's Arrow memory management.
Questons:
Does the shaded Netty library respect Dio.netty.maxDirectMemory=0?
Could Arrow + Netty be competing against their shaded counterparts for direct memory?
Is there a way to pass our BufferAllocator instance to the JDBC driver so all memory management is centralized?
I see that SnowflakeResultSetSerializableV1 has a setRootAllocator method, but it's not immediately obvious how to use this
The text was updated successfully, but these errors were encountered:
When the parameter in shaded code is set then the parameter should be also specified for a shaded package
which means: -Dio.netty.maxDirectMemory=0 -> -Dnet.snowflake.client.jdbc.internal.io.netty.maxDirectMemory=0
Please try and let us know.
For the 3rd question, setRootAllocator is going to be considered a private API in the future, so it should not be used.
Thanks! I tried this in dev but never saw any logs indicating the option had been picked up so I wasn't sure it was working.
Curious, with this setting, would the shaded Netty keep track of its own memory usage separately from the shaded Netty?
For example, if I have -XX:MaxDirectMemorySize=2G, would each Netty use up to 2G for a total of 4G, or would they both somehow be able to tell how much of the direct memory is being used by each other and respect the 2G limit regardless?
Please answer these questions before submitting your issue.
In order to accurately debug the issue this information is required. Thanks!
3.22.0
Linux x64
amazoncorretto:17.0.7
We have an Arrow Flight SQL service (Arrow 14.0.0) that allows users to execute SQL queries and we're currently using the (shaded) Snowflake JDBC driver to execute the query, convert the results into Arrow, and stream the results back. We're currently using
-Dio.netty.maxDirectMemory=0 -Xms4G -Xmx4G -XX:MaxDirectMemorySize=2G
and limiting our pods at 9G of ram, but we're still hitting the k8s OOM killer due to excessive use of direct memory.Our total memory usage should stay at or below 6G
I did this but didn't see any logs related to Snowflake's Arrow memory handling
I know our "local" non-shaded Arrow + Netty are respecting our max direct memory limit, so my current hypothesis is that the problem lies in Snowflake's Arrow memory management.
Questons:
Dio.netty.maxDirectMemory=0
?BufferAllocator
instance to the JDBC driver so all memory management is centralized?SnowflakeResultSetSerializableV1
has asetRootAllocator
method, but it's not immediately obvious how to use thisThe text was updated successfully, but these errors were encountered: