martes, 30 de abril de 2013

Ponencia: Afinando sistemas. Primeras conclusiones

Ayer he ido a presenciar una ponencia sobre el ajuste (afinamiento, tuning) de sistemas. Impartida por Fernando Ruiz-Tapiador (uno de los pocos "Arquitectos Certificados Red Hat" de España), en el Centro de Novas Tecnoloxías de Galicia (CNTG); naturalmente se centraba en los sistemas Red Hat, si bien como es de esperar el 99% de lo dicho es aplicable a cualquier sistema GNU/Linux.

Una ponencia de cuatro horas sobre este tema es, reconozcámoslo de entrada, bastante dura. Ni siquiera la pericia (o experiencia) de Fernando puede evitar esto. Aunque, como es de esperar, fue una ponencia en la que se pudieron aprender algunas cosas, y como es habitual en las clases impartidas por Fernando, algún truquillo tan útil como muchas veces desconocido.


No voy a hacer una entrada exhaustiva sobre la ponencia. Fernando se comprometió a colgar el pdf de la presentación independientemente de que el CNTG hiciese lo propio. Si para entonces tengo tiempo y ánimo, intentaré hacer un resumen de cosas útiles. Hoy sólo quiero dejar aquí un par de cosillas interesantes.

En primer lugar, GNU/Linux es un sistema muy maduro, basado en otro sistema también muy maduro: tiene muchos desarrolladores y muchísima gente que lo utiliza, por lo que está muy bien afinado per se. Eso implica que, salvo en casos muy concretos, para afinar una cosa hay que desafinar otra. Por otra parte, debe tenerse en cuenta que cualquier cambio que se haga puede tener consecuencias imprevistas.

La primera recomendación es la obvia: deshabilita (incluso desinstala) cualquier cosa que no uses. Otra buena recomendación es estimar si realmente necesitas afinar el sistema.

¡Vaya!! ¿es malo que un procesador tenga una carga de trabajo del 90%? ¡Pues para eso lo compraste!! También es importante ver la relación esfuerzo/impacto del afinamiento que queramos realizar. Un ejemplo sencillo es el arranque de los sistemas servidores de producción: son sistemas pensados para ser arrancados muy pocas veces, por lo que una demora de 10 o 20 segundos en su arranque no suele merecer mucho esfuerzo por parte de sus administradores.

En segundo lugar, para saber si es preciso (o incluso posible) el ajuste del sistema, se deben de utilizar datos fiables, no suposiciones. Esto incluye que normalmente el usuario tiene una impresión del rendimiento del sistema muy ligada a la interactividad del mismo. Sí, el usuario tiende a creer que un sistema es más rápido si le responde rápidamente a él, independientemente de cuánto tiempo real tarden las cosas en realizarse.

Por supuesto, para estudiar el rendimiento real de un sistema deberemos hacerlo en función de las tareas reales a realizarse con él. Y también es cierto que eso suele llevar tiempo. Y otro factor importante es que realizar tales mediciones tenderá a influir en el rendimiento real del sistema, con lo que deberá discriminarse la parte de sobrecarga debida a nuestro estudio.

Es frecuente encontrar "reglas" para "afinar" un sistema o para mejorar el rendimiento del mismo. La lectora avisada habrá pensado que, en el mejor de los casos, que tales ajustes sirvan de algo es algo posible, pero no demasiado probable. No es fácil.

Un ejemplo de documentación sobre este tema puede ser la System Analysis and Tuning Guide (en este caso, para openSUSE, que es mi Sistema Operativo principal). Y si bien es cierto que sí hay unas cuantas reglas generales que se pueden utilizar, también es cierto que el usuario debe cerciorarse completamente de que ese cambio no va a producir consecuencias imprevistas, como he dicho antes. Piénsese que si un cambio pudiese ser útil siempre, con seguridad el sistema ya vendría con él incorporado.

Salud y feliz computación!!

No hay comentarios:

Publicar un comentario en la entrada