After our production release we have a problem handling big traffic logs from appwrite container:
TypeScript
[Error] Timestamp: 2023-10-10T08:04:18+00:00
[Error] Method: GET
[Error] URL: /v1/databases/:databaseId/collections/:collectionId/documents/:documentId
[Error] Type: PDOException
[Error] Message: SQLSTATE[HY000] [1040] Too many connections
[Error] File: /usr/src/code/app/init.php
[Error] Line: 700
[Error] Timestamp: 2023-10-10T08:04:19+00:00
[Error] Method: GET
[Error] URL: /v1/databases/:databaseId/collections/:collectionId/documents
[Error] Type: PDOException
[Error] Message: SQLSTATE[HY000] [1040] Too many connections
[Error] File: /usr/src/code/app/init.php
[Error] Line: 700
[Error] Timestamp: 2023-10-10T08:04:19+00:00
TL;DR
The support thread discusses an error message: "SQLSTATE[HY000] [1040] Too many connections" that occurs when handling big traffic logs from the Appwrite container. The user considers passing the variables through compose variables or adding them to the .env file. They also mention four variables to try fiddling around with: _APP_CONNECTIONS_MAX, _APP_POOL_CLIENTS, _APP_SERVER_MULTIPROCESS, and _APP_WORKER_PER_CORE, with a corresponding GitHub link. Unfortunately, no solution is provided in the thread.You can try fiddling around with:
- _APP_CONNECTIONS_MAX
- _APP_POOL_CLIENTS
- _APP_SERVER_MULTIPROCESS
- _APP_WORKER_PER_CORE
these are not present in documentation - should I just put them into .env file?
nvm just pass them through compose variables
Recommended threads
- I'm getting an error on the console "j?....
On my self hosted instance version 1.8.1 the console is giving me this error when trying to view the rows for a table I recently created. My application is read...
- Websites hosted on my appwrite sites hav...
Hello, all my websites hosted on appwrite sites are not running I am getting this message "This site can’t be reached drivehub.appwrite.network took too long t...
- Database Write Limits hit
Hello Appwrite Admins, I'm a GitHub Education user, and about a week ago, my database was really badly optimized, resulting in about 600k writes in a single day...