Blog de Ibercivis

En los últimos días hemos tenido unos problemas con el validador de fusión, que ha hecho que algunos trabajos quedasen pendientes de recibir los créditos. Después de trabajar estos días, ya disponemos de una versión que realizará una validación correcta de los resultados pendientes.

Esto ha ocurrido por una pequeña desincronización de las versiones de las aplicaciones y el validador, que ya hemos solucionado satisfactoriamente.

Etiquetas: calfonso, fusion, validador, bugs, upv

Ahora que parece que las aplicaciones estan funcionando, en Valencia vamos a volver a trabajar con el salvapantallas. En realidad, en cuanto a programación y funcionamiento básico ya está completamente desarrollado y es funcional en Windows, Linux y Mac. Además, ya lo pasé a la gente que se encarga de los contenidos y han preparado una versión con contenidos iniciales.

Así que tenemos una versión (y hay que remarcar que es inicial, puesto que falta afinar el concepto de los contenidos), que saldrá a la luz dentro de unos días.

La cuestión es que hace tiempo que teníamos en Valencia desarrollado el salvapantallas, pero con el cambio del API gráfica (pequeños, pero que requerían revisar la programación), se retrasó la puesta en marcha, balanceando los esfuerzos hacia la estabilización de las aplicaciones.

En cualquier caso, hemos retomado el desarrollo del salvapantallas y esperamos que en los próximos días podamos dar noticias acerca de él.

Etiquetas: calfonso, salvapantallas, upv

En los ultimos dias habreis notado paradas y rearranques de las bases de datos, o de ibercivis completamente, en pequeños lapsos mitad simulacro de emergencias, mitad prueba de parametros. Lo cierto es que no tuvimos Zivis a este nivel de usuarios durante mucho tiempo, asi que tenemos que aprender sobre la marcha. Tambien por eso los tecnicos estamos comodos con este nivel inicial de un par de miles de participantes asiduos.

MySQL es fascinante. Su modo cluster no es aconsejable mas que si de verdad tienes necesidades brutales, pues exige tener toda la base de datos en RAM, y no solo las caches de los indices. Pero entre la base aislada y el cluster tiene unas etapas intermedias muy interesantes. Basicamente, el sistema de copias Maestro->Esclavo puede no solo expandirse en arbol sino tambien cerrarse en circulo, de forma que un "cluster" de baja velocidad se puede formar mediante un circulo de nodos que aceptan escrituras junto con ramificaciones a nodos que solo aceptan lectura.

A la espera de que se pongan de pie las maquinas de nuestros socio, el "circulo" lo forman dos nodos, uno en subida y otro en bajada/registro, y la ramificacion es una copia que sale hacia www y de ahi a modulos.

Un primer descubrimiento, tan obvio que no sale en los manuales, ha sido el que no habia obligacion de tener los mismos indices en cada copia de la tabla. Lo que sí que sale en el manual es que podemos escoger que tablas copiamos a cada rama, pero eso era de esperar .  Total, que resulta que podemos optimizar las copias a las ramas quitando indices que no van a utilizar y añadiendo indices que sí que pueden necesitar. Es de esta manera como conseguimos listar en menos de cinco minutos las actividades de los ultimos cinco minutos .  Otro dia os contare por qué no conseguimos listar las coordenadas de los usarios a la misma velocidad.

Otro descubrimiento, asociado a este, es que las tareas de escritura se repiten en cada nodo. Usease, que realmente el anillo alivia las lecturas, pero las escrituras se las tienen que comer todos como si fuera una base de datos unica. Y obviamente el anillo va a ser tan lento como lo sea su nodo mas debil. Asi que, tirando de ganglia, iostat y lo que se os ocurra, estamos haciendo malabarismos con  la cpy, la memoria y los RAID para ver como optimizarlos, y segun vayamos creciendo habra que ir dejando discos y maquinas completas en exclusiva para el mysql.

Es tambien un poco molesto ver que esta diferencia entre lectura y escritura se entendio a medias del desarrollo de BOINC y hay mucho legacy frenandote. Asi, el php tiene una flag para dar un nodo de lectura diferente que el de escritura pero en realidad no lo usa de forma correcta en todos los db_init y ni siquiera esta documentada. La cosa es grave porque hemos observado, o creido observar, que las oleadas de lecturas bloquean la creacion o borrado de tablas.

Etiquetas: arivero, software, toquiteos, mysql

(la gráfica muestra en horizontal los Gflops y en vertical los Giops de las máquinas activas ayer en Ibercivis. La línea que cruza es el promedio de ambos; todas las máquinas en esa línea o en alguna paralela obtienen igual puntuación a igual tiempo de CPU)

En Zivis ya notamos que la gente tiende a quejarse de los pocos creditos obtenidos en nuestros proyectos.  Esta vez, hemos echado un vistazo a las estadísticas que da boinstats para acabar constatando, sorprendidos, que no es tal el caso: Rosetta y WCG dan menos créditos que nosotros, y sólo SIMAP y Einstein@home, de entre los mas populares, dan claramente más créditos.

¿Qué pasa entonces? La conjetura es que la queja puede provenir de las máquinas menos potentes: la mayoría de estos proyectos (excepto Rosetta) exigen tres resultados de quorum y suelen mandar más, digamos cuatro o cinco. En tal caso, los créditos concedidos son el promedio de los intermedios, así que la máquina que ha hecho la petición mas baja recibe al final más créditos de los que ha pedido. Estos cálculos los podéis ver explicados aquí http://www.boinc-wiki.info/Credit#Credit_Granting_Rules.

Si miramos la distribución de Gigaflops y Gigaiops de las máquinas activas en Ibercivis, veréis que aunque el promedio es de 4.9 hay una dispersión muy amplia; en la grafica hay 1018 maquinas bajo la línea promedio y 762 por encima. En otros proyectos, los que están por debajo tienen una cierta probabilidad de ser agrupados con los de la parte de arriba y obtener por ello más (?) creditos. En el nuestro, de momento los investigadores están optando por correr sin redundancia (y hacer uso de análisis y postvalidación al recibir), así que el quorum mínimo es de un solo resultado y este beneficio no se produce: obtienen mas crédito las máquinas más potentes a igualdad de tiempo de cálculo. Os recuerdo que la fórmula básica de cálculo dice que el crédito es proporcional a la suma (flops+iops) y al tiempo de cálculo empleado, ya que se supone que un crédito es la producción de un hipotético pentium básico durante un día de cálculo.

¿Qué opináis? ¿Es esto lo que esta ocurriendo, o hay otras causas involucradas? Ahora que lo pienso, he simplificado demasiado porque la discusión anterior no considera que el que tiene menos potencia ha tardado más. ¿Quién está pidiendo más crédito, y quién menos, para una workunit dada... los que tienen más, o los que tienen menos potencia? Precisamente, al no tener casi redundancia, no tenemos ese dato directamente en ibercivis.

Etiquetas: arivero, deuvede, ayuda, faq

(AR edit: paron, paron... mas bien paradica, porque la recepcion, registro y conexion siguen abiertos. Veanse los comentarios para mas info)

Hoy entre las 14:00 y las 20:00 está previsto que hagamos un pequeño parón de mantenimiento forzoso (va a haber un parón de mantenimiento de la red de la Universidad de Zaragoza), tiempo durante el cual no se mandarán trabajos. Durante la mañana aceleraremos la creación de trabajos para que tengáis suficientes para calcular durante el parón.

En el parón intentaremos mejorar varias cosas: mejorar la velocidad de acceso a la base de datos, mejorar el rendimiento de los discos del RAID, resumiendo mejorar el rendimiento general del sistema central para que tengáis la misma experiencia de usuario a pesar del aumento de usuarios y funcionalidades del sistema.

El parón podría prolongarse más allá de las 20h, en ese caso os avisaríamos por aquí con una actualización de la entrada.

Etiquetas: sgimeno, administración, sistemas, ibercivis, unizar

o casi. Como ya podeis ver, hace una hora que registro.ibercivis.es, bajada.ibercivis.es y subida.ibercivis.es han retornado a la normalidad. Hay dos excepciones: no estoy seguro de que arranquemos los creadores de nuevos trabajos hasta que haya una supervision humana (y por tanto quizas hasta mañana por la mañana) y no se podra activar del todo www y su mapa hasta que no haya alcanzado a los demas, y por algun lio de ficheros se ha quedado muy retrasado y no creo que alcance hasta la madrugada.

Etiquetas: arivero, alertas

Como dijimos, esta parada hemos hecho mas pruebecicas. Hemos mejorado algun que otro acceso a disco, limpiado un par de atime que podrian molestar en sistemas de ficheros ext3 (alguno lo hemos puesto a noatime, otros a relatime), y refinado el my.conf de la base de datos, y parece que se nota. No obstante estoy aun un poco mosca con el raid de discos. Es un raid 1+0 de cuatro discos, y de alguna manera cuando esta en competicion con todo el httpd y el mysqld en marcha no se comporta como debiera. Ahora mismico, un test de bonnie++ ha escupido

------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
94650 57 109599 29 16450 3 28923 15 17693 1 171.9 0

A lo que entiendo, Bonnie llama Output a la escritura en disco e Input a la lectura desde disco. Asi que ya veis que no encaja la cosa: ¡109Mbytes de escritura contra apenas (en el peor de los test que he hecho) 18 MB/sec de lectura!. Una confirmacion independiente la da el correr iostat en paralelo con los tests: se puede ver que durante las escrituras el md0 se sube hasta 115MB/seg, que el rewritting mantiene hasta como mucho 34MB/sec en lectura y en escritura... y que la lectura a secas no consigue levantar mas de esto.

En la misma maquina, con el disco duro raiz, que no esta en el raid, se consigue

------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
30007 17 29160 6 15809 2 33730 17 39346 3 117.9 0

En teoria, un 1+0 de cuatro discos deberia ser al menos 2 veces mas rapido en escritura que un disco solo,
y cuatro veces mas rapido en lectura. No cuadran las cuentas. Hay que tener en cuenta que aparte del test los discos llevan un trafico majico en registro/bajada de ibercivis, del orden del megabyte por segundo, y algo menos de la mitad para el raiz. Pero los resultados no parecen cambiar demasiado si paro procesos.

Por comparacion, www.ibercivis.es tiene un solo disco con dos particiones lvm, las cuales ademas estan con el journaling simplificado del ext3, "=writeback". Las dos se ponen tranquilamente con el bonnie por encima de los 50 megabytes/sec tanto en lectura como escritura de bloques. Y el journaling no afecta a la lectura, que es lo que esta fallando.

El primer sospechoso es el layout del Raid, "near=2, far=1", con chunks de 64K. Esto es el default, "n2". Que ya sabia uno que no es tan espectacular en los tests como "f2" pero a fin de cuentas tampoco es el servidor web, asi que la escritura es tan importante o mas que la lectura. Pero ni siquiera el obseso de Makarevitch llega a notar diferencias espectaculares.

Volviendo a mirar el iostat, se ve un detalle que ya noto Samuel el otro dia: al hacer las lecturas, un solo disco se esta comiendo todo el marron de su pareja: mientras sde y sdf van a la par, el sdc se come todo el marron que deberia tener sdd. Si el md da 30MB, 15 vienen de cada par, y del par c/d resulta que 14MB vienen del c. El escaqueado es un hitachi de la ostia que compramos hace poco en sustitucion de un failed, pero tambien el sdf es del mismo modelo y mes, y da el callo como el que mas. ¿No sera que el c se pasa de currar y no le deja al otro?

[EDIT, arivero, jul 10 14:52] Hemos cambiado el cable de alimentacion y el cable SATA, y la velocidad de lectura de sdd ha subido del megabyte rancio hasta los nominales 75MB/sec que se esperan de un 500 Gigas. Conjetura: le faltaban amperios.

Para comprobar los discos una herramienta rapida es, quien lo iba a decir, hdparm -A -C -t -T /dev/sda

Hay quien sugiere desactivar el look-ahead del disco para los RAID. De todas formas hay que tener en cuenta que el propio OS tiene otro read ahead, vease blockdev --getra /dev/md0, que en este caso esta ajustado al doble del readahead de sus componentes, blockdev --getra /dev/sdX. Habria que diseñar probatinas especificas de nuestra carga.

Etiquetas: arivero, hardware, toquiteo

Dejo aqui esto para que si veis algun problema durante el fin de semana lo comenteis. Los comentarios se leen en admin, aunque por misteriosas razones (tenemos que hablar con el proveedor acerca de ello) no todos se ven aqui.

En particular me hablan de fallos en docking para 64 bits. ¿alguna confirmacion?

Etiquetas: arivero, ayuda

Los comentarios siguen llegando, pero no se por que el estilo de blogia da problemas y no se visualizan fuera de administracion. Estamos esperando que lo solucionen definitivamente. Hay dos razones para tener el blog fuera: una, no reinventar la rueda. y otra, poder comunicarnos en caso de emergencia de nuestras maquinas o incluso de rediris.

Bueno, a lo que iba. Hoy hemos puesto en la web, en la seccion de estadisticas, los datos "crudos" de ancho de banda y carga de las maquinas. La maquina "lxbifi25" es www, la "lxbifi26" es registro y bajada, la del CETA es subida, y nuestro  escaso java se ejecuta en la 39.  Asi que los mas  interesantes son 25, que hace muchos analisis de la base de datos (recordad que esta fuera del circulo) y 26, que en su papel de "registro" produce trabajos. Las metricas propias tienen la etiqueta icvis_. Otro dia las pondremos mas bonitas, cuando dominemos el rrdtool, y entonces os explicare lo que es cada una. De momento ahi estan.

Etiquetas: arivero, software

Hemos sacado algunos histogramas para ver como iba la duracion de los trabajos respecto a nuestro ideal de 40 minutos. Practicamente todo acaba antes de los 2400 segundos, con dos excepciones en las que se esta trabajando: Materiales 64 y Fusion-iter. Esto es una cierta molestia relativa, dado que cuando se apaga el ordenador es lo mismo que abortar el proceso: el calculo de la workunit (y los creditos) se pierde. Os explico: antiguamente, con windows 95, se diseñaban estos programas para que guardaran continuamente su estado, porque cada vez que el usuario volvia al ordenador el proceso de calculo era terminado fulminantemente. Hoy en dia lo que ocurre es que el proceso se suspende y pasa al swap, a dormir en el disco duro, hasta que vuelve a haber RAM y CPU desocupada. Asi que los desarrolladores no se tienen que preocupar tanto como antiguamente de la recuperacion... a no ser que el proceso dure mucho.

En el caso de "materiales" (vease su blog) la aplicacion ya esta segmentada de forma que cada cuarenta minutos guarda su estado y se da por terminada (de forma que el usuario reciba el credito acumulado). En el caso de "fusion" estan trabajando en ello. Lo que ocurre es que las trajectorias simuladas mas estables duran mucho mas que las que directamente colisionan con las paredes del reactor y aunque muchos de los calculos terminan rapidamente hay un "long tail" de workunits que necesitan horas para terminar.

En cualquier caso, intentamos que los investigadores nos manden trabajos cuyo tiempo medio sea inferior a esos cuarenta minutos prototipicos. Ojo, las aplicaciones que pecan por el lado contrario (demasiado cortas) causan tambien problemas, pero de consumo de ancho de banda y de CPU en los servidores. Esto se equilibra porque ibercivis ajusta los envios de manera que todos los grupos obtengan a la larga el mismo numero de unidades de trabajo, y por tanto los investigadores ya procuran aprovechar el tiempo de cada uno de sus "tickets".

En esta grafica se muestra en horizontal el tiempo que ha tardado en terminar una workunit, en la ultima semana, y en vertical la velocidad (o coloquialmente "potencia") del ordenador, entendida como la suma de las dos benchmarks que hace BOINC.

Se puede ver que para los trabajos de m64 el tiempo de calculo y la velocidad de la maquina son inversamente proporcionales. Eso es asi porque estos trabajos estan compartimentados para realizar un numero fijo de operaciones una vez estan termalizados. Y por ello el producto velocidad*tiempo es constante; practicamente igual nos daria dar un "fijo" por workunit que calcular cada vez el crédito a partir de las benchmarks y el tiempo.

Otro cantar son docking e iter. Aunque en promedio son tareas cortas, no se sabe de partida cuanto tiempo van a necesitar. Y como son mucho mas cortas que m64, ni siquiera se llega a apreciar una hiperbola difusa.

Tambien podria ser problematico un subproyecto en el que las benchmarks, que son basicamente un tipo de calculo, no estuvieran siquiera correlacionadas con su duracion. Por ello se hacen dos benchmarks, una de calculo entero y otra de calculo flotante.

En Ibercivis nos resulta conveniente usar un baremo neutral respecto a subproyectos. A la pregunta ¿que me conviene mas, correr A o B?, la respuesta sencilla es que va a dar igual en la misma maquina, dado que vamos a puntuar segun el producto "velocidad*tiempo", con la velocidad dada no por A ni por B sino por la benchmark neutral. Otro asuntillo seria comparar sistematicamente tiempo de cpu con tiempo real transcurrido: esta relacion dependera debilmente de la configuracion de cada maquina. Y naturalmente, un asunto totalmente diferente es la cuestion del tipo de CPU y de sistema operativo, que afecta de manera diferente a cada subproyecto y a los benchmarks; a la gente de CanalBoinc les gusta hilar fino en estos asuntillos.

Etiquetas: arivero

Ayer estrenamos nuevas aplicaciones de materiales con tamaños 24 y 48 respectivamente. Aquellos que hayan personalizado sus preferencias de Ibercivis deben acordarse de indicar manualmente que desean recibir trabajos de estas aplicaciones. Para comprobar si puedes recibir trabajo de las aplicaciones visita Ibercivis->Unirte a Ibercivis->Tu cuenta->Subproyectos. En caso de que materiales24 y/o materiales48 aparecieran desmarcaradas puedes marcar haciendo click en el cuadradito al lado de los nombres y luego haciendo click en "Enviar" para hacer efectivos los cambios.

EDIT: Aquellos que admiten trabajo de todas las aplicaciones de materiales anteriores a estas dos, se les han modificado las preferencias de forma automática para que admitan estas dos también. Los que sólo aceptaban algunas aplicaciones de materiales se les enviará nota invitándoles a que las acepten. Los que no aceptaban ninguna aplicación de materiales no han sufrido ningún cambio. Si en tu configuración dispones de diferentes "venues" tampoco se ha realizado ningún cambio.

Etiquetas: Deuvede, aplicaciones, materiales