opensolaris
TRANSCRIPT
OpenSolaris 2008.05
OpenSolaris Indiana 2008.05 en una máquina virtual creada con VirtualBox 1.6 bajo el Sistema Operativo Kubuntu 8.04
Amd64
OpenSolaris: Procesos
➢ Los ficheros mantienen información sobre los distintos procesos que se están ejecutando en la máquina, OpenSolaris utiliza un pseudo sistema de ficheros llamado Procfs , en el cual, el kernel mantiene información sobre los procesos que está corriendo.
➢ El sistema de archivos procfs está organizado en directorios, uno por cada proceso en que se ejecuta en la máquina, los directorios se llaman con el PID del proceso del cual mantienen la información. Ejemplo:
OpenSolaris: Procesos
(root@Carlos)# cd /proc(root@Carlos)# ls0 14470 18279 19575 22216 2496 28190 3782 4622 6051 1464 18340 19604 22610 25190 28252 398 4636 60610192 1465 18709 19634 22645 25229 285 421 472 634710622 14896 18779 2 23054 25479 28610 4210 476 664...
(root@Carlos)#
➢ Cada uno de estos ficheros que representa a un proceso contiene una serie de ficheros y directorios, de los cuales podemos obtener información sobre el proceso y todos sus LWP.
OpenSolaris: ProcesosEjemplo:
(root@carlos)# cd 29039(root@carlos)# ls ltotal 5933rw 1 noxos noxos 2998272 May 16 12:13 asr 1 noxos noxos 152 May 16 12:13 auxvr 1 noxos noxos 36 May 16 12:13 credw 1 noxos noxos 0 May 16 12:13 ctllrx 1 noxos noxos 0 May 16 12:13 cwd >drx 2 noxos noxos 8208 May 16 12:13 fd...
(root@carlos)#
OpenSolaris: ProcesosFicheros:➢ /proc/< pid >/as➢ /proc/< pid >/auxv➢ /proc/< pid >/cred➢ /proc/< pid >/ctl➢ /proc/< pid >/cwd➢ /proc/< pid >/fd/➢ /proc/< pid >/psinfo➢ /proc/< pid >/map➢ /proc/< pid >/object/➢ /proc/< pid >/pagedata➢ /proc/< pid >/sigact➢ /proc/< pid >/status
OpenSolaris: Fallos
MDB (Modular Debugger) es una herramienta que nos puede ayudar a conocer las causas que provocaron un fallo, MDB trabaja con los ficheros core, que son una imagen de memoria del proceso que ha sufrido el fallo, esto nos permitía averiguar cuales fueron la causa de dicho fallo.
MDB no solo puede trabajar con los volcados de memoria de los procesos, sino que también lo puede hacer con las imágenes de memoria del kernel mientras este está ejecutándose, esto nos permite poder acceder a toda la información, si sabemos como leerla, con la que trabaja el kernel, lista de procesos, páginas de memoria, ficheros abiertos, listas de espera, conexiones de red, bloqueos, etc.
OpenSolaris: Fallos
Para que MDB acceda a la imagen del memoria del Kernel debemos saber como fichero objeto debemos utilizar /dev/ksyms el cual contiene la tabla de símbolos y como fichero core utilizaremos /dev/kmem, por lo tanto podemos ejecutar la siguiente línea.
(root@carlos)# mdb /dev/ksyms /dev/kmem
Loading modules: [ unix krtld genunix ip usba ipc random nfs ptm ]
>
OpenSolaris: Fallos
Lo que debemos conocer de MDB para comenzar a trabajar con él es que se basa en los siguientes tres elementos:
dmods son los módulos que se cargan en el debugger, dependiendo de los módulos que se hayan cargado podremos realizar más o menos acciones.
dcmds son los comandos que podemos utilizar en el debugger.
walkers son sencillos programas que nos permiten iterar sobre una serie de datos.
OpenSolaris: Paginación
Todos los procesos, disponen de su propio espacio de direcciones de memoria, los espacios de direcciones están formados por segmentos de memoria, un espacio de direcciones tiene al menos 4 segmentos de memoria, el de datos, el de texto, el de heap y el de stack. Cada segmento de memoria está formado por un número determinado de páginas de memoria.
Las páginas tienen un tamaño fijo, son de 8K, con el comando pagesizepodemos ver qué tamaños de página podemos utilizar en nuestro sistema y cual es el tamaño por defecto (8k). Utilizando el ! podemos ejecutar comandos del sistema operativo dentro de mdb.
OpenSolaris: Paginación
Ejemplo:
(root@carlos)# mdb k
Loading modules: [ unix krtld genunix ip usba ipc random nfs ptm
> ! pagesize a
8192
65536
>
El tamaño de página por defecto es 8K, aunque podemos disponer de páginas de 8K,64K, 512K y 4MB, el tamaño de página se define en el momento del arranque, por lo que no se puede cambiar en caliente,
OpenSolaris: Segmentación Al menos existen 4 segmentos: Texto, Datos, Heap, Pila.
MDB nos ayuda para conocer los distintos segmentos que están asignados al espacio de direcciones de un proceso. Para nuestro ejemplo crearemos un nuevo proceso lanzando el comando sleep 50000 en background.[1] 1788
(root@carlos)#(root@carlos)# mdb kLoading modules: [ unix krtld genunix ip usba ipc random nfs ptm ]> 0t1788::pid2proc |::print proc_t p_as |::walk seg |::seg SEG BASE SIZE DATA OPS 3007d839f80 10000 2000 3000863d598 segvn_ops 300881d6d38 20000 2000 3578600afe8 segvn_ops 3015579b128 22000 2000 3007d8469c0 segvn_ops
OpenSolaris: Segmentación...
35785fea3a8 ff3a0000 2000 3578601aa38 segvn_ops 3007d8661b0 ff3b0000 2e000 3578dae20e8 segvn_ops 3007d842120 ff3ee000 2000 301b3697bb8 segvn_ops 30008602678 ff3f0000 2000 3578da37e90 segvn_ops 3578da9d5a8 ffbfe000 2000 3000369f590 segvn_ops> En el sistema existen varios tipos de segmentos de memoria, dependiendo
de la funcionalidad para la que se crearon, así podemos encontrar segmentos de tipo seg_map, seg_kmem, seg_dev o seg_vn, entre otros. Todos los segmentos son de tipo struct seg y lo que los diferencia entre ellos, es el tipo de operaciones y el tipo de dato al que apunta el puntero del campo s_data, por esta razón, este campo es un puntero void.
OpenSolaris: Semáforos
En OpenSolaris existe un elemento llamado Sets de semáforos, el cual es en realidad un grupo de semáforos, no existen los semáforos independientes, es decir, cuando nuestra aplicación necesita un semáforo le solicita al Kernel un Set de semáforos, el cual tendrá un número determinado de ellos mediante la llamada a sistema semget( ) , que acepta como parámetros una key que define al set de semáforos, el número de los semáforos del set y los permisos que tendrá el set de semáforos
OpenSolaris: Semáforos
En esta versión los límites de los semáforos los podemos aplicar a proyectos o procesos. Para ver como están configurados los límites de los semáforos mediante el control de recursos debemos utilizar el comando rctladm.
(root@carlos_10)# rctladm l | grep sem
process.maxsemops syslog=off [ deny count ]
process.maxsemnsems syslog=off [ deny count ]
project.maxsemids syslog=off [ nobasic deny count ]
(root@carlos_10)#
OpenSolaris: Caché
Dependiendo del tipo de procesador con el que se esta trabajando, el tamaño y número de niveles varía, así en el procesador como el UltraSparc V+ existen 3 niveles en la jerarquía de cache.
Nivel L1: Es la memoria más rápida con la que trabaja el procesador, aunque presenta el inconveniente de su reducido tamaño.
Nivel L2: Es más lenta que la cache L1 aunque presenta la ventaja que es mayor tamaño.
Nivel L3: Es la cache más lenta y está situada fuera del chip, el tamaño de esta cache en el procesador UltraSPARC V+ es de 32MB.
OpenSolaris: Intercambio
El sistema de memoria virtual (VM) de Solaris utiliza una nueva capa, denominada swapfs, que consiste en un sistema de archivos que gestiona el área de swap, de tal forma que en el área de swap únicamente se ocupará espacio cuando el sistema lo necesite y no cada vez que un proceso realice una petición de memoria.
Cuando un proceso solicita una cantidad de memoria, supongamos que mediante la llamada malloc() realiza una petición de 16K, esto significa que el sistema reservará 2 páginas de memoria (suponiendo que el tamaño de la página sea de 8K), estas nuevas páginas deben tener asignadas a un vnode, como el resto de páginas de memoria, estas nuevas páginas son páginas anónimas por lo que el vnode debe ser el área de swap.
OpenSolaris: Intercambio
El Kernel utiliza la capa de swapfs para gestionar la asignación de los vnodes a las nuevas páginas anónimas que se creen, mientras una página que ha sido solicitada no sea necesario llevarla al área de swap, no tendrá asignado ningún espacio en dicho área.
Algo que debemos tener claro para entender cómo funciona swapfs es lo siguiente, swapfs trabaja con un espacio virtual de swap el cual está compuesto por e l espacio f ísico de swap, es decir, todos los discos o ficheros que se hayan asignado al espacio de swap, mas toda la memoria física del sistema que pueda ser paginable. Es decir swapfs además de utilizar los ficheros o discos que hayamos asignado al área de swap, también utilizará toda la memoria disponible en el sistema.
Espacio virtual de swap = Espácio de swap + Memoria física
OpenSolaris: Deadlocks
OpenSolaris proporciona varias herramientas que permiten garantizar que un dato solo es accedido por un thread o por varios pero teniendo solo uno de ellos acceso como escritura.
El bloqueo mas comúnmente usado es el de exclusión mutua (mutex), dando acceso de lectura y escritura a un único thread.
Cuando vayamos a acceder para leer o modificar un dato, por ejemplo la lista de una cola de ejecución, podemos encontrar que su bloqueo se encuentre libre o ocupado: Si el bloqueo se encuentra libre, nos adueñaremos de el, realizaremos las acciones oportunas, y lo liberaremos de nuevo.
Si el bloqueo está ya ocupado se usa: Spin Mutex o Mutex Adaptive
OpenSolaris: Hilos
OpenSolaris es un sistema multithread donde cada uno de los hilos de un proceso puede tener una prioridad distinta, además esta es dinámica, es decir durante su vida puede variar en función de varios parámetros, como pueda ser la carga el sistema, como interactúe con otros hilos.
Cuando un threads es creado en Solaris se asigna a una scheduling class, para que nos entendemos esta define el rango de prioridades en el que fluctuará durante su vida. Existen 6 rangos distintos:
Timeshare (TS) : Es la scheduling class por defecto, la prioridad del hilo aumenta a medida que va esperando un cpu libre, una vez consiga cpu se ejecutará hasta que se agote su quantum.
OpenSolaris: Hilos
Interactive (IA): Parecida a la anterior, para entornos de escritorio, los threads correspondientes a los procesos X window reciben un incremento de prioridad.
Fair Share (FSS): El tiempo de cpu se divide en unidades llamadas shares, cada thread puede consumir x shares dependiendo del número de threads que hay en esa scheduling class, de su consumo reciente y de su prioridad.
Fixed Priority (FX): El thread tiene las misma prioridad durante todo su ciclo de vida.
Real Time (RT): Es el rango de prioridades altas, garantiza el mínimo tiempo de lantencia entre que el thread pasa a estado running hasta que se le asigna CPU.
System (SYS): Es la clase usada para los threads del kernel, tiene prioridad superior a las demás excepto la Real Time.
Créditos
Grupo de Trabajo:
Alvarado PabloCoronel Brayann
Peralta DiegoRomán Carlos