Fair question. In their view, 25 threads per user is a sensible limit. Their mindset is based around single-threaded PHP. And for that reason among others, yes, switching providers is definitely something I will pursue. But that will be a long-term effort. Right now I'm looking for a short-term solution to get my site back up.
Thanks, Steve On Thu, Feb 1, 2024 at 8:34 AM Steven Hartland <stevenmhartl...@gmail.com> wrote: > To be honest I would question if its a usable solution if they are > limiting that low on threads, so is the fix to switch or have the provider > increase the limit to a sensible number? > > On Thu, 1 Feb 2024 at 16:08, Steve Roth <st...@rothskeller.net> wrote: > >> Thanks to the people who suggested how to limit the number of apparent >> cores. Unfortunately, doing that didn't solve the problem. I have the >> number of cores now limited to two — confirmed by checking runtime.NumCPU() >> — but the program is still trying to allocate more than 25 threads, and >> crashing when cgroups won't let it. >> >> Surely there must be some way to get a Go program to run successfully in >> an environment with process limits? Any further suggestions would be >> greatly appreciated. >> >> Regards, >> Steve >> >> >> On Wed, Jan 31, 2024 at 6:43 PM Steve Roth <st...@rothskeller.net> wrote: >> >>> I am running Go code on a shared web hosting server from a major hosting >>> company. Using cgroups, they limit the number of threads any user can >>> create to 25. Up until a week ago, they had me running on a server with 24 >>> cores, and everything worked fine. Now they've moved me to a new server >>> with 128 cores. The Go runtime thinks it should be able to create that >>> many threads, and it can't, and all of my Go programs crash with, "runtime: >>> failed to create new OS thread". >>> >>> Setting GOMAXPROCS doesn't help this, since it only controls the number >>> of active threads, not the total number of threads. The Go runtime still >>> thinks it can create as many threads as there are cores, and crashes the >>> program when it's blocked from doing so. >>> >>> Is there any way around this? Or is Go just completely unusable in an >>> environment where the per-user process limit is less than the number of >>> cores? >>> >>> Many thanks, >>> Steve >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAAnpqKEzZcFxDkG2Qtzf25hPwkZq2EstbDbYtBz4CtTaBQxqWA%40mail.gmail.com >> <https://groups.google.com/d/msgid/golang-nuts/CAAnpqKEzZcFxDkG2Qtzf25hPwkZq2EstbDbYtBz4CtTaBQxqWA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAAnpqKH%2BpawFZ2uqC0-wZm2vidngmePhS_%3Dgqfh9iwKPyN%2Bdcg%40mail.gmail.com.
