Skip to content
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

monkeypatch kubernetes to avoid ThreadPool problems #169

Merged
merged 2 commits into from
May 7, 2018

Conversation

minrk
Copy link
Member

@minrk minrk commented Apr 26, 2018

kubernetes creates client objects in a number of places e.g. every time a Watch is instantiated.

These objects create a max-size thread pool for async requests, which bogs down the process if enough client objects are instantiated (#165). Since we don't
use async requests, these pool objects go totally unused.

We setup shared clients to reduce the number of client objects created in #128, but there are some places we can't prevent clients from being instantiated (Watches), so the new EventReflector caused a problem in a big way by instantiating N-CPUs threads for every spawn.

To solve this at the root, api_client is monkeypatched to avoid creating these ThreadPools in the first place. A patch has been submitted upstream to swagger-codegen, which is responsible for creating the ThreadPool in the kubernetes client.

Related to #153, which creates a Watch per spawn, so we cannot avoid creating a very large number of ApiClient objects and thereby threadpools without monkeypatching Kubernetes.

The alternative is to go back to pinning kubernetes-3.0.

avoids creating a new client for each reflector
…client

kubernetes creates client objects in a number of places
e.g. every time a Watch is instantiated.

These objects create a max-size thread pool for async requests,
which bogs down the process if enough client objects are instantiated.
Since we don't use async requests, these pools go totally unused.

api_client is monkeypatched to avoid creating these ThreadPools in the first place.
A patch has been submitted upstream to swagger-codegen,
which is responsible for creating the ThreadPool.
@minrk minrk merged commit 54730e7 into jupyterhub:master May 7, 2018
@minrk minrk deleted the mock-kube-pool branch May 7, 2018 13:57
@gweis
Copy link
Contributor

gweis commented May 17, 2018

How about keeping an instance of kubernetes.client.api_client.ApiClient around and passing that into the the specific kubernetes.client.apis.XXX clients? This would get around the many thread pools as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants