Hola :) El Martes, 1 de Agosto de 2006 07:04, Jordi Espasa Clofent escribió:
No la conozco y no he probado estos chipsets. Por lo poco que he visto/leído, algún problema podría aparecer si la t. red estaba integrada en placa, pero creo que se ha corregido. Personalmente no me gustan las cosas que vienen en placa y tiendo a aconsejar deshabilitarlas en la BIOS y poner una placa en ranura PCI/PCI-X/PCIe.
La idea es ponerle 2 ethernets más; evidentemente si la integrada me da algún problema, deshabilitada y ha ponerle 3 y Santas Pascuas.
¿Channel bonding? En todo caso, 3 tarjetas te van a crear muchas interrupciones además de tener que separarlas en buses differntes para obtener el máximo rendimiento.
Para eso te vendo un 386 que tengo muerto de risa ;) Ahora en serio, si las queries no son muy brutas, te sobra máquina.
Si, lo sé.
Con samba tienes varios cuellos de botella:
- CPU: Samba no usa threads, son procesos, cada usuario conectado arranca un proceso hijo nuevo.
Bueno, con la CPU que le meto no creo que haya demasiado problema.
- t. red: usa jumbo frames (aka MTU=9000) si puedes. Si lo dejas a 1500, te puede crear otro cuello de botella en la CPU debido a las interrupciones por parte de cada paquete que procesa la t. de red. Al aumentar el MTU -> disminuye el número de paquetes -> disminuye el número de interrupciones.
Si, sería lo suyo. ¿Cómo se configura eso?
O bien desde YaST o bien en el ficherillo: /etc/sysconfig/network/ifcfg-eth-<loquesea> modificando la entrada: MTU='' rcnetwork restart
¿Vale sobre ethernet 10/100 o tiene que ser dispositivo gigabit?
Gigabit.
- memoria: no es realmente un cuello de botella sólo que Linux mete todo en RAM por lo que si pones más RAM ... mejor ;)
;)
- sistema de disco + sistema de ficheros: te puede suponer un cuello de botella. Si buscas buen rendimiento, separa los discos en diferentes controladoras y ten cuidado con el "stripe size" al crear el RAID. Si puedes, intenta que el "stripe size" sea igual al tamaño de bloque que le asignas al sistema de ficheros y al "write cache size" de Samba si usas oplocks.
Aquí me he quedado un poco igual Rafa. ¿Puedes darme más info o remitirme a algún link para ignorantes?
A bajo nivel, los discos escriben en bloques, generalmente 512 bytes. El sistema de ficheros puede "definir" un tamaño de bloque determinado para escribir esa cantidad de información en el disco duro. Por ejemplo, puedes poner 4K (creo que es lo normal) o puedes poner 16K o el valor que soporte el sistema de ficheros que vayas a usar. Esto es importante en función del tamaño de ficheros que vayas a manejar. Si son ficheros pequeños, mejor pon valores pequeños y si son ficheros grandes ... valores grandes ;) La explicación es que si tienes ficheros pequeños y pones un tamaño de bloque grande, hasta que no se llene el buffer ... no se escribirá a disco. En el caso contrario, si trabajas con ficheros grandes (100 MB, por ejemplo) y el tamaño de bloque es muy pequeño, escribirá muchas veces a disco y el rendimiento caerá (más interrupciones, recuerda que lo mecánico es siempre más lento, ...). El stripe en un sistema RAID es un concepto algo similar, pero no idéntico al del bloque del HDD. Son unidades de escritura y lectura para los discos en RAID con striping. En cuanto a Samba, puedes establecer el tamaño de buffer también. Cuando este buffer esté lleno escribirá a disco. Si te fijas, tus discos van a trabajar con unos 3 buffers. Si consigues que estos 3 estén al mismo tamaño, los tres escribirán a disco al mismo tiempo. Estarán sincronizados. Obviamente esto no te va a dar un aumento de rendimiento del 2000%, pero sí vas a conseguir valores sostenidos y las CPUs y los HDD trabajarán menos ... o mejor dicho, trabajarán mejor. Espero haberme explicado 0;) En cuanto a links .. no tengo ninguno :(
Hay otros cuellos de botella con los que te puedes encontrar como son: buses PCI y bus RAM <-> CPU.
En el primer caso, serán tarjetas PCI las que te puedan causar pérdidas de rendimiento y lo sufrirá Samba. Evita que los dispositivos PCI compartan bus, de esta manera evitarás saturar un bus PCI.
Exacto. Lo había tenido en cuenta.
En principio no parece que vayas a tener problemas de rendimiento. De todas maneras, monitorízalo con alguna herramienta para asegurarte que das un rendimiento aceptable.
¿ideas?
En otras ocasiones he comentado el uso de saidar, es la que más me gusta. Pero tienes gkrellm, xosview, ... Antes de ponerla en producción, puedes hacer pruebas con dd e iperf para ver los rendimientos máximos que puedes esperar de tu máquina y, quizás, dónde puedes intentar mejorar el rendimiento.
Una pregunta más ¿has tenido en cuenta backups? Te pueden suponer un cuello de botella en cuanto a red (si haces backup por red), de disco y CPU (si usas rsync, por ejemplo) o de memoria.
De momento se hará a nivel local de disco 2 (el que estará en RAID) al disco 1. Independientemente de esto, sobre soporte óptico (DVD) diariamente.
Evidentemente esto se quedará pequeño y lo que tengo en mente es un disco externo vía USB y rsync.
Ojo con la CPU y el I/O con rsync, es bastante intensivo. HTH 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