-
Notifications
You must be signed in to change notification settings - Fork 16.3k
Fix memory leak in Client via SSL context creation #57334
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
Conversation
|
@wjddn279 I am working on a fix for the failing tests, do not worry about that one :) |
|
Fix here: #57335 |
amoghrajesh
left a comment
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.
Thanks for the investigation @wjddn279!
A new client is created per task execution, that number could be high in a busy environment. Looks like a nice improvement.
kaxil
left a comment
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.
Awesome stuff @wjddn279 , left minor comments. Once you fix it, will merge it for 3.1.2
c417b1d to
7ca1a48
Compare
|
@kaxil @amoghrajesh Thanks for checking! 👍 |
related: #56641 When I performed the same memray inspection on the latest version that includes both fixes, the first issue was clearly resolved, but the second issue still persists. [memray1.html](https://github.com/user-attachments/files/23160226/memray1.html) When a Client object is created, `ctx = ssl.create_default_context(cafile=ca_file)` continues to be executed repeatedly, which accumulates in memory and causes a memory leak. (It appears to be allocated as a C language object and remains in memory regardless of Python object GC) This PR uses caching to prevent the SSL context object from being recreated. Here are the results after running for two hours with this change. The memory usage, which was previously growing to tens of MBs, now stabilizes at approximately 700KB. [memray2.html](https://github.com/user-attachments/files/23160405/memray2.html) (cherry picked from commit 7369e46) Co-authored-by: Jeongwoo Do <48639483+wjddn279@users.noreply.github.com>
… (#57374) related: #56641 When I performed the same memray inspection on the latest version that includes both fixes, the first issue was clearly resolved, but the second issue still persists. [memray1.html](https://github.com/user-attachments/files/23160226/memray1.html) When a Client object is created, `ctx = ssl.create_default_context(cafile=ca_file)` continues to be executed repeatedly, which accumulates in memory and causes a memory leak. (It appears to be allocated as a C language object and remains in memory regardless of Python object GC) This PR uses caching to prevent the SSL context object from being recreated. Here are the results after running for two hours with this change. The memory usage, which was previously growing to tens of MBs, now stabilizes at approximately 700KB. [memray2.html](https://github.com/user-attachments/files/23160405/memray2.html) (cherry picked from commit 7369e46) Co-authored-by: Jeongwoo Do <48639483+wjddn279@users.noreply.github.com>
related: #56641
@kaxil has addressed the second item in this issue. When I performed the same memray inspection on the latest version that includes both fixes, the first issue was clearly resolved, but the second issue still persists.
memray1.html
When a Client object is created,
ctx = ssl.create_default_context(cafile=ca_file)continues to be executed repeatedly, which accumulates in memory and causes a memory leak. (It appears to be allocated as a C language object and remains in memory regardless of Python object GC)This PR uses caching to prevent the SSL context object from being recreated.
Here are the results after running for two hours with this change. The memory usage, which was previously growing to tens of MBs, now stabilizes at approximately 700KB.
memray2.html
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.