I upgraded from Meteor 1.8 to 1.11. I’m facing one issue. A particular activity runs very slowly on my production server if I use node v12.18.3 on production. But this activity runs properly on development machine. Also on production machine if instead I use node v12.0.0, this activity runs properly.
I believe meteor 1.11 uses node v12.18.3, so why I’m facing this issue?
As regards the activity, it open 200 ssh connection to different machines in my network and extracts data from them. I use async.parallelLimit to carry out 200 operations in parallel. When I use node v12.18.3 on production machine, when this activity is going I can see node process hogging 100% CPU continuously. But with node v12.0.0, CPU crosses 100% for a very small time.
Any idea what could be wrong?
1 Like
Just to add problems seems to be on CentOS 8.2. On Ubuntu 20.04, the meteor build is working fine. Is there some bug in meteor 1.11 on CentOS 8.2 or some other issue?
This isn’t a long term solution, but you can use whatever node version (from the same major) you want in production. Install 12.0.0 on your server and use it to run the built meteor app
This should at least mean you can keep working while a more permanent solution is found
Oh and Meteor 1.11.1 with Node 12.18.4 was just released, maybe the patch update won’t have the same issue?
2 Likes
I had this issue earlier as well when I was trying to update to Meteor 1.10. I suspect its a bug in meteor on CentOS that it doesn’t work when we try to schedule large number of asynchronous tasks in parallel with async library or something like that. I had pointed out the bug on github, but it was not taken up.
I could use node v12.0.0 on CentOS, but if the bug is not fixed, I might end up in trouble if future updates in meteor break anything in node v12.0.0.
1 Like