Hola :) On Wednesday 29 June 2011 14:03 Mauro Antivero wrote
Actualizo:
Nos encontramos en problemas con nuestro actual servidor, el cual es:
Intel Core 2 Quad Q9650 @ 3.00GHz 2 GB RAM Mother Intel DG43NB 2 discos SATA II en RAID por soft 2 placas de red Gb Ethernet PCI express - una onboard y la otra agregada - Intel e1000 2 placas de red Gb Ethernet de las cuales no recuerdo la marca
El problema con el cual nos encontramos ahora (grave) es que el equipo est� ruteando un tr�fico aproximado de 200 Mbps y se ve desbordado por las interrupciones que genera la llegada de cada paquete.
Ya hemos probado una caracter�stica disponible en el chip de la placa PCI Express (las dos PCI Express son las principales, por una "entre" y por la otra "sale" - se entiende que el tr�fico es bidireccional, es solo una forma de decir - ) para cambiar la forma en la que se manejan las interrupciones, denominada "InterruptThrottleRate". Por si a alguien le interesa:
http://www.mjmwired.net/kernel/Documentation/networking/e1000e.txt
http://www.intel.com/design/network/applnots/ap450.htm
Pero no hemos obtenido mayores resultados.
Una solución para el problema de las interrupciones en redes Gigabit Ethernet es usar Jumbo Frames. Ahora bien, si comunicas con un router que no es GigE, no te va a valer. Para usar Jumbo Frames, tienes que tener todos los equipos de esa red trabajando con Jumbo Frames. Otro consejo: tienes 4 cores y 2 GB de RAM ... poca RAM veo yo allí. Tercer consejo: - comprueba que las tarjetas GigE _NO_ compartan bus PCI (generalmente cad dos slots PCI comparten un bus por lo que si dejas al menos un slot PCI entre una tarjeta y otra te aseguras que no comparten bus ... pero no siempre es así) - comprueba que _NO_ compartan IRQs, que cada GigE tenga su propia IRQ. - comprueba que las tarjetas GigE _NO_ compartan bus PCI con otros dispositivos tipo HBA, HCA, t. gráfica, ... Si no hay más remedio que compartir bus PCI porque no hay más slots/buses libres, que el bus lo compartan las dos GigE
Lo que sucede es que al llegar aprox. a los 200 Mbps (supongo que no ser� en si la velocidad, sino la cantidad de paquetes) el tr�fico literalmente se "viene abajo", por ejemplo baja poco a poco a 150 Mbps y pasada la hora pico comienza a subir nuevamente, como si al "alivianarse la carga" el sistema responde normalmente de nuevo.
En estos momentos problem�ticos, al hacer un htop vemos un proceso que se dispara al 100% en uno de los n�cleos, el mismo es el "ksoftirqd".
Al ver la descripci�n del mismo (http://www.openalfa.com/cgi-bin/man.cgi?section=9&topic=ksoftirqd http://www.openalfa.com/cgi-bin/man.cgi?section=9&topic=ksoftirqd) se ve que es un kernel thread que se dispara cuando el sistema est� bajo mucha carga de interrupciones por software.
Si bien todav�a seguimos investigando sobre el tema nos da a pensar que el problema es por el tr�fico que est� atravesando el servidor.
Yo creo que sí, que es por el tráfico. Bueno, por el número de interrupciones y context switching que se hace debido al alto volumen de tráfico. Los consejos que te doy más arriba alivian, pero no solucionan ya que la CPU no puede más. BTW, ¿tus tarjetas GigE soportan TOE (TCP Offload Engine)?
Lo que quiero saber es si existe la posibilidad de que un sistema m�s moderno (en cuanto a hardware) mejore esta situaci�n. La plataforma actual es realmente potente, pero en si es una dektop, no s� que diferencia habr� con algo similar pero destinado a ser un servidor.
Ustedes tienen alguna idea sobre esto? Puede llegar a mejorar la situaci�n al cambiar el hardware o est� por otro lado el problema?
Si tienes el dinero, te recomendaría un sistema con: - pocos cores (dual core), a menos que tengas muchas rutas y cortafuegos y cosas complejas, en cuyo caso quad-core puede ser interesante. - elevada frecuencia (lo más alta posible) - dos sockets - dos chipsets - cada tarjeta GigE conectada a un chipset diferente - 1 GB de RAM por core - comprar tarjetas que soporte TOE (todas las enterprise o de tipo servidor lo soportan ... o deberían) - Jumbo Frames, si puede ser Eso sería la situación ideal. HTH Rafa -- "We cannot treat computers as Humans. Computers need love." "Assume the problem is with whomever is asking the question." Happily using KDE 4.6.3 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org