¿Cómo se equilibra la carga del sistema operativo entre múltiples procesos que aceptan el mismo socket?

Question

estoy leyendo la documentación del módulo de clúster en Node.js:
http://nodejs.org/api/cluster.html

que afirma lo siguiente:

Cuando varios procesos son todos accept() ing en el mismo recurso subyacente, el balances de carga del sistema operativo a través de ellos muy de manera eficiente.

Esto suena razonable, pero incluso después de un par de horas de búsqueda en Google, no he encontrado ningún artículo ni nada que lo confirme, ni explico cómo funciona esta lógica de equilibrio de carga en el sistema operativo.

Además, ¿qué sistemas operativos están haciendo este tipo de equilibrio de carga efectivo?

Answer 1

"Equilibrio de carga" es quizás una selección de palabras un poco pobre, básicamente se trata de cómo elige el sistema operativo qué proceso se debe activar o ejecutar después. En general, el planificador de procesos intenta elegir el proceso para ejecutar en función de criterios tales como dar una parte equitativa de tiempo de CPU a procesos de igual prioridad, localidad de CPU/memoria (no rebotan procesos alrededor de la CPU), etc. De todos modos, haciendo búsquedas en Google encontrará muchas cosas para leer sobre los algoritmos e implementaciones de programación de procesos.

Ahora, para el caso particular de accept(), eso también depende de cómo el sistema operativo implementa los procesos de activación que están esperando en accept().

• Una aplicación sencilla es apenas despierta todos los procesos bloqueados en la llamada accept(), y luego dejar que el programador elegir el orden en que llegan a ejecutar.

• Lo anterior es simple pero conduce a un problema de "rebaño atronador", ya que solo el primer proceso tiene éxito al aceptar la conexión, los demás vuelven al bloqueo. Un enfoque más sofisticado es que el sistema operativo despierte solo un proceso; aquí la elección de qué proceso para despertar se puede hacer preguntando al programador, o p. simplemente seleccionando el primer proceso en la lista de bloqueado en aceptar() para este socket. Esto último es lo que hace Linux desde hace una década o más, basado en el link ya publicado por otros.

• Tenga en cuenta que esto solo funciona para bloquear accept(); para accept() no bloqueante (que estoy seguro es lo que node.js está haciendo) el problema se convierte en qué proceso bloquea en select()/poll()/lo que sea para entregar el evento. La semántica de poll()/select() en realidad exige que todos ellos se despierten, por lo que tiene la cuestión del rebaño aullante allí de nuevo. Para Linux, y probablemente de manera similar, otros sistemas con interfaces de sondeo de alto rendimiento específicas del sistema también, es posible evitar la manada de truenos mediante el uso de un único disco epoll compartido y eventos de borde activado. En ese caso, el evento se entregará a solo uno de los procesos bloqueados en epoll_wait(). Creo que, de forma similar al bloqueo de accept(), la elección del proceso para entregar el evento es simplemente para elegir el primero en la lista de procesos bloqueados en epoll_wait() para ese fólder epoll particular.

Así, al menos, para Linux, tanto para el bloqueo de aceptar() y el no bloqueo aceptar() con el borde provocó epoll, no hay programación en sí misma la hora de elegir qué proceso de despertar.Pero OTOH, la carga de trabajo probablemente estará bastante equilibrada entre los procesos de todos modos, ya que, esencialmente, el sistema hará los procesos en el orden en que terminan su trabajo actual y volverá al bloqueo en epoll_wait().