budo with live reload consumed 100% cpu

mattdesl / budo

:clapper: a dev server for rapid prototyping

MIT License

2.17k stars 106 forks source link

budo with live reload consumed 100% cpu #230

Open morganrallen opened 6 years ago

morganrallen commented 6 years ago

Unfortunately I cannot give a ton of detail but after my computer ground to a halt I did manage to get top open to see the node process for budo was pegged at 100%. The only command line argument was --live

As the time of the spike I had just started editing a new file, it was unsaved but would have created a hidden swap file in the same directory as my budo entry file. At the same time I ran npm install --save ... in another tab. The npm install finished at some point but I do not know if it was before or after I killed budo Process had been running for ~20 hours.

Linux 4.15.0-22-generic #24-Ubuntu SMP Wed May 16 12:15:17 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux budo v11.2.2 browserify v16.2.2 watchify v3.11.0

morganrallen commented 6 years ago

I've observed this several times now on two different systems. Running npm install *something* seems to be able to trigger it but I'm unsure if it's consistent.

mattdesl commented 6 years ago

Thanks for testing. I'm not even sure how to go about debugging this, but I'd be happy to look into it further. In the past I've run into memory issues #213 which I attributed to Chrome (due to hundreds of page reloads on WebGL apps), but it may be something in Budo or Browserify instead.

morganrallen commented 6 years ago

I saw that other issue and thought it might be related but not sure. Not really sure how to go about this either, but one of my systems has been locked up for ~30 minutes. I'm letting it keep running to see if I can ssh in or if there are any hints if the usage drops. Otherwise I guess this is just a "let it be known" issue.

mattdesl commented 6 years ago

Are you running budo in production? Never tried ssh with budo, it was more designed to be run locally.

morganrallen commented 6 years ago

No, nothing like that. It's presently locking up my laptop and I'm attempting to SSH in to run top.

morganrallen commented 6 years ago

My laptop gained enough composure to kill the process and recover.

Firefox threw up an unresponsive dialog, unfortunately I was unable to get a stack trace from that.

And this reminded me of why I thought it might be related to #213. The first time this happened, I managed to kill the budo process but Firefox remained unresponsive afterwards.

I've been thinking on ways to debug this issue and if I have time before leaving on vacation I am going to attempt to trigger this inside a VM.