JJMora@arrakis.es

En el post anterior, sobre Resource Management, vimos las posibilidades que ofrece este conjunto de herramientas para la gestión de los recursos. Principalmente vimos la forma en la que podemos gestionar ciertos parámetros del Kernel y como crear grupos de CPUs. En este post vamos a ver la herramienta RCAP (Resource Capping Daemon) que nos permite controlar la cantidad de memoria física a la que tiene acceso un proceso.

rcapd

A diferencia del control de recursos que realiza el kernel mediante los parámetros en los projects o en los procesos, el control de la cantidad de memoria asignada a un proceso la realiza un el demonio rcapd, el cual podremos activar o desactivar a nuestro antojo.

RCAP se basa en dos valores que tenemos que definir:

• La cantidad de memoria física que los procesos de un project pueden consumir
• El porcentaje de memoria física libre, a partir del cual el demonio rcapd comenzará a trabajar para liberar memoria.

¿Qué ocurre cuando se sobrepasa alguno de estos valores? la respuesta depende de la carga del sistema, vamos a poner algunos casos:

• Si se sobrepasa el límite definido en el project, pero el porcentaje de memoria física libre está por debajo del que hemos definido nosotros, el SO seguirá asignando memoria al project.
• Si se sobrepasa el límite definido en el project, y el porcentaje de memoria física libre está por encima del que hemos definido nosotros, el demonio rcapd comenzará a reducir el número de páginas asignadas a los procesos del project.

Cuando realicemos el capacity planning de nuestro sistema, podemos diseñar un reparto de los recursos que refleje nuestras necesidades, evitando de esta forma que aplicaciones menos importantes consuma memoria física necesaria para aplicaciones mas importantes para nuestro negocio. Por ejemplo en el caso de servidores de aplicación o BBDD, podríamos asegurar la cantidad de memoria física que asignaremos a un project donde correrán las aplicaciones o BBDD principales.

En nuestro capacity planning debemos tener en cuanta las consecuencias que se producen a la hora de definir límites poco realistas, para por ejemplo, un error a la hora de la definición de los límites provocará que el SO comience a trabajar en el intercambio de páginas entre la memoria principal y la secundaria.

Arrancar rcapd

Como hemos comentado, el control de la cantidad de memoria asignada a un project lo realiza el demonio rcapd, este demonio lo podemos arrancar como un servicio del sistema, mediante SMF o sencillamente como un proceso mas.

root@host #
root@host # svcadm enable system/rcap
root@host #

Configurar rcapd

El demonio rcapd dispone de una serie de variables, que nosotros podemos modificar para ajustar el comportamiento del demonio a nuestras necesidades.

Para ver los valores actuales con los que está trabajando rcapd, solo tenemos que ejecutar el comando rcapadm.

root@host # rcapadm
                                      state: enabled
           memory cap enforcement threshold: 0%
                    process scan rate (sec): 15
                 reconfiguration rate (sec): 60
                          report rate (sec): 5
                    RSS sampling rate (sec): 5
root@host #

Definir el límite en un project

Para definir el límite de memoria física que un project puede tener asignada, debemos utilizar el parámetro rcap.max-rss. Podemos modificar un project con el comando projmod, en el siguiente ejemplo hemos modificado el project default con un límite de 20GB y de 20MB.

root@host # cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::
group.staff:10::::
root@host # projmod -K rcap.max-rss=20GB default
root@host # cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::rcap.max-rss=21474836480
group.staff:10::::
root@host # projmod -K rcap.max-rss=20MB default
root@host # cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::rcap.max-rss=20971520
group.staff:10::::

rcapstat

Para ver como se está comportando el sistema con los nuevos límites de memoria física que hemos definido, podemos utilizar el comando rcapstat.

root@host # rcapstat 1
    id project         nproc    vm   rss   cap    at avgat    pg avgpg
     3 default             -   72M   13M   20M    0K    0K    0K    0K
     3 default             -   72M   13M   20M    0K    0K    0K    0K
     3 default             -   72M   13M   20M    0K    0K    0K    0K
     3 default             -   72M   13M   20M    0K    0K    0K    0K
     3 default             -   72M   13M   20M    0K    0K    0K    0K
     3 default             -   72M   13M   20M    0K    0K    0K    0K
     3 default             -   72M   13M   20M    0K    0K    0K    0K
     3 default             -   72M   13M   20M    0K    0K    0K    0K
^C
root@host #

Para chequear el consumo de memoria de los distintos projects del sistemas podemos utilizar el parámetro -J del comando prstat.

root@host # prstat -J
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 16247 root     5544K 4720K cpu0    59    0   0:00:31 0.0% prstat/1
   516 daemon   3264K 2536K sleep   59    0   0:00:00 0.0% rpcbind/1
   582 root     2424K 1312K sleep   59    0   0:00:00 0.0% smcboot/1
   519 daemon   3464K 2944K sleep   59    0   0:00:00 0.0% statd/1
   521 daemon   2824K 2192K sleep   60  -20   0:00:00 0.0% nfs4cbd/2
   581 root     2424K 1312K sleep   59    0   0:00:00 0.0% smcboot/1
   528 daemon   2792K 2176K sleep   60  -20   0:00:00 0.0% lockd/2
   175 daemon   5120K 3840K sleep   59    0   0:00:09 0.0% kcfd/5
   327 root     3048K 2072K sleep  100    -   0:03:46 0.0% xntpd/1
   584 root     2904K 2136K sleep   59    0   0:00:01 0.0% ttymon/1
   363 root     1768K 1024K sleep   59    0   0:00:00 0.0% efdaemon/1
   156 root     6376K 3312K sleep   59    0   0:00:00 0.0% syseventd/15
     9 root       13M   12M sleep   59    0   0:01:51 0.0% svc.configd/17
     7 root       44M   38M sleep   59    0   0:01:47 0.0% svc.startd/12
   523 daemon   5144K 2176K sleep   59    0   0:00:05 0.0% nfsmapid/3
PROJID    NPROC  SWAP   RSS MEMORY      TIME  CPU PROJECT
     1       11   10M   18M   0.1%   0:03:15 0.0% user.root
     3        4   74M   20M   0.1%   0:00:09 0.0% default
     0       42  147M  161M   0.5%   2:09:38 0.0% system

Total: 57 processes, 209 lwps, load averages: 0.24, 0.30, 0.57

Conclusión

Como herramienta para la gestión de los recursos, RCAP nos ayudará a garantizar la cantidad de memoria física asignada a un project, pero tenemos que tener especial cuidado que el análisis que hemos realizados sobre la carga de nuestro sistema sea correcto, porque tal como hemos comentado en el post, un error en la definición de los límites de memoria, puede provocar problemas de paginación entre la memoria principal y la secundaria, con el consiguiente consumo de CPU y por lo tanto degradación del sistema.

Desde aquí os invito a participar en el proyecto phpEasyTools en el que estamos creado un sencilla interfaz para la gestión de los recurso de Solaris, en la sección EasyRM screenshots podéis echar un vistazo a la herramienta y lo fácil que es la parte de RCAP.