Is there a channel that still does discussion on i...
# orm-help
r
Is there a channel that still does discussion on issues specifically productions issues related to scalability and stuff with regards to Prisma1
r
Hey @Rashmi Bidanta we don't have a separate channel for that but you could raise any concerns you have here 🙂
r
@Ryan thank you. In our production set up we are running Prisma1 on k8s cluster but the pods keeps restarting every so often. We have debug logging and this is what the last few lines of the log says before the pod gets restarted
Copy code
[DEBUG] #11: Commit
[DEBUG] #1: SimpleJdbcAction
[DEBUG] #1: SimpleJdbcAction
[DEBUG] #1: SimpleJdbcAction
[DEBUG] #1: SimpleJdbcAction
[DEBUG] #1: SimpleJdbcAction
[DEBUG] #1: SimpleJdbcAction
[DEBUG] #1: SimpleJdbcAction
[DEBUG] #1: SimpleJdbcAction
[DEBUG] #1: SimpleJdbcAction
[DEBUG] #1: SimpleJdbcAction
[DEBUG] #1: SimpleJdbcAction
/app/start.sh: line 4:     8 Killed                  /app/bin/prisma-prod
👍 1
Some more details: we are on Prisma
1.28
at this moment
👍 1
e
I'll contribute over here, since Rashmi and I are looking at the same issue. The pods are being killed due to the probe (which is simply accessing
/
via http) fail due to connection refused and occasionally connection timeout. I suspect we are saturating the http connection pool, but I haven't been able to get visibility into that to confirm it. That's where I had been hopeful there were some way to expose prometheus metrics that would also communicate the connection pool state.
👍 1
We had previously ran into issue with the task queue being full and requests being rejected, but we've increased the resources to our database, then increased the database connection limit, and scaled out the number of pods and haven't seen the exceptions for the queue being full since.
👍 1
r
Thanks a lot for jumping in @Ervin Rashmi could you try this method and see if it works?
r
@Ryan Ervin and me are in the same team supporting the same graphql platform with apollo and prisma. What we are seeing is that there are instances when the probes, we have, receive connection timeout from Prisma server the K8s cluster thinks that the prisma server is in a bad state and then it restarts the server. earlier the default connection pool was 9 I believe cause we had 4 core cpu. With that setting we were getting
Copy code
"exception":"java.util.concurrent.RejectedExecutionException: Task slick.basic.BasicBackend$DatabaseDef$$anon$2@6747976d rejected from slick.util.AsyncExecutor$$anon$2$$anon$1@736c10d2[Running, pool size = 9, active threads = 9, queued tasks = 1000, completed tasks = 37987088]"
I think this is how
SLICK
library actually works. Hence we increased the connectionLimit in our prisma-config.yml
Now we are seeing Prisma probably gets into a state where it responds with connection timeouts and the requests are getting stalled until the pod is restarted. So we were hoping to get some direction with this issue
r
Sure @Rashmi Bidanta I'll get back to you on this!
🙏🏽 1
h
Slick library has a bug which was causing connection pool saturation. It is fixed in later versions of Prisma.
Also, in later version you can increase the queue size of Prisma
r
@Harshit thanks for this information
do you know any specific version we should be upgrading to?
we are currently on Prisma version 1.28
h
👍🏽 1
r
It would also be helpful if you could share the information on how to increase the queue size of prisma
h
You are on 1.28 so that means you should get 1.30.5
r
yeah that makes sense
does 1.30.5 has the ability to increase prisma queue size?
h
Yep, 1.30.3 introduced the change so 1.30.5 has it
r
cool cool
is this a configuration in prisma-config.yaml?
h
Default is 1000, you can increase it to like 8000
r
awesome let me check that out
We will try these recommendation in our lower environments and see how things are going
thank you @Harshit for this information
@Harshit is there anything we need to do for the rabbitmq when we upgrade prisma setup
h
No, use the same rabbit url. No changes required there 🙂
👍🏽 1
r
@Harshit We did upgrade our prod instance to 1.30.5 but our prisma deploy scripts are not going through. This is preventing us from doing any new upload. The response to prisma deploy --force --no-seed is
Copy code
Creating stage prod for service app-name... !
error	21-Apr-2020 17:19:43	
error	21-Apr-2020 17:19:43	ERROR: Whoops. Looks like an internal server error. Search your server logs for request ID: local:ck9aj51yf01220852j6lcdd33
error	21-Apr-2020 17:19:43	
error	21-Apr-2020 17:19:43	{
error	21-Apr-2020 17:19:43	  "data": {
error	21-Apr-2020 17:19:43	    "addProject": null
error	21-Apr-2020 17:19:43	  },
error	21-Apr-2020 17:19:43	  "errors": [
error	21-Apr-2020 17:19:43	    {
error	21-Apr-2020 17:19:43	      "message": "Whoops. Looks like an internal server error. Search your server logs for request ID: local:ck9aj51yf01220852j6lcdd33",
error	21-Apr-2020 17:19:43	      "path": [
error	21-Apr-2020 17:19:43	        "addProject"
error	21-Apr-2020 17:19:43	      ],
error	21-Apr-2020 17:19:43	      "locations": [
error	21-Apr-2020 17:19:43	        {
error	21-Apr-2020 17:19:43	          "line": 2,
error	21-Apr-2020 17:19:43	          "column": 9
error	21-Apr-2020 17:19:43	        }
error	21-Apr-2020 17:19:43	      ],
error	21-Apr-2020 17:19:43	      "requestId": "local:ck9aj51yf01220852j6lcdd33"
error	21-Apr-2020 17:19:43	    }
error	21-Apr-2020 17:19:43	  ],
error	21-Apr-2020 17:19:43	  "status": 200
error	21-Apr-2020 17:19:43	}
error	21-Apr-2020 17:19:43	
error	21-Apr-2020 17:19:43	Get in touch if you need help: <https://www.prisma.io/forum/>
error	21-Apr-2020 17:19:43	To get more detailed output, run $ export DEBUG="*"
error	21-Apr-2020 17:19:43	npm ERR! code ELIFECYCLE
error	21-Apr-2020 17:19:43	npm ERR! errno 1
error	21-Apr-2020 17:19:43	npm ERR! app-name@1.0.0 prisma-deploy-force: `prisma deploy --force --no-seed`
error	21-Apr-2020 17:19:43	npm ERR! Exit status 1
error	21-Apr-2020 17:19:43	npm ERR! 
error	21-Apr-2020 17:19:43	npm ERR! Failed at the app-name@1.0.0 prisma-deploy-force script.
error	21-Apr-2020 17:19:43	npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
The deploy seems to be timing out. We have upgraded the bamboo node as well to use prisma 1.30.5 cli, but we are still getting that error
h
What does the error log say?
r
Hi @Harshit
Let me get you the error log
do you mean the prisma log?
Copy code
java.util.concurrent.TimeoutException: Futures timed out after [50 seconds]
this is what the prisma logs are saying
@Harshit we realized that there were a lot of select queries that were blocked on the database for some reason. Which resulted in DDL query for adding schema changes to timeout. We will try to deploy the changes again today. However we are still not clear what might have caused the select queries to have been blocked.