Vladimir Kovac

> Is there any expectation that ARM Linux will be supported in the future? > > The issue makes Sorbet inoperable for a small team like mine developing on ARM...

Btw I'm not sure it has to do with the sheer volume of jobs, i had a colleague queue up like 30k very fast jobs and the same thing happened.

we have our query limit set to 1000 btw

Sure let me add more context, the job in question is just a couple of db reads and db writes, very simple < 1 second each, I don't know how...

Gotcha so yeah it should work like i'm expecting if LISTEN/NOTIFY is working properly, i'm going to have to devise a test to see if that's the case.

Sure the thread count could be changed and that's something we can tweak to get perfect, but i'd expect filling them to be fast regardless. Let's focus on the fetch-and-lock...

I'm still holding out hope that we've just configured something horribly wrong, to get concrete here with these fast running jobs lets say 100k queued up (btw queuing up this...

Even more details: 10 processes, 25 max threads each, and i think 10 puma threads per process configured in rails. Then also pool count is set to 35. And finally...

i just got a huge throughput boost by enqueuing 1000 at a time for the 100k size batch.... something like 4 to 6x which doesn't make a whole lot of...

@bensheldon i can confirm i do get a bump in both throughput and parallel running jobs right as a bulk enqueue finishes. It does make me wonder about the listen/notify...