10.07.2015 Views

TuxInfo 22

TuxInfo 22

TuxInfo 22

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Una historia conocidaSi dentro de la población económicamente activa preguntamos quiénes trabajan en IT,tendremos un subgrupo cada vez más interesante. Si dentro de ese grupo preguntamos quiénestienen tareas relacionadas con sufrir y solucionar problemas dentro de sus aplicaciones, el grupono disminuye tanto. Si sacamos a los mentirosos, casi todos hemos tenido que lidiar alguna vezcon un problema que se ha intentado solucionar con el procedimiento “give the ball to someoneelse”, o “patear la pelota”, en la lengua de nuestras costas.Así, el círculo de IT se transforma en una excelente cinta de Moebius, que sólo se deformamediante un golpe de mouse en la nuca de algún gerente o director, y que es más o menos así:● El usuario se queja: “¿Puede ser que el coso ese que implementaron esté andando mal? Lo veolento”● Soporte de primer nivel se defiende: “Gracias, tiene el ticket Nro. 11.231-b. Guarde ese númeropara referencia, y futuras maldiciones”.● Ingresa a IT:● Desarrollo patea la pelota: “No es el programa. Seguro que es un problema en la base de datos,como nos pasó una vez, hace un tiempo, con el mismo programa. ¿Por qué no le preguntamos alos DBAs?”● Los DBAs patean la pelota: “La base anda perfecto. Le corrí estadísticas con la herramienta quetenemos, y no nos muestra nada. ¿Por qué no le preguntamos a los administradores delmiddleware, que una vez falló por usar demasiados recursos?”.● Los administradores del middleware patean la pelota: “Hice profiling, y todo funciona bien. ¿Noserá el sistema operativo, y algunos de los patches que instalaron hace poco? Eran deseguridad, pero las cosas a veces fallan. ¿Por qué no los involucramos a ellos?”.● Los sysadmins patean la pelota: “El sistema operativo anda perfecto. ¿No será la aplicación?Hace poco tuvimos un problema por un while que habían metido en un programa que noterminaba nunca, ¿se acuerdan? ¿No será otra vez lo mismo? ¿Por qué no los involucramos alos desarrolladores?”.Así el círculo se vuelve infinito, y el usuario finalmente decide instalar en su memory stick elMAME para jugar al Pacman mientras espera que una aplicación termine de procesar.Generalmente se vuelve campeón de Pacman, pero lo echan por baja productividad. Juntando laplata de la indemnización y del premio del campeonato, comienza un negocio propio donde noexista nada relacionado con una computadora.Contra el mal, la hormiga atómica¿Quiénes están aquí para evitar que estas historias se repitan? Nosotros, que ahora sabemosque existen otras herramientas de análisis, y que queremos transformarnos en las estrellas delárea de sistemas. No se entusiasmen, en la vida real eso no pasa nunca. Si son sysadmins,sepan que todo termina con un gerente recibiendo las medallas, y diciendo en una presentacióna la que los sysadmins no están invitados que “gracias a las técnicas de coaching, y mentoring, yal empowerment que la gerencia entrega a sus recursos, la productividad aumentó, y losproblemas se resuelven más rápido”. No sé si reír o llorar...Pero...¡aún no hemos ejecutado una sola línea de DTrace! Hemos dado un hermoso paseo porsus conceptos, pero ¡no sabemos cómo se implementa!Bien, acá es donde comenzamos con unos ejemplos sencillos, para luego ir metiéndonos enotros que no lo son tanto.Vamos por el primero, que nos dirá cuáles son los procesos que están escribiendo en cualquierfilesystem basado en ZFS, basándonos en “fbt:zfs:zfs_write:entry”. Escribamos este script, yguardémoslo como “zfs_write_procs.d”. La terminación “.d” no es necesaria, pero es útil pararecordar que es un script de DTrace:28

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!