Impacto de cientos de subprocesos inactivos

Question

Estoy considerando el uso de potencialmente cientos de subprocesos para implementar tareas que administren dispositivos a través de una red.

Esta es una aplicación C++ que se ejecuta en un procesador powerpc con un kernel de Linux.

Después de una fase inicial cuando cada tarea realiza la sincronización para copiar datos del dispositivo en la tarea, la tarea queda inactiva, y solo se activa cuando recibe una alarma o necesita cambiar algunos datos (configuración), que es raro después de la fase de inicio. Una vez que todas las tareas lleguen a la fase "inactiva", espero que solo unas pocas por segundo deberán activarse.

Entonces, mi principal preocupación es que si tengo cientos de hilos, ¿tendrán un impacto negativo en el sistema una vez que estén inactivos?

Gracias. Amso

edición:
estoy actualizando la cuestión sobre la base de las respuestas que me dieron. Gracias chicos. Parece que tener una tonelada de hilos en ralentí (IO bloqueado, esperando, durmiendo, etc.), per se, no tendrá un impacto en el sistema en términos de capacidad de respuesta. Por supuesto, gastarán dinero extra para la pila de cada hilo y los datos de TLS, pero eso está bien siempre que arrojemos más memoria a la cosa (haciéndolo más €€€)

Pero entonces, otros problemas deben ser contabilizados para. Tener cientos de subprocesos esperando probablemente aumente el uso de memoria en el núcleo, debido a la necesidad de colas de espera u otros recursos similares. También hay un problema de latencia, que parece no determinista. Para verificar la capacidad de respuesta y el uso de memoria de cada solución, se debe medir y comparar.

Finalmente, la idea de cientos de subprocesos que estarán mayormente inactivos se puede modelar como un grupo de subprocesos. Esto reduce un poco la linealidad del código, pero aumenta drásticamente la escalabilidad de la solución y, con un cuidado apropiado, se puede ajustar fácilmente para ajustar el compromiso entre el rendimiento y el uso de los recursos.

Creo que eso es todo. Gracias a todos por su entrada.

-
Amso

Answer 1

Cada hilo tiene cabeza - lo más importante cada uno tiene su propia pila y TLS. El rendimiento no es un gran problema ya que no obtendrán ningún corte de tiempo a menos que realmente hagan algo. Es posible que aún desee considerar el uso de grupos de hilos.

Answer 2

No soy un hacker de Linux, pero suponiendo que la programación de subprocesos de Linux es similar a la de Windows' ...

Sí, por supuesto, el habrá alguna impacto. Cada bit de memoria que consuma potencialmente tendrá algún impacto en.

Sin embargo, en un entorno de división de tiempo, los subprocesos que se encuentran en un estado Esperar/Suspender/Suscribir no consumirán ciclos de CPU hasta que se despierten.

Answer 3

Me preocuparía ofrecer mapeos de conexiones de hilos 1: 1, por lo menos porque te deja bastante expuesto a ataques de denegación de servicio.(pthread_create() es una operación bastante costosa en comparación con una llamada a accept())

EboMike ya ha respondido directamente a la pregunta, siempre que los hilos estén bloqueados y no estén ocupados, esperando que no consumirán mucho en cuanto a recursos aunque ocupará memoria e intercambiará para todo el estado por hilo.

Answer 4

Principalmente utilizarán el espacio de direcciones y la memoria para las pilas; una vez que obtienes, digamos, 1000 hilos, esto se vuelve bastante significativo ya que he visto que 10M por hilo es típico para las pilas (en x86_64). Es cambiante, pero solo con cuidado.

Si tiene un procesador de 32 bits, el espacio de direcciones será la principal limitación una vez que llegue a 1000s de hilos, puede agotar fácilmente el AS.

Usan memoria del kernel, pero probablemente no tanto como el espacio de usuario.

---

Editar: por supuesto, los hilos comparten el espacio de direcciones entre sí solo si están en el mismo proceso; Estoy asumiendo que lo son.

Answer 5

Estoy aprendiendo los conceptos básicos del kernel ahora. No puedo darle una respuesta específica todavía; Todavía soy un novato ... pero aquí hay algunas cosas para que puedas masticar.

Linux implementa cada subproceso POSIX como un proceso único. Esto creará sobrecarga como otros han mencionado. Además de esto, su modelo de espera parece defectuoso en cualquier forma que lo haga. Si crea una variable condicional para cada hilo, entonces creo (basado en mi interpretación del sitio web a continuación) que en realidad estará gastando mucha memoria del kernel, ya que cada hilo se colocaría en su propia cola de espera. Si, en cambio, divide los hilos para cada grupo de subprocesos X para compartir una variable condicional, entonces también tiene problemas porque cada vez que la variable señala, debe activar _EVERY_DARN_PROCESS_ en la cola de espera de esa variable.

También asumo que necesitará hacer algún objeto que comparta una sincronización. En este caso, su código puede ser más lento debido a la necesidad de activar todos los procesos que esperan un recurso, como mencioné anteriormente.

Sé que esto no fue de mucha ayuda, pero como he dicho, soy un novato de kernel. Espero que haya ayudado un poco.

http://book.chinaunix.net/special/ebook/PrenticeHall/PrenticeHallPTRTheLinuxKernelPrimer/0131181637/ch03lev1sec7.html

Answer 6

no estoy seguro de lo que "dispositivo" que está hablando, pero si es un descriptor de archivo, me gustaría sugerir que se mire empezando a migrar al uso ya sea sondeo o epoll (Id sugieren el último da la descripción de qué tan activo espera que sea cada descriptor de archivo). De esta forma, podría usar un proceso que sería responsable de todos los fds.