We are using FastAPI version 0.111.0 for our application. The uvicorn server is started as shown below:
uvicorn.run(
"main:app",
host='0.0.0.0',
port=8080,
log_level="DEBUG",
workers=3
)
This works on a Windows machine during our development/test environment. When we deploy this code to the Azure Kubernets cluster, during startup the child process dies.
Error message:
INFO: Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)
INFO: Started parent process [1]
INFO: Waiting for child process [12]
INFO: Child process [12] died
INFO: Waiting for child process [13]
INFO: Child process [13] died
INFO: Waiting for child process [14]
INFO: Child process [14] died
INFO: Waiting for child process [13]
INFO: Child process [13] died
INFO: Waiting for child process [15]
If we remove the workers argument for the uvicoen.run call, the application starts in AKS. I would like to understand, why the child process dies with the workers argument.
I experimented with the request/limit CPU setting for our FastAPI app running with 5 child threads on a small AKS node.
What I noticed is that when the CPU limit value of the pod is too low, the child processes are crashing during initial startup.
In our case (very simple API) I had to put the limit on 400mi (request I kept on 20mi). During 0.5 minute or so, the pod is using then 330mi and once started it drops to 10mi.
Only consistent thing I see happening is that the first spawned child process is still crashing. But that is directly replaced by another child process.
Maybe when you don't specify any limits and the pod is deployed on a node that has insufficient CPU available, it won't get enough too startup correctly.
I also wonder that precompiling the code to pyc may decrease the need for the higher limit.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With