Heya blurry50,

Typically applications will spin up new threads or workers in a pool to take advantage of more CPUs. While having more CPUs typically means you can speed up your tasks, whatever application you're using will have to thread those tasks in parallel to take advantage of the additional CPUs.

If you have a single-threaded application, you may consider increasing your replicas, provided your service is capable of taking on traffic on different instances of your running application.

Hope that helps!

Despite configuring it to use all available CPUs via multiprocessing.cpu_count(), my metrics show the container is using only 1 CPU most of the time, rarely peaking to 2.

The code does spawn multiple processes, and each process handles a batch of simulations. However, it seems that Railway is still not distributing the CPU workload efficiently across all vCPUs.

Could you please clarify:

1. Does Railway support full concurrent CPU usage across all 32 vCPUs in the paid plan?

2. Are there any restrictions we should be aware of when using Python’s multiprocessing in Railway containers?

3. How should we structure our execution to ensure that Railway’s autoscaling or process pooling fully utilizes available cores?

4. Is there a preferred way to monitor how many concurrent processes/threads Railway is actually handling at runtime?

5. Could there be any internal throttling or container sandboxing that limits real-time parallelism?

Thank you for your help — I just want to be sure I'm doing things the right way and making full use of the system’s power.

Have you used railway ssh to debug? I'd start there before diving deeper. We have plenty of customers (indeed using your same use-case) who are utilizing large amounts of concurrent CPU on the platform today.

Let me see if I can answer your specific questions:

1. Does Railway support full concurrent CPU usage across all 32 vCPUs in the paid plan?

Yes

2. Are there any restrictions we should be aware of when using Python’s multiprocessing in Railway containers?

No restrictions. We do limit to 1000 PIDs, but that shouldn't be an issue.

3. How should we structure our execution to ensure that Railway’s autoscaling or process pooling fully utilizes available cores?

Replicas are fully independent container environments. Here's our docs that go into detail about that: https://docs.railway.com/reference/scaling#horizontal-scaling-with-replicas

4. Is there a preferred way to monitor how many concurrent processes/threads Railway is actually handling at runtime?

You're welcome to use whatever monitoring tools you'd like. To start you can railway ssh into your container, and use standard off-the-shelf CLI tools to debug like
ps -eLf
ps -T -p <PID>
top
pstree -p <PID>
perf top -p <PID>
ps aux --sort=-%mem
etc.

5. Could there be any internal throttling or container sandboxing that limits real-time parallelism?

No. Not unless we detect an abuse vector and ban the user. Then we shut down all their containers.

I can't believe it, I already solved it. I deleted the project and recreated it. Because when I created it I did it with the free plan and it seems that when you buy the paid plan it is still limited with the free plan. Even with redeploy.

But thank you anyway, you are very kind!

Ahhhh something strange happened where the project was limited based on the free plan utilization. That was my next stop in debugged (we try to avoid opening customer code if possible).

Glad to hear you solved it, and I'll take some notes to the team about the weird blip you experienced to make sure we can address those kinds of things in the future.