[erlang-questions] My frustration with Erlang

Valentin Micic valentin@REDACTED
Sun Sep 14 17:14:50 CEST 2008


> Long before threading models came into vogue, multiple processes
> were taking advantage of multi-CPU systems simply by letting 
> the OS scheduler choose which CPU on which to run the next
> runnable process.

Well... a single process would never exceed a capacity of a single CPU. Therefore, if you had, say, 4 CPUs, one process shall never exceed more than 25% of the overall system capacity. In a case of SOLARIS, this may be true even if you create multiple threads (e.g. if thread were created as bound threads, they will still be scheduled using the same light-weight process, but that is another matter alltogether).

> Since Erlang threads are "green" threads, they don't individually use
> the threading model of the underlying operating system anyway.
> Each VM, other than for I/O operations on files (controleld by +A, I believe),
> uses AFAIK one O/S thread per scheduler. So +S 8 will use 8 O/S threads.
> When you have 8 threads sharing something (which they will when running SMP),
> there is a risk of contention slowing things down.


That is why I'm saying that one should look at the code, and ensure that code is written to take advantage of SMP environment. If you going to use SMP machine and then use it as a "normal" multi-CPU machine, you would be better off staying with a multi-CPU machine which has a faster clock. 
In my experience so far, one should stay clear from servers that are doing a lot of processing per request -- clock is slower, clearly indicating that server will be slower, and yet we have more schedulers resulting in more requests being generated. One may experiment with different priorities and change server to higher priority, which is, I suspect, what one should do for the code that was written for non-SMP machines. My preference, however, would be to write another kind of server, that would spawn a new process for each request, which will in turn report back to the caller bypassing the server.

V.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080914/9e6e1727/attachment.htm>


More information about the erlang-questions mailing list