search

douban / greenify

Make blocking C library work with gevent
BSD 3-Clause "New" or "Revised" License
430 stars 58 forks source link

Oracle KPEDBG_HDL_PUSH_FCPTRMAX 11x Enter green_write #19

Open dsuch opened 3 years ago

dsuch commented 3 years ago

Hello,

I use greenify compiled from source code, commit 9bca4dcb9ae096aa9df8df4857691f2ec2745e07, along with SQLAlchemy, gevent and cx_Oracle - all newest versions from PyPI as of today.

I am trying to run 200 concurrent queries using a greenified version of cx_Oracle.

This works as long as I set the pool size not to exceed 11 connections. As soon as I set it to 12 or more, I get the following debug traceback from greenify and the process receives a SIGKILL.

As you can see below, there are exactly 11 Enter green_write entries without a corresponding return entry, such as "write, return 159, errno: 11."

You can also see a KPEDBG_HDL_PUSH_FCPTRMAX message which comes from Oracle - looking around, it is certainly to do with multi-threading but there are no details to be found what it is exactly about.

I wonder what makes greenify enter this code path where it has 11 "Enter green_write" messages and then it receives SIGKILL?

Thanks.

[greenify] [Fri Jan 29 19:51:41 2021] [19875] read, return 41, errno: 11
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] write, return 159, errno: 11
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_read
[greenify] [Fri Jan 29 19:51:41 2021] [19875] read, return -1, errno: 11
[greenify] [Fri Jan 29 19:51:41 2021] [19875] read, return 127, errno: 11
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] write, return 34, errno: 0
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_read
[greenify] [Fri Jan 29 19:51:41 2021] [19875] read, return -1, errno: 11
[greenify] [Fri Jan 29 19:51:41 2021] [19875] read, return 127, errno: 11
KPEDBG_HDL_PUSH_FCPTRMAX[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
[greenify] [Fri Jan 29 19:51:41 2021] [19875] Enter green_write
dsuch commented 3 years ago

Some more info - I added a few more debug calls and the reason why green_write does not return anything is that function "is_not_socket" returns 1, indicating that fd is not a socket.

As far as I can see, the function receives an fd, e.g. -2082384048, but -2082384048 cannot be naturally found in /proc/<pid>/fd and I am now trying to find out where this value of -2082384048 (or any other which is not a socket) comes from.