-
Notifications
You must be signed in to change notification settings - Fork 735
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
High CPU usage #320
Comments
I confirm this issue. |
To me this happened when I was running a query that was returning a lot of data. Can everyone share some information when it happened to them? 🙂 This might help pinning down the problem. |
This is one potential cause: #356. |
@schickling It happens for me (express middleware). |
Can everybody share at least little bit info how to get to this state, because i tried to reproduce it and no luck. |
So far I have not been able to reliably reproduce this. Some potential causes
|
The times I’ve seen it happening I had one or two (max) playgrounds open; I had a few tabs open; some queries may have errored a few times before getting it right. Small schema. |
having this issue as well in v1.4.3 Mac version, at the workplace selection screen, the GraphQL Playground helper is constantly at >20% cpu usage don't blame on electron, I'm using a lot of electron apps like VSCode and GitKraken, all work just fine |
@kambing86 No there is no mining you can see it in network tab.. |
Right, I might have an additional insight on this. I am developing a GraphQL server with I haven't yet checked network traffic etc., to see what's actually going between the two, if anything... |
Hi! I'm having this issue too, with the electron app. The CPU usage raises only when the app window is visible. I don't have context on the project, but I think this could be one of the main issues. |
Thanks for the insights everyone! We're working on the playground performance and will probably have a new release this or next week with some improvements :) |
I can definitely replicate what I wrote in my last comment: as soon as I open PG in Chrome and run a query, the Docker container running the server starts eating 160+% of CPU, and so does PG. If I do what @emibloque said, and just switch tab, the Chrome's CPU usage halves, but the Docker container's one remains the same. The only way to calm the storm is to close the tab where PG is running. |
This issue happens to me as well. Every time I open the playground the CPU start increasing whatever the size of the schema. |
Any news on this, @timsuchanek? This is starting to become a serious issue for me, as it also affects the docker container where Yoga is running, and the machine starts struggling under the excessive CPU usage. |
Noticed the same issue on macOS High Sierra after creating a very simple server with |
I think i figured out what is problem, i will try to make fix for it 👍 Yea i got it playground cpu usage varies with number of rendered editors so we can just render active editor to reduce cpu usage :) |
@HuVik I'm working on a fix for that, which is also including reducing the number of editors. So no need from your side to work on that :) |
Fans start spinning as soon as i open playground in Chrome, (Version 64.0.3282.186) Mac OS High Sierra(10.13.3) |
any update on this? seems like the recent release still suffering, any insight so that we can help to figure out and solve this? |
This also happens on the Electron app for me. |
@timsuchanek I still get this issue with the latest PG in Yoga. |
same here, the playground is pretty much unusable at the moment. I think rendering seems to be the issue as scrolling in a decent size json output is sluggish and not very nice to work with. On large json output (203814 lines), the browser becomes pretty much unresponsive or even gives up. Using something like Altair has no problem, runs the query and the json output in approx 4s and scrolling is smooth. I am using 1.14.1 version of graphql-yoga. Just wondering if this is going to be fixed or should I turn off playground and try and incorporate something else? |
Thanks for your comment @iamgmd ! We can't give a clear timeline right now, but it is definitely something we will work on in the coming weeks. |
@iamgmd your comment was so important to use, that we just released a new version of the react and electron app with a performance that matches the performance of the original GraphiQL and Altair 🙂 You can download the latest electron app here: https://github.com/prismagraphql/graphql-playground/releases/tag/v1.5.9 |
@timsuchanek Middleware express coming soon for Yoga? |
Ah m8, that is sweet and I can confirm that it renders much faster and scrolling is smooth on my 203814 line example. Job well done and now very usable :-) You might be surprised to know I did still manage to break it when running a really really large query (1.6 million lines - 45MB). The result is that the query doesn't display all the lines, only about 3/4 of them and therefore the output is not complete. Altair did manage to display of all the lines but not surprising was sluggish when scrolling. That being said though, it is better to have all the lines whilst sacrificing performance in this use-case. |
I think this happens on high volume subscriptions. The results area gets a lot of results and probably the front end code and/or component is not very optimized. I cannot even scroll to told results, yet the whole browser tab becomes unresponsive. |
"graphql-yoga": "^1.17.4" 100% cpu usage on just open web app |
This is still a problem, why is this issue closed? Opening the playground in the browser causes my mac to slow down noticeably even when not running any queries. Edit: this is with an empty query pane. Literally launching the playground and doing nothing will cause my machine to become laggy. |
Same as @freshtonic web playground slows down my mac (using http://localhost:4466 with an empty query pane) Downloading the app didn't help either: EDIT |
FWIW, I'm not using Docker. |
I can confirm that increasing the query refresh interval in the settings works around the issue. But even with the default settings it doesn't seem like something that should slow down my machine significantly. |
Yes, it's because of schema pooling. This feature runs only on local from the default you can adjust it in settings by changing |
I have put |
Can confirm what @johhansantana said. Disabling polling fixed the CPU issue. I think this may happen when live reload is ON and doing quick iterations. At least, this was my use case. |
Just for refference if someone gets stuck with huge memory consumption. By code first approach it's needed to turn of the polling and the query refresh interval, I wasn't avare of that and my API started to consume more and more memory without an code explanation, simply the polling and refreshing the schema was fault, since it's a reversed approach to development. E: And Playgrounds requiers almost 250MB of memory more then graphiql, to keep a schema alive? |
@huv1k @johhansantana Disabling schema polling worked! THANK YOU! |
Disabling schema polling worked! =) Maybe It is related #653 (comment) |
Setting |
My graphics card’s fans ran full speed when schema polling is enabled. This should be disabled by default, until it’s fixed. Disabling schema polling helps, but so does removing that little animation. |
I ran into this as well. If you want to hide the dot, you can add this style to the page. This custom style will persist through reloads of your server as well.
|
This issue pertains to:
What OS and OS version are you experiencing the issue(s) on?
MacOS High Sierra
What version of graphql-playground(-electron/-middleware) are you experience the issue(s) on?
v1.3.6 (web)
What is the expected behavior?
The Playground should be friendly to my CPU 🤔
What is the actual behavior?
In some scenarios the CPU goes all crazy (sometimes above 80%). I couldn't exactly pin it down to a specific reproducible case but it's happening quite frequently. I suspect the Playground is "trapped" in some kind of infinite loop.
What steps may we take to reproduce the behavior?
Unfortunately I couldn't yet find a clear way to reproduce it. Would be great if other people can add more information!
Update:
I suspect it has something to do with errors (for example when the server returns an error)
The text was updated successfully, but these errors were encountered: