4 ms·
> Considering a normal-sized Linux server can handle a million threads without much trouble, it really seems like misplaced effort Seems like that would use a
by varajelle 6y ago
> Considering a normal-sized Linux server can handle a million threads without much trouble, it really seems like misplaced effort
Seems like that would use a lot of memory for all the stacks
- oblio 6y agoBased on this, the default value is 2MB: https://unix.stackexchange.com/questions/127602/default-stack-size-for-pthreads https://unix.stackexchange.com/questions/127602/default-stac... So that would mean a lot of memory for 1 million threads, 2TB of RAM. But you can change the default. With a 64k stack you'd use up ~68GB of RAM, which doesn't seem like a lot for 1 million threads and 1 million requests happening at the same time.
- ibraheemdev 6y agoWhat "normal-sized Linux server" has 70GB of RAM?
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- oblio 6y agoOne that wants to handle a million requests per second? Or would you want to do that with a Raspberry Pi? :-) > What "normal-sized Linux server" has 70GB of RAM? Also, why are you "quoting" what I did not say?
- ComputerGuru 6y agoAir quotes.
- ibraheemdev 6y agoI was quoting the parent comment by @akvadrako :)
- akvadrako 6y agoMost servers support at least 128GB; it isn't even very expensive. And if you want to handle a million concurrent users you also need to consider CPU and latency, so for most real-world workloads the memory probably won't even be your bottleneck.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- platinumrad 6y agoAlso worth noting that the entire stack isn't allocated at once so 1 million threads would be using 2TB/68GB of virtual address space, not 2TB/68GB of physical memory.
- spacechild1 6y agoThat is indeed a very important fact to keep in mind! Thread stack sizes have been a problem with 32 bit systems where you quickly run out of virtual memory because the adress space is not large enough. With 64 bit that is not a problem anymore.
- akvadrako 6y agoThat is also the maximum stack size which shouldn't normally be reached. You'll have to be careful how you use memory when you're handling a million clients, either as async or threaded.
- varajelle 6y agoThe point is that each stack need to be big enough for the worst case. That means it does not really scales to start many thousands of threads. While the futures themselves used in async code can be kept relatively small, as they only need to contain the state needed while awaiting.
- gpderetta 6y agoIn theory a smart enough OS (or runtime) should be able to reclaim any memory beyond the stack pointer (plus redzone) at any time without preserving its content and shrink back the stack. Because of signal handlers that memory is to be considered volatile anyway. It might not be worth doing it in practice, but it is something to keep on mind.
- secondcoming 6y agoHow much does a 68GB cost on the cloud per day? Also, you don't have 1 million cores so quite a bit of your daily server costs will be eaten up by the OS running context switching code.
- novocaine 6y agoPending async waits have stacks to preserve too
- Yoric 6y agoIn some languges, that's true. In Rust, however, that pseudo-stack is typically tiny.
- steveklabnik 6y agoThe difference, at least in the way this is built in Rust, is that when you create a task, you get a single allocation that's exactly sized. There's no resizing, which means that you aren't getting stacks that are too big or too small, with all of the other runtime shenanigans that that entails.
- varajelle 6y agoThat said, the future has the size of the biggest state that need to be kept across await. The future might be slightly oversized, but still order of magnitude smaller than a perfectly sized stack.