You are on page 1of 7

UNIVERSIDAD LA SALLE CARRERA DE INGENIERIA DE SISTEMAS

ADMINISTRACION DE LA MEMORIA EN EL SISTEMA OPERATIVO ORACLE SOLARIS

NOMBRE MATERIA FECHA

: : :

MIJAEL COLQUEHUANCA JAVIERI SISTEMAS OPERATIVOS 11 DE JUNIO DE 2012

ADMINISTRACION DE MEMORIA EN EL SISTEMA OPERATIVO ORACLE SOLARIS


La gestin de memoria que hace el Kernel de un sistema operativo no se diferencia mucho de la que se debera hacer con cualquier otro software, excepto en una cosa, es difcil realizar una prediccin sobre las necesidades de memoria que van a tener los distintos procesos que se estn ejecutando en el sistema, para ellos el Kernel debe estar continuamente reservando pedazos de memoria para la gestin del sistema, dicha memoria se emplear para mantener las distintas estructuras de datos necesarias, por ejemplo, cuando se crea un nuevo proceso, el Kernel debe reservar un espacio de memoria para almacenar una estructura de datos de tipo proc_t, o cuando se crea un fichero, se debe reservar memoria para almacenar la informacin del fichero en una estructura de tipo inode_t. De la misma forma, cuando un proceso muere, la informacin que mantiene el Kernel sobre dicho proceso ya no es necesaria por lo que puede ser eliminada de memoria, liberado el espacio que ocupa. Que el Kernel trabaje con este tipo de informacin presente dos inconvenientes considerables: La cantidad de informacin que se crea y se destruye es bastante elevada y cada vez ser mayor en tanto en cuanto los procesadores se hagan ms rpidos y se gestione ms cantidad de memoria, lo que permitir que una mayor cantidad de procesos podrn ejecutarse en el sistema, asignandoles cada vez ms cantidad de recursos. La cantidad de memoria necesaria para almacenar mucha de la informacin con la que trabaja el Kernel es mucho menor que el tamao de una pgina fsica, por lo tanto el utilizar unidades de un tamao fijo como son las pgina, supone un aumento de la fragmentacin de la memoria. Para resolver estos y otros problemas en la versin de Solaris 2.4 se implement un nuevo mtodo para la asignacin del memoria conocido como slab allocator (asignacin de losa). Este asignador de memoria trabaja con los siguientes elementos: Objetos, de esta forma se designa a una unidad de memoria asignada a un elemento, su tamao es variable dependiendo del tipo dato. Slab, consiste en una o ms pginas de memoria, las cuales estn divididas en huecos del mismo tamao y que se utilizan para almacenar un tipo de objeto, disponen de un contador que informa sobre la cantidad de objetos que han sido asignados. Cache, consiste en uno o varios slabs. Magazines, son arrays de punteros a objetos.

Cachear objetos Entre las operaciones ms realizadas por el Kernel estn la asignacin de memoria para un objeto nuevo que se ha solicitado y la posterior liberacin de dicha memoria. El cacheado de los objetos es un tcnica que permite ahorrar tiempo intentando no ejecutar los pasos de construccin y destruccin de un objeto, para ello se basa en la reutilizacin de los objetos, no en su creacin y destruccin. Cuando se realizar una peticin para crear un objeto, este dispone normalmente de un mtodo constructor que se encarga de reservar memoria, inicializar variables, etc. Una vez el objeto ha terminado su funcin, debera ser destruido, para entre otras cosas liberar la memoria que est ocupando, en vez de esto, el Kernel no lo elimina sino que lo marca con el estado de libre, de esta forma si se vuelve a solicitar la creacin de un objeto del mismo tipo, el sistema ya no tiene que ejecutar el paso de su construccin porque el objeto ya existe. Este mtodo se basa en disponer de una serie de caches, en las cuales se almacenan los objetos para poder ser reutilizados. Es importante entender que en el sistema habr tantos tipos de cache, como tipos de objetos maneje el sistema. El uso de un sistema de cache para los objetos con los que trabaja el Kernel aumenta considerablemente el rendimiento, evitando los 2 pasos ms costosos, la creacin del objeto y su destruccin. Cuando el sistema necesite memoria, el asignador puede llamar a los destructores de todos los objetos que estn marcados como libre y de esta forma liberar la memoria que ocupan. Slabs Un slab est formado por una o varias pginas continuas de memoria virtual, divididas en espacios de igual tamao, utilizados para almacenar objetos, el slab dispone de un contador que indica la cantidad de objetos asignados al slab. Es por tanto la unidad mnima con la que trabaja el Asignador. Cuando el contador de un slab est a 0, dicho slabs puede ser destruido para liberar la memoria que tiene asignada. El uso de slabs reduce la fragmentacin de la memoria, ya que aunque los objetos son menores que el tamao de la pgina, al utilizar varias pginas para almacenar objetos del mismo tamao y que la unidad de memoria para el Asignador sea el slabs y no el objeto, permite que el sistema pueda almacenar muchos objetos de pequeo tamao en una o varias pginas de memoria. La definicin de la estructura kmem_slab la puedes encontrar en el portal de OpenSolaris

El slab es controlado por la estructura de datos kmem_slab, la cual contiene un puntero a la cache a la que pertenece el slab, la direccin base del slab, un puntero al siguiente slab en la lista freelist de la cache, un puntero al slab previo en la lista freelist de la cache, un puntero al primer buffer libre del slab, el contador de objetos en el slab y el nmero de objetos que tiene este slab.

Un slab formado por varias pginas est divido en tres tipos de informacin, al final del slab se almacena la estructura de datos kmem_slab que contiene la informacin necesaria para trabajar con el slab, el resto del espacio se divide entre el tamao del objeto para el que se ha creado el slab y el espacio restante es espacio no utilizado. Como curiosidad decir que el slab solo almacena informacin sobre la lista de buffers libres y no de los ocupados, esto es porque el objeto ocupado tiene una direccin de memoria que obligatoriamente debe coincidir con alguno de los buffer del slab, cuando un objeto es liberado se realiza una peticin a la cache, esta localiza el slab al que pertenece mediante la direccin del objeto, aade al buffer al que pertenezca el objeto a la lista de buffers libres y decrementa el contador de objetos del slab. Cache La cache consiste en un pool de un tipo de objeto en concreto, es decir, se pueden crear tantas caches como tipos de objetos utilice el sistema. Todas las caches dispones de dos interfaces, un interfaz de frontend que es utilizado para asignar/liberar objetos y un interfaz de backend que se utiliza para reclamar o liberar slabs. Cuando todos los slabs de una cache estn llenos, se realiza una peticin mediante el interfaz de bakend para que se asigne otro slab, una vez se ha asignado, se inicializan todos los objetos del slabs y se marcan como libres para que la siguiente peticin a la cache pueda asignar un objeto. Cuando el sistema dispone de poca memoria, se avisa a las caches para que liberen toda la memoria que les sea posible, para ello, comprueban en la lista de slabs libres todos aquellos que no tienen ocupado ninguno de sus espacios y llaman a los destructores de los objetos del slabs, en ese momento se libera la memoria ocupada por todo un slab. Magazines El mtodo de cacheado de objetos presenta una serie de ventajas que permiten aumentar el rendimiento del sistema, en tanto en cuanto ya no se pierde tiempo en la creacin y destruccin de objetos, los cuales en caso de que sean muy utilizados, supondra un consumo en ciclos de CPU. Frente a las ventajas existe un inconveniente, es que si el mtodo de cachear objetos funcionase tal como se ha descrito, no solo no servira para aumentar el rendimiento, sino todo lo contrario en sistemas que utilizasen varios procesadores, ya que se dara el caso de que varios procesadores luchasen por obtener un objeto de la cache, provocando un bloqueo de la misma y dejando a los procesadores en un estado de espera. Para evitar que los procesadores tengan que luchar por un objeto de algunas de las caches, cada uno de los procesadores tendrn asignadas sus propias caches, evitando de esta forma los bloqueos.

Se ha implementado un sistema de tres capas: Capa de CPU. Capa de depsito. Capa de SLAB Las dos primeras capas organizan los objetos en arrays de un nmero N de objetos, dichos arrays se conocen como Magazine y son secillamente, arrays de punteros a objetos. La capa de CPU asigna una serie de Magazines a cada una de las CPUs del sistema, dichos Magazines garantizan que una CPU puede realizar al menos N operaciones de asignacin o liberacin de un objeto. El nmero de objetos por magazine vara dinmicamente dependiendo de la cantidad de peticiones que se realizan a la capa de depsito NOTA El uso del termino Magazine se debe al uso que se realiza en Ingls de esta palbra para referirse a los cargadores de las armas automticas, por lo que debemos entenderla como un cargador, donde las objetos se corresponderan con las balas. Cuando una CPU necesita un objeto lo solicita a la cache que tiene asignada, esta cache dispone de dos magazines, llamados magazine cargado y magazine previamente cargado, el objeto solicitado es extraido del magazine cargado. Los magazines funcionan como una pila de objetos, manteniendo informacin sobre el tipo de objeto y el nmero de objetos disponibles en el magazine. Si la CPU solicita un objeto al magazine y ste se encuentra vacio, pero se puede utilizar un objeto del magazine previamente cargado entonces se realiza un intercambio entre estos 2 magazines. Si ninguno de los magazines se pueden utilizar para satisfacer la necesidad de un objeto por parte de la CPU, en este caso el magazine cargado es pasado al previamente cargado y se solicita un magazine a la capa inferior, la capa de depsito. Pero los magazines de la CPU no solo se sustituyen cuando estn vacios sino tambien cuando se llenan, ya que en caso de que la CPU desee liberar un objeto, este debe volver al magazine, al igual que ocurre con la operacin de retirada de un objeto, si se intenta devolver un objeto y el magazine cargado est lleno y se puede utilizar el magazine previamente cargado, se realiza un intercambio entre ambos, para que se puede dejar el objeto. En caso de que no se pueda utilizar ninguno de los magazines, se debe solicitar a la capa de depsito un nuevo magazine que est vacio. La capa de depsito dispone de dos listas, las cuales contienen los magazines, llenos y vacios. Parmetros del Kernel De todos los parmetros del Kernel disponible, existen 3 que son interesante que conozcamos si vamos a modificar el comportamiento del Kernel a la hora de trabajar con los objetos de los distintos magazines.

Con mdb podemos echar un vistazo a los valores de estos 3 parmetros:

Con el comando ::kmastat de mdb, podemos ver el uso que est haciendo el sistema de los distintos magazines que se han creado.
root@host # mdb -k Loading modules: [ unix genunix specfs dtrace ufs sd mpt px ldc ip hook neti sctp arp usba fcp fctl emlxs nca lofs zfs random nfs sppp crypto ptm md cpc fcip logindmux ipc ] > ::kmastat cache buf buf buf memory alloc alloc name size in use total in use succeed fail ------------------------- ------ ------ ------ --------- --------- ----kmem_magazine_1 16 3703 26416 425984 117757 0 kmem_magazine_3 32 11865 36068 1163264 187112 0 kmem_magazine_7 64 14718 52070 3358720 246824 0 kmem_magazine_15 128 17824 38997 5070848 298984 0 kmem_magazine_31 256 2484 10695 2826240 57060 0 kmem_magazine_47 384 2120 2373 925696 18681 0 kmem_magazine_63 512 0 330 180224 3168 0 kmem_magazine_95 768 544 1370 1122304 4421 0 kmem_magazine_143 1152 17513 17521 20504576 74371 0 kmem_slab_cache 56 141733 170230 9617408 194782 0 kmem_bufctl_cache 24 368335 399681 9658368 438525 0 kmem_bufctl_audit_cache 128 0 0 0 0 0 kmem_va_8192 8192 158463 186656 1529085952 258293 0 kmem_va_16384 16384 2159 2512 41156608 7103 0

kmem_va_24576 kmem_va_32768 kmem_va_40960 kmem_va_49152 kmem_va_57344 kmem_va_65536 kmem_alloc_8 kmem_alloc_16 kmem_alloc_24 kmem_alloc_32 kmem_alloc_40 kmem_alloc_48 kmem_alloc_56 kmem_alloc_64 kmem_alloc_80 kmem_alloc_96 kmem_alloc_112 kmem_alloc_128 >> More [, , q, n, c, a] ?

24576 968 980 32768 2139 2144 40960 65 72 49152 0 0 57344 66 68 65536 0 0 8 127593 132210 16 44304 48768 24 59889 71868 32 24623 66294 40 18312 40194 48 57996 96330 56 51772 74240 64 33247 145161 80 135877 225836 96 95371 157836 112 51425 73800 128 81531 118881

25690112 70254592 3145728 0 4456448 0 1064960 786432 1736704 2138112 1622016 4669440 4194304 9363456 18317312 15392768 8396800 15458304

1180 3540 72 0 66 0 192956965 154080669 47239399 126889256 54706405 38173148 85700241 678235324 111788983 46351102 13371716 27763230

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

De la salida anterior, una de las columnas importantes es alloc fail, esta columna debera estar en 0, ya que en caso contrario tendramos un problema de memoria disponible, el sistema estara intentando reserver memoria, la cual no est disponible y por lo tanto se producira un problema en la gestin de los objetos de una magazine.

You might also like