Como se indic� en la introducci�n, una vez que se ha aplicado las normas de "higiene" en el sistema, tenemos dos posibilidades para mejorar a�n m�s su performance: la configuraci�n de la memoria y la repartici�n CPU-I/O. Aunque ambos an�lisis se pueden hacer en paralelo, es muy conveniente hacerlos secuencialmente a fin de cuantificar separadamente el impacto y simplificar las observaciones. Asimismo, es bastante recomendable empezar con la configuraci�n de la memoria, dado que las soluciones por este concepto son m�s sencillas y menos costosas que en lo concerniente a la repartici�n CPU-I/O.
Algunos sistemas nunca tienen absolutamente ninguna carencia de memoria. Una forma sencilla de determinar esta situaci�n es observando si han hecho uso del swap. Como se aprecia en el ejemplo, el swap (en este caso de aproximadamente 1200 megabytes) no tiene uso HASTA ESTE MOMENTO, lo que significa que el sistema todav�a no ha tenido que recurrir al �l por falta de memoria:
sys1$ /sbin/swapon -s Filename Type Size Used Priority /dev/hda7 partition 1228932 0 -1Si esta situaci�n se mantiene a lo largo de muchos d�as, es indicativo de que dicho sistema probablemente tiene exceso de memoria, o cuando menos, exceso de swap. En estos sistemas, dificilmente podr�amos mejorar la performance en lo referente al consumo de memoria.
Normalmente los sistemas experimientan carencias de memoria durante ciertos lapsos en los que se ejecutan determinados procesos pesados. Si estos "per�odos de carencia" son breves, entonces no hay mucho que mejorar en cuanto a la falta de memoria. Por el contrario, si los per�odos de carencia son prolongados, la performance se puede multiplicar asombrosamente.
En conclusi�n, el primer paso consiste en determinar si nuestro sistema tiene largos per�odos de carencia de memoria (por lo menos de algunos minutos) o si �stos son breves y poco numerosos (de pocos segundos de duraci�n.) Para el primer caso se aconseja una reconfiguraci�n, mientras que para el segundo una reconfiguraci�n mejorar�a muy poco la performance del conjunto y probablemente no valdr�a el esfuerzo.
A continuaci�n se muestra parte de la salida de vmstat para un sistema que inicialmente no tiene carencias de memoria, pero luego de unos segundos s� que las tiene:
$ vmstat 2 ---------memory- ---swap-- -----io---- --system-- ----cpu---- swpd free si so bi bo in cs us sy id wa 67288 478472 188 262 282 279 1037 239 8 1 81 10 67288 478472 0 0 0 0 1002 59 2 0 99 0 67288 478472 0 0 0 0 1001 54 2 0 99 0 67288 478472 0 0 0 24 1010 103 1 0 99 0 67288 478456 0 0 0 0 1017 467 8 1 91 0 67236 102320 34 0 46 16 1023 297 11 54 35 2 72148 3336 1276 4202 2446 4204 1424 459 15 23 0 61 111640 2960 1674 20072 4210 20086 1263 273 1 6 0 93 129996 3208 1960 9180 3622 9180 1190 327 1 4 0 96 129996 3568 3200 0 3862 0 1245 480 1 2 0 97 129996 3176 2454 0 2984 6 1225 414 4 2 0 95 129988 3496 3672 0 4076 68 1328 567 2 2 0 96 129988 2892 3268 0 4396 2 1325 531 0 2 0 97 175224 2768 2864 22664 3186 22710 1309 455 1 7 0 92 175224 3016 2460 0 3030 0 1254 675 5 3 0 92 76508 474376 438 0 478 0 1060 189 2 10 70 20 76508 474388 6 0 6 2 1012 436 8 1 91 1 76508 474404 0 0 0 0 1001 54 2 0 99 0 76508 474408 0 0 0 0 1001 57 1 0 99 0 76508 474408 0 0 0 0 1001 51 2 0 99 0Obviando la primera l�nea (que son valores acumulados), apreciamos que bajo las columnas 'si' y 'so' (swap in/swap out) los valores permanecen inicialmente en cero, y luego 'so' se dispara; luego de unos instantes 'si' tambi�n adquiere valores significativos. Finalmente tras unos 20 segundos, ambas columnas retornan a cero.
Este es un ejemplo t�pico de un sistema que durante unos segundos experimienta carencia de memoria. Los usuarios de este sistema probablemente experimentar�n lentitud en la respuesta durante estos momentos.
�Qu� debemos hacer al respecto? si durante todo el d�a �ste es el �nico momento de carencia de memoria, entonces cualquier reconfiguraci�n de memoria s�lo nos permitir�a ganar hasta 20 segundos en todo el mismo d�a, lo cual es evidentemente despreciable. Si por el contrario, este comportamiento hubiera durado algunas horas, o si ocurriera en muchas ocasiones (que acumulando su duraci�n podr�a totalizar horas) entonces la reconfiguraci�n s� es aplicable.
Si hemos decidido reconfigurar la memoria a partir del an�lisis anterior, entonces tenemos esencialmente tres opciones:
Modificar el orden de ejecuci�n de los procesos
Modificar los programas
Ampliar la memoria
Describiremos cada caso por separado.
Este es el primer nivel de soluci�n al problema de la carencia de memoria; es el m�s sencillo y el que requiere menos inversi�n.
A modo de ejemplo, consid�rese un sistema en el cual dos procesos que se ejecutan separadamente uno detr�s del otro tardan (en total) cinco minutos en completarse; pero si se ejecutan simult�neamente tardan una hora o m�s en terminar. Esto ocurre as� debido a que cada proceso por separado no introduce al sistema en el r�gimen de carencia de memoria o lo hace por muy poco tiempo e intensidad, mientras que la combinaci�n de ambos procesos s� lo hace de lleno y la performance se reduce dr�sticamente.
Este problema ocurre t�picamente en sistemas en los que el n�mero de procesos es muy elevado y por simplicidad para los operadores, se prefiere la ejecuci�n simult�nea. Evidentemente, la soluci�n consiste en identificar las "combinaciones" que generan el r�gimen de carencia de memoria y serializar la ejecuci�n.
Las consideraciones acerca de la optimizaci�n que se comentaron en la secci�n de "higiene" son totalmente aplicables aqu�. Lamentablemente muchas instalaciones ejecutan programas de terceros o no cuentan con el personal adecuado para este trabajo, por lo que s�lo pueden recurrir a la ampliaci�n de la memoria f�sica (ver m�s abajo.)
En muchos casos (especialmente programas no documentados) este procedimiento puede resultar costoso (en tiempo de honorarios de programaci�n), poco seguro (pues tal vez el programa ya no se puede optimizar mucho en cuanto a su consumo de memoria), y lento (pues la optimizaci�n puede resultar complicada y requiere muchas horas de an�lisis) por lo que tambi�n se recurre a la ampliaci�n de la memoria f�sica.
En este caso s�lo hay que determinar cu�nta memoria se va a agregar. En la mayor�a de casos la gente opta por agregar "bancos" de memoria que suelen duplicar la memoria existente, y volver a efectuar el an�lisis de la performance para cerciorarse de que ya no hay carencia de aquella.
Esta aproximaci�n iterativa es v�lida, pero en algunos casos es aconsejable tener una idea m�s exacta (por ejemplo, si el dinero escasea, o si no hay disponibilidad de "bancos" de memoria en el mercado, o si nuestro hardware est� casi al l�mite de su capacidad de crecimiento en memoria.)
Durante la operaci�n del sistema es frecuente que se observen diversos episodios de carencia de memoria de poca importancia, pero que necesariamente ir�n utilizando nuestro swap. Si volvemos a la salida de vmstat del ejemplo anterior, apreciaremos que antes de que se inicie el per�odo cr�tico el consumo de swap era de 67288 bloques (tambi�n se pudo obtener con swapon -s.) Este consumo se eleva hasta 175224 bloques para luego disminuir gradualmente. Esto quiere decir que el proceso pesado excedi� en 175224-67288=107936 bloques la capacidad de nuestra memoria empleando el swap. Por tanto, si agregamos prec�samente esta cantidad de memoria f�sica (por ejemplo, un "banco" de 128Mb) el proceso pesado podr� ejecutarse enteramente en RAM[1].
Evidentemente este tipo de an�lisis requiere bastante paciencia y los resultados pueden ser variables de un d�a para otro en funci�n de la carga total del sistema.
| [1] | De seguro al inicio entrar�a en el r�gimen de carencia de memoria dependiendo del consumo que otros procesos hagan de esta, pero tras desplazar a aquellos al swap, el proceso pesado terminar�a por completo en la RAM. |