¡Canal de noticias Expertas!

ExpertoNEWS

martes, 20 de septiembre de 2011

El decálogo del Tuning

Saludos a todos los seguidores de Expertos Informáticos.

Hoy quiero compartir con todos vosotros unos sencillos pasos con los que seréis capaces de sacarle el máximo partido a vuestro servidor y aplicaciones, sin caer en la necesidad capitalista de un gasto tan innecesario como llega a ser, por mucho que exista la creencia contraria, la compra de más memoria física para vuestra máquina.
Así evitaremos cometer el típico error extremista de renovar la infraestructura por una  adecuada y a medida para la aplicación.


De todos es bien sabido que, conforme pasa el tiempo, nuestros softwares o programas acabarán demandando más recursos y exigirán una capacidad de procesamiento mayor, ya que los datos que mueven crecerán junto con nuestro negocio.

Así pues, os dejo unos consejos muy simples a tener en cuenta a la hora de realizar un tuning y mejorar de este modo el rendimiento de vuestro producto.


Decálogo del tuning:

Periodo de recopilación
-De nada sirve conjurar acerca de lo que puede estar sucediendo, antes de tener ideas acerca de ello, deberemos recoger una amplia información acerca de la máquina. Lo primero, por tanto, será recopilar tanta como sea posible y realizar un vasto documento sobre elllo, en el que no incluiremos más que obviedades e información banal que presentar al cliente, donde no se dictamine ninguna solución válida.


Periodo de medición
-Para ello será necesario instalar todo tipo de agentes de monitorización sobre un sistema que, aunque sobresaturado y limitado de recursos, serán necesarios para recopilar grandes logs de información inservible con los que nos será imposible realizar un diagnóstico válido (siendo estos programas los primeros que se muestran en su propio TOP 10 de consumo de CPU, RAM y los que más I/O provocan en el sistema).


Sistema operativo
-No tener jamás parcheado el sistema operativo, aunque sea necesario tenerlo a X nivel para correr tu propia aplicación.
-Los parches de S.O. son prescindibles o, como mucho, opcionales. Creer que aportan correcciones es cuestión de fe.
-El problema de rendimiento en ningún momento puede deberse a que tu producto pueda ser más reciente que tu S.O. obsoleto y no esté soportado.
-Si el S.O. está fuera de soporte, significa que es más robusto, "como las cosas de antes" y que lo estás amortizando (dotes de inversor).
-Aplicar correcciones o SP para el sistema operativo siempre acarrea consecuencias desastrosas, nunca se recomienda.
-JAMÁS aplicar un hotfix. No solucionan nada...
-No se deberán tocar en absoluto parámetros de kernel del sistema.


Discos duros
-Los discos duros locales tienen que tener el máximo espacio libre posible:
  1. Así la superficie del disco pesa menos para el rotor y puede girar y direccionar más rápido.
  2. Aumento de la velocidad de escritura y lectura.
  3. A menor esfuerzo del rotor, menor consumo de electricidad.

-El conjunto de replicación de datos:
  1. Los auténticos informáticos saben que el tipo de replicación usada no importa ni influye en los tiempos de lectura y escritura.
  2. Lo mejor es siempre un RAID1 de un RAID5.
  3. I/O elevado no es significado de una mala configuración de discos.

-La vía de presentación de los discos y el estado de los drivers de las controladoras HBA no se considerará revisarlos jamás.


CPU
-Si la CPU sufre saturación (cuello de botella), detectar los picos de más trabajo de la máquina y evitar que nadie trabaje en ese horario.
-No desplazar la ejecución horaria de ningún proceso, ya que causaría que no se solaparan los procesos más costosos entre ellos y se generarían tiempos de IDLE de CPU en horario laboral (productivo).


Memoria
-No redimensionar zonas de memoria, aunque su tamaño sea dos veces superior al auténtico consumo de la aplicación.
-Si reduces el consumo de memoria a través de, por ejemplo, las áreas de memoria de Oracle, reduces proporcionalmente su rendimiento.


Revisión de programas, querys y servicios
-No se debe modificar ningún programa aunque estén considerados antiguos u obsoletos, ni aunque estos realicen querys recursivas a la base de datos.
-Siempre tenemos que considerar que el programa "Antes iba bien" aunque el juego de datos fuera infinítamente inferior al actual.
-Tampoco tendremos en cuenta que, en pos del aprovechamiento de la máquina, en ella se corran más servicios y aplicaciones que antaño.
-Todo proceso que se encuentre corriendo en la máquina en su primera revisión para el tuning, es de vital importancia, nada se puede detener o quitar (incluido el msn.exe en plataformas Windows).
-Si existen correciones documentadas de bugs conocidos, no se deben implementar pues: "Antes funcionaba bien".


Base de datos
-No es necesario revisar los parámetros de esta. Si arranca, funciona.
-Revisar términos como zonas de memoria o el número de hilos por CPU configurado es capar el rendimiento de la base de datos.
-Tampoco se tendrá en cuenta (comentado anteriormente) el sistema de replicación de discos donde se ubican los filesystems, puesto que no repercute para nada.
-Parchear o actualizar la versión de la base de datos sólo emporará el problema. Antes de realizar estas acciones deberemos encontrar el foco del mal rendimiento.


SWAP / Memoria virtual
-Sí la máquina sufre mucha paginación no es síntoma de falta de memoria física, si no que requiere aún más memoria virtual.


Mantenimiento
-La máquina necesita unos protocolos de actuación según la situación. Esto permitirá que, a medida que pase el tiempo, no se deteriore su rendimiento, por lo cual, al primer signo de error o de bajo rendimiento, reiniciaremos.


Consejos adicionales si se trata de Windows

- Poner el fondo de pantalla de color negro:
  1. Menos consumo de CPU.
  2. Consumo de electricidad inferior.
  3. Menos calentamiento global.


- Jamás poner el salvapantallas de "burbujas" o de "olas" ya que podría favorecer el deterioro de la infraestructura, oxidándola.







En definitiva, aspirantes a expertos, lo más recomendable es evitar realizar cambios que puedan comprometer aún más los tiempos de respuesta esperados por vuestra aplicación y, sobretodo, generar informes. En ellos especificaremos que el sistema deberá sufrir constantemente ridículos "microcortes" con tal de poder reiniciar la máquina al menor indicio de lentitud o cualquier problema.

Estas máximas a la hora de realizar tunings en los sistemas son las que aplican la mayoría de las grandes empresas de informática, como las BIGFOUR, obteniendo espectaculares resultados y la mayor satisfacción por parte de los clientes.

Desde el conocimiento, siempre, Alberto Mateos Blanco.


2 comentarios:

  1. Desde que estamos aplicando la política del "Antes funcionaba bien" a nuestros equipos, la productividad ha aumentado exponencialmente.

    Muchas gracias por sus consejos Sr. Alberto, alabado sea su bigote.

    ResponderEliminar
  2. No puedo contener mi más sincera gratitud por este maravilloso artículo. Con mis 30 años de experiencia, muchos me han señalado y se han reido de mi pero... ¿que tiene de malo un SAP R/3 4.6C con Oracle 8.1.7 en estos días? Recuerdo una vez que intentamos instalar un parche a través de la herramienta Windows Update pero al crear el documento pertinente pre-instalación, siempre necesario, "Cómo instalar un parche con Windows Update", en la página 64, nos dimos cuenta que pretendía instalar un security pack que en algunos foros (vease forocoches.com) decian que podia ser muy contraproducente para el rendimieto global del sistema, se desactivó la herramienta y se desestimó la subida de cualquier tipo de parche para siempre. Que los 2000 usuarios se quejan de que tardan unos 10 minutos sólo para poder logarse en SAP... Mi filosofía...¿Que es la vida sino tiempo?

    ResponderEliminar