RESUELTO problema de rendimiento

Rafa Grimán

12 May 2006 12 May '06

10:41

Hola :) Pues eso, que ya he resuelto el problema de rendimiento que tenía al hacer los benchmarks. Resumo el hardware: - 16 CPUs - 32 GB de RAM - 2 tarjetas de red GigE a 66 MHz - 3 tarjetas duales de red GigE a 133 MHz - 2 tarjetas de fibra de 4 Gbit a 133 MHz - 3 cabinas de disco de 4 Gbit El problema era que no escalaba la red, daba un rendimiento muy malo. A pesar de tener pocos discos, no se podía achacar a los discos porque al hacer un stress, obteníamos 500+ MB/s. Al usar iperf obteníamos unos resultados nefastos: 180 MB/s. Esto nos despistó y pensábamos que era la red: cables, switch, PCs cliente, ... El problema es que no podíamos cambiar nada de la red por lo que estábamos con las manos atadas :( Pues resulta que al final la culpa fue mía 0:) El hardware estaba mal configurado !!! Me explico: se debe asignar 1 CPU por cada puerto de 1 GigE que se tenga. El problema con sistemas NUMA es que el sw (kernel o no) "van" a la CPU que más cercana está. En mi caso había 5 puertos de red GigE en el mismo brick asociadas a 2 CPUs. Luego había un cuello de botella porque los drivers de las 5 tarjetas iban a estas 2 CPUs :( El resultado de esto era: - cuello de botella en los buses PCI - las 2 CPUs estaban al 100% y el restante no hacía gran cosa Ahora está separado y he quitado una de las tarjetas de 66 MHz (la otra es para el heartbeat) y he repartido las tarjetas por los diferentes bricks. Ahora consigo unos anchos de banda mejores: 350 MB/s en lectura y 280 MB/s en escritura. De todas maneras, no he podido separar del todo los dispositivos de E/S, pero si consigo hacerlo posiblemente mejore el rendimiento :) Pues eso, muchas gracias a todos por las ideas ;) Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman

Show replies by date

Juan Erbes

12 May 12 May

12:01

New subject: [suse-linux-s] RESUELTO problema de rendimiento

2006/5/12, Rafa Grimán :

...

Hola :)

Pues eso, que ya he resuelto el problema de rendimiento que tenía al hacer los benchmarks. Resumo el hardware: - 16 CPUs - 32 GB de RAM - 2 tarjetas de red GigE a 66 MHz - 3 tarjetas duales de red GigE a 133 MHz - 2 tarjetas de fibra de 4 Gbit a 133 MHz - 3 cabinas de disco de 4 Gbit

El problema era que no escalaba la red, daba un rendimiento muy malo. A pesar de tener pocos discos, no se podía achacar a los discos porque al hacer un stress, obteníamos 500+ MB/s.

Al usar iperf obteníamos unos resultados nefastos: 180 MB/s. Esto nos despistó y pensábamos que era la red: cables, switch, PCs cliente, ... El problema es que no podíamos cambiar nada de la red por lo que estábamos con las manos atadas :(

Pues resulta que al final la culpa fue mía 0:) El hardware estaba mal configurado !!! Me explico: se debe asignar 1 CPU por cada puerto de 1 GigE que se tenga. El problema con sistemas NUMA es que el sw (kernel o no) "van" a la CPU que más cercana está. En mi caso había 5 puertos de red GigE en el mismo brick asociadas a 2 CPUs. Luego había un cuello de botella porque los drivers de las 5 tarjetas iban a estas 2 CPUs :( El resultado de esto era: - cuello de botella en los buses PCI - las 2 CPUs estaban al 100% y el restante no hacía gran cosa

Ahora está separado y he quitado una de las tarjetas de 66 MHz (la otra es para el heartbeat) y he repartido las tarjetas por los diferentes bricks. Ahora consigo unos anchos de banda mejores: 350 MB/s en lectura y 280 MB/s en escritura. De todas maneras, no he podido separar del todo los dispositivos de E/S, pero si consigo hacerlo posiblemente mejore el rendimiento :)

Parece ser que son pocos los que tienen la posibilidad de trabajar con tantas cpu's, razon por la que no es mucho lo que te podemos ayudar. Aunque ese es el camino del aprendizaje. Eso figura en los manuales, de como hay que configurar el hw? En cuanto a las memorias, cada cpu, tiene su propio banco de memorias, o forman un solo banco para todas las cpu's? Salu2

Rafa Grimán

12:13

New subject: [suse-linux-s] RESUELTO problema de rendimiento

Hola :) El Viernes, 12 de Mayo de 2006 14:01, Juan Erbes escribió:

...

2006/5/12, Rafa Grim�n :

...
Hola :)

[...]

...

...
Pues resulta que al final la culpa fue m�a 0:) El hardware estaba mal configurado !!! Me explico: se debe asignar 1 CPU por cada puerto de 1 GigE que se tenga. El problema con sistemas NUMA es que el sw (kernel o no) "van" a la CPU que m�s cercana est�. En mi caso hab�a 5 puertos de red GigE en el mismo brick asociadas a 2 CPUs. Luego hab�a un cuello de botella porque los drivers de las 5 tarjetas iban a estas 2 CPUs :( El resultado de esto era: - cuello de botella en los buses PCI - las 2 CPUs estaban al 100% y el restante no hac�a gran cosa

Ahora est� separado y he quitado una de las tarjetas de 66 MHz (la otra es para el heartbeat) y he repartido las tarjetas por los diferentes bricks. Ahora consigo unos anchos de banda mejores: 350 MB/s en lectura y 280 MB/s en escritura. De todas maneras, no he podido separar del todo los dispositivos de E/S, pero si consigo hacerlo posiblemente mejore el rendimiento :)

Parece ser que son pocos los que tienen la posibilidad de trabajar con tantas cpu's, razon por la que no es mucho lo que te podemos ayudar.

Todo lo contrario, me dieron ideas muy buenas :)

...

Aunque ese es el camino del aprendizaje. Eso figura en los manuales, de como hay que configurar el hw?

Eso es lo malo, que sí está documentado, que cuando imparto algún curso o charla lo digo y soy muy pesado con ello, ... Fue un descuido mío 0:)

...

En cuanto a las memorias, cada cpu, tiene su propio banco de memorias, o forman un solo banco para todas las cpu's?

Cada CPU tiene su banco de memoria, pero la memoria está completamente compartida. Es decir: si un proceso A se lanza, intentará usar la memoria asociada a su CPU, pero si esta memoria es poca, utilizará la memoria de otro banco. En cuanto a CPUs, ocurre lo mismo, el sistema operativo te puede asociar todas las CPUs o bien, mediante el comando tasksel puedes asociar procesos a CPUs y zonas de memoria. Mmmm ... creo que era tasksel, tendría que revisarlo 0:) Gracias :) Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman

Juan Erbes

13 May 13 May

03:00

New subject: [suse-linux-s] RESUELTO problema de rendimiento

2006/5/12, Rafa Grimán :

...

Hola :)

El Viernes, 12 de Mayo de 2006 14:01, Juan Erbes escribió:

...
2006/5/12, Rafa Grim�n :

...
Hola :)

[...]

...
...
Pues resulta que al final la culpa fue m�a 0:) El hardware estaba mal configurado !!! Me explico: se debe asignar 1 CPU por cada puerto de 1 GigE que se tenga. El problema con sistemas NUMA es que el sw (kernel o no) "van" a la CPU que m�s cercana est�. En mi caso hab�a 5 puertos de red GigE en el mismo brick asociadas a 2 CPUs. Luego hab�a un cuello de botella porque los drivers de las 5 tarjetas iban a estas 2 CPUs :( El resultado de esto era: - cuello de botella en los buses PCI - las 2 CPUs estaban al 100% y el restante no hac�a gran cosa

Ahora est� separado y he quitado una de las tarjetas de 66 MHz (la otra es para el heartbeat) y he repartido las tarjetas por los diferentes bricks. Ahora consigo unos anchos de banda mejores: 350 MB/s en lectura y 280 MB/s en escritura. De todas maneras, no he podido separar del todo los dispositivos de E/S, pero si consigo hacerlo posiblemente mejore el rendimiento :)

Parece ser que son pocos los que tienen la posibilidad de trabajar con tantas cpu's, razon por la que no es mucho lo que te podemos ayudar.

Todo lo contrario, me dieron ideas muy buenas :)

...
Aunque ese es el camino del aprendizaje. Eso figura en los manuales, de como hay que configurar el hw?

Eso es lo malo, que sí está documentado, que cuando imparto algún curso o charla lo digo y soy muy pesado con ello, ... Fue un descuido mío 0:)

...
En cuanto a las memorias, cada cpu, tiene su propio banco de memorias, o forman un solo banco para todas las cpu's?

Cada CPU tiene su banco de memoria, pero la memoria está completamente compartida. Es decir: si un proceso A se lanza, intentará usar la memoria asociada a su CPU, pero si esta memoria es poca, utilizará la memoria de otro banco.

Esto viene a ser el famoso NUMA? Salu2

Carlos E. R.

11:31

New subject: [suse-linux-s] RESUELTO problema de rendimiento

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-05-13 a las 00:00 -0300, Juan Erbes escribió: [recortado]

...

Esto viene a ser el famoso NUMA?

GRRRR... a ver si aprendemos a recortar :-P - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEZcOHtTMYHG2NR9URArpwAJ47DXRhpd5rVhuf3QMxZ6xhsulFNACfUA/F 3OIkk0BA4lIio+fpP7rYZhQ= =QTsF -----END PGP SIGNATURE-----

Rafa Grimán

15 May 15 May

16:27

New subject: [suse-linux-s] RESUELTO problema de rendimiento

Hola :) El Sábado, 13 de Mayo de 2006 05:00, Juan Erbes escribió:

...

...
Cada CPU tiene su banco de memoria, pero la memoria está completamente compartida. Es decir: si un proceso A se lanza, intentará usar la memoria asociada a su CPU, pero si esta memoria es poca, utilizará la memoria de otro banco.

Esto viene a ser el famoso NUMA?

Sí :) Non-Uniform Memory Access. Dicho de otra manera, tengo un montón de placas base conectadas (algunas pueden tener CPU y otras no) y lo que hago (soy una aplicación;) es acceder al banco de memoria más cercano, si ya no hay sitio voy al siguiente más cercano. En el caso de SGI, hay que añadir que es de tipo cc (ccNUMA) que significa cache coherent NUMA. O, lo que es lo mismo, con coherencia de caché. Es decir: si una operación matemática se lleva a cabo en dos procesadores, antes de realizarse, se comprueba que las cachés de ambos procesadores tienen el mismo dato, si no es el mismo dato, se sincronizan y se realiza la operación. Puede parecer que reduce el tiempo de cómputo, pero se hace por hardware (SHUB) por lo que no se pierde tanto tiempo :) Hasta donde yo sé, AMD tiene una estructura similar a NUMA, pero creo que no es del todo (o es una modificación de NUMA). Estando en SUSE, me lo explicó un ingeniero de AMD, pero no me acuerdo bien. En todo caso, en uno de los links que envió Juan Erbes hace poco, lo explican muy bien, es relativo al controlador de memoria que está dentro de la CPU. Resulta que los procesdores AMD hacen esto mismo: los datos van a parar al banco de memoria que controlan, pero si este banco se queda sin memoria ... van a otro banco :) Lo bueno de este diseño es que el número de hops (saltos de una memoria a otra) es muy pequqeño por lo que la latencia sigue siendo muy baja :) Sólo hay un problema y es que, si compramos una placa "barata" y queremos usar todos los bancos de memoria, tenemos que poner en la placa base todos los procesadores :( Esto no es "culpa" de AMD, sino de chipsets algo baratos y con algún que otro bug :( En resumen, si alguien se va a comprar un AMD64, que se pase por la web de AMD y que mire aver qué placas base tienen chips certificados y garantizados. Que también se pase por los links que envió Juan porque también lo comentan y los listan. Esto lo comento sobre todo para los que estén pensando en un AMD64 para servidores, y estaciones de trabajo que requieran toda la potencia. Si es para uso casero u ofimático ... no creo que sea tan necesario ;) Rafa -- 50% of all statistics are inaccurate. OpenWengo: rgriman

Carlos E. R.

12 May 12 May

12:21

New subject: [suse-linux-s] RESUELTO problema de rendimiento

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-05-12 a las 12:41 +0200, Rafa Grimán escribió:

...

Pues resulta que al final la culpa fue mía 0:) El hardware estaba mal configurado !!! Me explico: se debe asignar 1 CPU por cada puerto de 1 GigE que se tenga. El problema con sistemas NUMA es que el sw (kernel o no) "van" a la CPU que más cercana está. En mi caso había 5 puertos de red GigE en el mismo brick asociadas a 2 CPUs. Luego había un cuello de botella porque los drivers de las 5 tarjetas iban a estas 2 CPUs :( El resultado de esto era: - cuello de botella en los buses PCI - las 2 CPUs estaban al 100% y el restante no hacía gran cosa

¡Que curioso! Entonces al banco de programas de pruebas que se dijo le faltaba un simple "top", que puede mostrar la carga individual de cada cpu. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEZH3stTMYHG2NR9URAogrAJ9MVHnrMq3mJqNTA6AHg1mgIri/qQCeK4q9 YiKjhCOyy1wvX+/wgU4QEHs= =mtlW -----END PGP SIGNATURE-----

Rafa Grimán

12:48

New subject: [suse-linux-s] RESUELTO problema de rendimiento

Hola :) El Viernes, 12 de Mayo de 2006 14:21, Carlos E. R. escribió:

...

El 2006-05-12 a las 12:41 +0200, Rafa Grim�n escribi�:

...
Pues resulta que al final la culpa fue m�a 0:) El hardware estaba mal configurado !!! Me explico: se debe asignar 1 CPU por cada puerto de 1 GigE que se tenga. El problema con sistemas NUMA es que el sw (kernel o no) "van" a la CPU que m�s cercana est�. En mi caso hab�a 5 puertos de red GigE en el mismo brick asociadas a 2 CPUs. Luego hab�a un cuello de botella porque los drivers de las 5 tarjetas iban a estas 2 CPUs :( El resultado de esto era: - cuello de botella en los buses PCI - las 2 CPUs estaban al 100% y el restante no hac�a gran cosa

�Que curioso!

Entonces al banco de programas de pruebas que se dijo le faltaba un simple "top", que puede mostrar la carga individual de cada cpu.

Sip. Un top y luego pulsas "1" y te muestra el estado de todas las CPUs. Usamos top y sar para ver las CPUs. Hay más tema, resulta que NO se están usando Jumbo Frames (MTU=9000) lo cual produce muchos más paquetes e interrupciones por unidad de tiempo que una de 100 Mbits. Si pudiéramos usar jumbos, posiblemente no estarían tan ocupadas las CPUs. Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman

Carlos E. R.

13:08

New subject: [suse-linux-s] RESUELTO problema de rendimiento

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-05-12 a las 14:48 +0200, Rafa Grimán escribió:

...

Sip. Un top y luego pulsas "1" y te muestra el estado de todas las CPUs. Usamos top y sar para ver las CPUs.

Hay más tema, resulta que NO se están usando Jumbo Frames (MTU=9000) lo cual produce muchos más paquetes e interrupciones por unidad de tiempo que una de 100 Mbits. Si pudiéramos usar jumbos, posiblemente no estarían tan ocupadas las CPUs.

La verdad, es que con esas capacidades deberían haber tarjetas de red inteligentes, con su propia CPU. Le das el taco de datos a enviar y lo guarda en su propia memoria y lo procesa a su bola, o le dices donde está lo que tiene que enviar y lo pilla por DMA. Lo que pasa es que la CPU tiene que hacer la conversión de tcp/ip a ethernet, que es lo que la tarjeta entiende, y eso lo complicaría. Proceso distribuido... - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEZIjgtTMYHG2NR9URAtNxAJ9vLNY9ATu+fBxn44UeLAB6/WCXvgCfeR8r vHlgFwb6PMc5TOhDM9IqD7Q= =sosH -----END PGP SIGNATURE-----

Rafa Grimán

15 May 15 May

16:03

New subject: [suse-linux-s] RESUELTO problema de rendimiento

Hola :) El Viernes, 12 de Mayo de 2006 15:08, Carlos E. R. escribió:

...

El 2006-05-12 a las 14:48 +0200, Rafa Grim�n escribi�:

...
Sip. Un top y luego pulsas "1" y te muestra el estado de todas las CPUs. Usamos top y sar para ver las CPUs.

Hay m�s tema, resulta que NO se est�n usando Jumbo Frames (MTU=9000) lo cual produce muchos m�s paquetes e interrupciones por unidad de tiempo que una de 100 Mbits. Si pudi�ramos usar jumbos, posiblemente no estar�an tan ocupadas las CPUs.

La verdad, es que con esas capacidades deber�an haber tarjetas de red inteligentes, con su propia CPU. Le das el taco de datos a enviar y lo guarda en su propia memoria y lo procesa a su bola, o le dices donde est� lo que tiene que enviar y lo pilla por DMA. Lo que pasa es que la CPU tiene que hacer la conversi�n de tcp/ip a ethernet, que es lo que la tarjeta entiende, y eso lo complicar�a.

Proceso distribuido...

Pues sí, sería bastante útil. Lo mismo pasó con las tarjetas gráficas y las de sonido. Espero que alguien escuche tus ideas ;) Rafa -- 50% of all statistics are inaccurate. OpenWengo: rgriman

Carlos E. R.

19:52

New subject: [suse-linux-s] RESUELTO problema de rendimiento

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-05-15 a las 18:03 +0200, Rafa Grimán escribió:

...

...
Proceso distribuido...

Pues sí, sería bastante útil. Lo mismo pasó con las tarjetas gráficas y las de sonido. Espero que alguien escuche tus ideas ;)

Bah. Cuando terminé mis estudios, soñaba con diseñar sistemas microprocesador, placas, y esas cosas. Ahora... me conformo con que me paguen - y ya no podría diseñar cosas de esas, mis conocimientos seguro que están desfasados. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEaNvrtTMYHG2NR9URAjobAJ9RsWL61xmpBtgLNnkQTniMdlV3cgCfYrV6 DftJOqB1A8J7aGHSi9v1wDY= =vZEY -----END PGP SIGNATURE-----

Bono Vox

12 May 12 May

13:09

New subject: Error en la ejecucion de NMAP

Hola amigos de la lista... instale el sw NMAP sin problema, pero cuando quiero inicializarlo me sale el siguiente error: root: nmapfe nmapfe: relocation error: nmapfe: undefined symbol: gtk_action_group_new Agradecere que me puedan ayudar a solucionar el problema Saludos PD: OS RHES 3.0

Carlos E. R.

14:34

New subject: [suse-linux-s] Error en la ejecucion de NMAP

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-05-12 a las 13:09 -0000, Bono Vox escribió:

...

Hola amigos de la lista... instale el sw NMAP sin problema, pero cuando quiero inicializarlo me sale el siguiente error:

Esto... has secuestrado un hilo. Estabamos hablando de: ] Subject: Re: [suse-linux-s] RESUELTO problema de rendimiento

...

Agradecere que me puedan ayudar a solucionar el problema

PD: OS RHES 3.0

Esto... si eso es una Red Hat, ¿Que haces preguntando en una lista de SuSE? - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEZJzptTMYHG2NR9URAh93AJ9rcRfwOwR/GkqG9cI9Yrf8jGdavACeJoZR DSmN5MwpTU/UgSNa23fy/nQ= =Gr/l -----END PGP SIGNATURE-----

Victor Hugo dos Santos

15:08

New subject: [suse-linux-s] RESUELTO problema de rendimiento

2006/5/12, Rafa Grimán :

...

Hola :)

[...]

...

Pues resulta que al final la culpa fue mía 0:) El hardware estaba mal configurado !!! Me explico: se debe asignar 1 CPU por cada puerto de 1 GigE que se tenga.

como lo haces ??? por el kernel ?? o la BIOS ??? por algun hechizo ??? la verdad es que nunca lo tenia escuchado !!!

...

El problema con sistemas NUMA es que el sw (kernel o no) "van" a la CPU que más cercana está. En mi caso había 5 puertos de red GigE en el mismo brick asociadas a 2 CPUs. Luego había un cuello de botella porque los drivers de las 5 tarjetas iban a estas 2 CPUs :( El resultado de esto era: - cuello de botella en los buses PCI

mmm.. algo imaginaba referente a esto !!! ya que como comente, los buses PCIs eram compartidos, al menos para la maquinas que nosotros simples mortales usamos, no se las tuyas ya que nunca contestaste sobre esto.

...

- las 2 CPUs estaban al 100% y el restante no hacía gran cosa

mm. me extrana ya que imaginaba que se compartian la carga !!!! y es como la primera vez que escucho que una tarjeta PCI sartura toda una CPU.

...

Pues eso, muchas gracias a todos por las ideas ;)

Gracias a usted por compartir conozco estas configuraciones "utopicas", que posiblemente nos demorara mucho en conocer personalmente. salu2 -- -- Victor Hugo dos Santos Linux Counter #224399

Rafa Grimán

15 May 15 May

16:16

New subject: [suse-linux-s] RESUELTO problema de rendimiento

Hola :) El Viernes, 12 de Mayo de 2006 17:08, Victor Hugo dos Santos escribió:

...

2006/5/12, Rafa Grim�n :

...
Hola :)

[...]

...
Pues resulta que al final la culpa fue m�a 0:) El hardware estaba mal configurado !!! Me explico: se debe asignar 1 CPU por cada puerto de 1 GigE que se tenga.

como lo haces ??? por el kernel ?? o la BIOS ??? por algun hechizo ??? la verdad es que nunca lo tenia escuchado !!!

Bueno, esto tiene dos formas ... que además van juntas ;) Por un lado tienes un sistema que por hardware (generalmente un chip) te asocia los dispositivos físicos, los interconecta. Esto suelen ser los chipsets, en nuestro caso se llama SHUB. Este chip tiene la misión de interconectar los diferentes dispositivos. En nuestro caso (SGI), no tenemos "ordenadores" sino que lo que tenemos son placas base que tiene "algo": CPUs, memoria, I/O, el SHUB este y un conector llamado NUMALink. Estas placas base van metidas en un "enclosure" que parece un ordenador, a todo esto es lo que llamamos brick. El NUMALink lo que permite es conectar todos estos bricks y el SHUB lo que hace es conectar o establecer rutas entre los diferentes dispositivos que hay en cada brick. El SHUB lo que hace es que si tienes un brick que tiene todo (CPU, memoria, I/O), asocia estos dispositivos I/O a las CPUs y memorias más cercanas. Bueno, como hablamos de chips, también hay que tener en cuenta que hay un firmware ;) En el lado SW, tenemos básicamente dos cosas: - scheduler - un comando (creo que era tasksel) El scheduler distribuye cargas y con el comando puedes asociar tu mismo los procesos. En nuestro caso, como son drivers, hacerlo a mano no es lógico por lo que nos basaríamos en el scheduler y en el SHUB+NUMALink.

...

...
El problema con sistemas NUMA es que el sw (kernel o no) "van" a la CPU que m�s cercana est�. En mi caso hab�a 5 puertos de red GigE en el mismo brick asociadas a 2 CPUs. Luego hab�a un cuello de botella porque los drivers de las 5 tarjetas iban a estas 2 CPUs :( El resultado de esto era: - cuello de botella en los buses PCI

mmm.. algo imaginaba referente a esto !!! ya que como comente, los buses PCIs eram compartidos, al menos para la maquinas que nosotros simples mortales usamos, no se las tuyas ya que nunca contestaste sobre esto.

Bueno, en nuestro caso, tenemos 2 buses PCI en cada placa, con dos ranuras cada bus. Según esto, podemos pinchar 4 dispositivos PCI. Esto lo hacemos rara vez debido a lo que dices. En el caso que me pasó, sí compartí 1 bus entre 2 dispositivos PCI porque ambos eran tarjetas de red y pensé, "Bueno, como una de ellas no se usa (no tiene cable de red y no está configurada), pues nop habrá pérdida de rendimiento" ... Eso me pasa por pensar ;)

...

...
- las 2 CPUs estaban al 100% y el restante no hac�a gran cosa

mm. me extrana ya que imaginaba que se compartian la carga !!!! y es como la primera vez que escucho que una tarjeta PCI sartura toda una CPU.

El problema en este caso es que en lo que se está gastando CPU es en interrupciones y (como comenta Carlos en el correo anterior) el tema de TCP/IP-Ethernet. Hasta donde yo sé, esto no se puede distribuir ya que la latencia sería mayor de lo que debería ser y se perdería rendimiento. Hablándolo con otras personas, me han comentado que también influye el scheduler de Linux y que son cosas en las que se está trabajando :)

...

...
Pues eso, muchas gracias a todos por las ideas ;)

Gracias a usted por compartir conozco estas configuraciones "utopicas", que posiblemente nos demorara mucho en conocer personalmente.

:) Rafa -- 50% of all statistics are inaccurate. OpenWengo: rgriman

6557

Age (days ago)

6560

Last active (days ago)

List overview

Download

14 comments

6 participants

participants (6)

Bono Vox
Carlos E. R.
Juan Erbes
Rafa Grimán
Rafa Grimán
Victor Hugo dos Santos