Problem with Action Cable

[buithehien1991]

Dear @krschacht

I'm using Nginx + Passenger for server of Rails app and I faced trouble is not receipt message from background job (GetNextAIMessageJob) after AI return message. Thinking circle is endless until F5 page.

I checked at passenger-status and detected problem happen when RAM for cable process is high. Here is 1055MB

I just restart server, everything is OK. But I must restart server everyday.

I also switch adapter from postgresql to redis. It's same. I think problem happen by Passenger, but I don't know which config or how to setup to fix this bug.

If you know this issue, or need more information. please let me know.

[krschacht]

Complicated deployment issues are not my strongest point, but historically when I’ve deployed and scaled rails it’s common to need significant ram per thread/process. It doesn’t sound crazy for a worker jo to need a gig of ram. I think you may just need to allocate more memory to it. It doesn’t surprise me that switching from postgres to redis made no difference on ram. The ram overhead is from the rails stack as opposed to the queue handler.

Another alternative is to try one of the more supported deploys (Heroku, Fly, Render). I’ve done most of my testing across those. They all make it pretty easy to allocate greater resources to your worker pool. I know ngnix is popular but I don’t have much experience with it.

[buithehien1991]

Thank you so much for your comment.

It doesn’t sound crazy for a worker jo to need a gig of ram.

Actually, worker for web is 50 and never used all of them.
But worker for Action Cable is only one even I set it is unlimit

location /cable {
                passenger_app_group_name tda_shopify_action_cable;
                passenger_force_max_concurrent_requests_per_process 0;
        }

You can see detail

Max process is 50. Only used 9
Web can spawn to more process but ActionCable is not. I don't know why

I switched to Puma + Nginx. Now work is Ok, but still need time to know this happen or not.

Again. Thank you so much!

[krschacht]

Oh, I didn’t even notice that you mentioned Passenger. I didn’t know people still used that. Puma definitely seems to be the standard these days. I think eventually Falcon will replace it but probably still a year or so away.

I don’t quite follow the screenshots: do you still have an issue even after switching to Puma or are you saying that all the process stuff no longer has an issue?

There are some really good blog posts I found years ago when I was googling things like “Heroku deciding on processes vs threads for puma”. That is not the exact query, but Heroku in particular has two specific ENV you can set for Puma, I believe it’s WEB_PROCESSES and WEB_THREADS, that’s not quite right. But if you find those ENV and google with puma for those, there are a bunch of blog posts from about ~5 years ago that go in depth on tweaking these pools and helping to understand how they are utilized.

(I mention Heroku because that’s the context where most people have discussed this, but even the Heroku-specific Puma discussions apply to Puma outside of Heroku)