Re: Como Saber Cuantos Nucleos Tiene Mi Pc Ubuntu
Arnau Cyr
El comando anterior nos mostrar la informacin referente a nuestras CPUs, pero a simple vista no sabemos si lo que nos est enseando es el nmero de CPUs fsicas, el nmero de nucleos, todo mezclado, etc. Para ello, hemos de prestar atencin especialmente a los siguientes campos:
En el ejemplo anterior, vemos como nuestro server tiene 16GB de RAM. Si queremos ver el detalle de cuantos mdulos de RAM tiene el servidor, de cuanta capacidad cada uno, y de qu tipo, podremos usar el comando lshw. Si no tienes el comando instalado, puedes instalarlo con yum. Una vez instalado, bastar con ejecutar, como root, el comando:
As podremos saber si un server tiene algn slot de memoria libre, o qu tipo de mdulo de memoria hemos de comprar para sacarle mayor provecho al servidor, segn los mdulos de RAM que ya tenga instalados.
En esta gua se explicarn conceptos y el tratamiento bsico de procesos / hilos en base a los procesadores / ncleos del sistema. Se mostrar como cambiar de ncleo / procesador un determinado proceso o uno de sus hilos en ejecucin. Tambin se nombrarn varias herramientas para visualizar los hilos en relacin a los procesadores y sus ncleos.
Los procesos suelen ejecutarse dentro de lo que se considera un cpuset, es decir, los conjunto de hilos tienen asignados un conjunto de ncleos donde procesarse. A pesar de eso, puede que los hilos dentro del cpuset vayan cambiando de core o procesador segn necesidad, de esto se encarga el ncleo del sistema operativo. En algunos momentos puede que el manejo del ncleo en cuanto a asignacin de cores / ncleos no sea el ptimo, siendo recomendable cambiar la afinidad para forzar que determinados procesos / hilos se ejecuten siempre en un determinado procesador.
Cuando un proceso / hilo cambia de procesador, este pierde los datos que tena en la cache del otro procesador y puede repercutir en una disminucin del desempeo de la aplicacin. En GNU/Linux se puede hacer uso del comando taskset para consultar y/o fijar la afinidad de determinados procesos y/o hilos.
No todos los procesos hacen uso de hilos de la misma forma, eso depende de como est desarrollada la aplicacin. En muchos casos es necesario especificar que el programa en uso utilice un nmero concreto de hilos, normalmente en base al nmero de procesadores y ncleos disponibles. Tambin hay diferentes tipos de hilos y usos dependiendo del lenguaje de programacin utilizado.
La razn principal de utilizar los threads es aumentar la performance del programa. Los threads pueden ser creados y administrados con menos gastos generales del sistema operativo y menos recursos en el sistema. Todos los threads en un proceso comparten el mismo espacio de direcciones, lo que hace que las comunicaciones entre los threads sean ms eficientes y ms sencillas de implementar que la comunicacin entre los procesos. Por ejemplo, si un thread est esperando que se complete una llamada de entrada/salida del sistema, los otros pueden estar trabajando en las tareas intensivas de la CPU. Con los threads, las tareas importantes pueden ser programadas para que tengan prioridad sobre las tareas de menor prioridad e incluso que las puedan interrumpir. Las tareas poco frecuentes y espordicas pueden ser intercaladas en forma regular entre las tareas programadas, creando de este modo una programacin ms flexible. Y, por ltimo, los pthreads son ideales para la programacin en paralelo en las mquinas con mltiples CPUs.
La programacin de los threads de POSIX brinda muchos beneficios, pero si usted no tiene en claro algunas de las normas bsicas corre el riesgo de escribir un cdigo difcil de depurar y causar fugas de la memoria. Comencemos por revisar los threads de POSIX que pueden serthreads que se pueden unir o threads desunidos.
Si usted quiere producir un nuevo thread y necesita saber cmo es terminado, entonces necesita un thread que se puede unir. Para estos threads, el sistema asigna un almacenamiento privado para guardar el estado de terminacin de los threads. El estado es actualizado despus de que el thread termina. Para recuperar el estado de la terminacin del thread puede hacer lo siguiente.
El sistema asigna almacenamiento subyacente para cada thread, incluyendo la pila, la ID del thread, el estado de terminacin del thread y as sucesivamente. Este almacenamiento subyacente permanecer en el espacio del proceso (y no ser reciclado) hasta que el thread haya terminado y haya sido unido por otros threads.
La mayor parte del tiempo, usted crea un thread, le asigna alguna tarea y luego contina procesando otros asuntos. En estos casos, usted no se preocupa de cmo los threads terminan, y un thread desunido sera una buena eleccin.
Si usted crea un thread que se puede unir pero se olvida de unirlo, sus recursos o su memoria privada se mantienen siempre en el espacio del proceso y nunca son reclamadas. Siempre una los threads que se pueden unir, de no hacerlo, usted corre el riesgo de tener prdidas serias de memoria.
Por ejemplo, un thread en Red Hat Enterprise Linux (RHEL4) necesita una pila de 10MB, lo que significa que se pierde al menos 10MB de memoria si usted no lo ha unido. Supongamos que usted disea un programa en la modalidad de administrador-empleado (manager-worker) para procesar las solicitudes entrantes. Se necesitan entonces crear cada vez ms threads de empleado, desarrollar tareas individuales y luego terminar. Si son threads que se pueden unir y usted no ha llamado a pthread_join() para unirlos, cada thread producido perder una cantidad considerable de memoria (al menos 10MB por pila) despus de su terminacin. El tamao de la memoria perdida aumenta en forma continua a medida que ms y ms threads de empleado sean creados y terminados sin ser unidos. Adems, el proceso no podr crear nuevos threads, ya que no quedar memoria disponible para crearlos.
El listado 1 muestra la prdida grave de memoria ocasionada si usted olvida unir los hilos que se pueden unir. Puede utilizar tambin este cdigo para comprobar la cantidad mxima de grupos de threads que pueden coexistir en un espacio de proceso.
En el listado, pthread_create() es llamado para crear un nuevo thread con un atributo de thread por omisin. De esta forma, el nuevo creado se puede unir. Se crean nuevos threads que se pueden unir sin cesar hasta que la falla ocurre. A continuacin el cdigo de error y la causa de la falla se imprimen.
Como se muestra en el listado 1 y 2, los threads que se pueden unir son producidos, pero nunca unidos, por lo tanto cada thread que se puede unir terminado an ocupa el espacio de proceso perdiendo la memoria de proceso.
Un thread de POSIX en RHEL tiene una pila privada con un tamao de 10MB. En otras palabras, el sistema asigna al menos 10MB de almacenamiento privado por cada pthread. En nuestro ejemplo, 304 threads fueron producidos antes de que el proceso se detuviera; estos threads ocupan 304*10MB de memoria, alrededor de 3GB. El tamao de la memoria virtual para un proceso es de 4GB con una cuarta parte del espacio de proceso reservada para el kernel de Linux . Sume eso y obtendr un espacio de memoria de 3GB para el espacio del usuario. De ese modo la memoria de 3GB es consumida por threads muertos. sta es una fuga de memoria grave. Y es fcil ver cmo sucedi tan rpidamente.
Al igual que con otras fugas de memoria, el problema no puede ser evidente cuando el proceso se ha iniciado. As que sta es una manera de detectar dichos problemas sin necesidad de acceder al cdigo fuente:
En un proceso de ejecucin, la cantidad de pilas de threads es igual a la cantidad de de grupos de threads en el proceso. Los grupos de threads constan de threads activos en ejecucin y de threads inactivos que se pueden unir.
Cada vez que un thread es creado y est en funcionamiento, una entrada se completa en /proc/PID/task. Cuando el thread termina, ya sea que se pueda unir o que sea individual, la entrada es eliminada de /proc/PID/task. De este modo la cantidad de threads activos se puede obtener mediante la ejecucin de:
Cuando se ejecuta un programa en Linux, se carga una instancia de ese programa en la memoria junto con todos los recursos que necesita. Esta instancia del programa en la memoria se llama proceso. Los procesos de Linux, especficamente los pesados (HWP), incluyen una gran cantidad de sobrecarga cuando se crean o conmutan desde otro proceso. Al contrario, un hilo es un proceso ligero (LWP) en un sistema operativo informtico. Puede compartir recursos como cdigo, datos, E/S de archivos, pila y tablas de seales. Eso es lo que los hace ligeros. A diferencia de los procesos, los hilos no necesitan vaciar y recrear todas las tablas antes de que se puedan conmutar. Por lo tanto, se pueden cambiar con ms facilidad y frecuencia.
Sin embargo, Linux no distingue entre un proceso y un hilo a nivel del sistema operativo. Los hilos siguen siendo procesos en Linux. Solo los hilos pueden compartir ciertos recursos con otros procesos. A diferencia de otros sistemas operativos, Linux no proporciona estructuras de datos de hilos ni opciones de programacin especficas. El kernel no hace distincin aqu.
Sin embargo, los hilos o procesos ligeros todava se pueden utilizar en Linux para lograr el paralelismo y el procesamiento de varios ncleos al dividir un proceso en varios hilos. De esta manera, cada hilo se puede ejecutar en un ncleo del procesador separado para lograr un verdadero paralelismo. Debido a que los procesos ligeros ya son tan ligeros en Linux, el cambio entre hilos no genera grandes sobrecargas.
Como cualquier sistema operativo, existen ciertos lmites para los subprocesos en Linux. Linux almacena las configuraciones como archivos y la mayora de los parmetros de configuracin del kernel se almacenan en la ruta /proc/sys/kernel/. La configuracin para el nmero mximo de subprocesos que el kernel puede ejecutar se almacena en proc/sys/kernel/threads-max.
Al utilizar el comando command en este archivo, se mostrar el nmero mximo de hilos para el sistema. En la figura 1, el nmero mximo de hilos es 3.935. Esto se ejecut en un servidor de ncleo nico utilizado para alojar un sitio web esttico, por lo que el nmero mximo de hilos es bajo en comparacin con los procesadores de varios ncleos:
d3342ee215