-
-
Notifications
You must be signed in to change notification settings - Fork 19
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
Service Interruption: suspected OOM #19
Comments
Seems that when there's too many (we are saying actually just 10-ish) connections to the Postgres DB, due to the fact that This created an issue on Postgres but the actual root cause is still unknown, as it sounds just not right to persist transaction data in the whole connection lifetime rather than just throw it away after the transaction completed. More investigation required. A workaround (ada2b92) has been implemented as it limits the connection pool size on the backend side to reduce the connection amount been put on Postgres, but the root cause is still remain to be solved. PS: A server-sided connection pool might be used but due to the pool itself is still elapsing a long time I doubt this would be the solution. |
What actually happened on the server? Was the service killed by OOM killer or panicked? However, it's quite interesting and puzzling... |
My opinion would be to check the |
Fixed with |
(investigate today)
The text was updated successfully, but these errors were encountered: