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 5933­rw­­­­­­­   1 noxos   noxos   2998272 May 16 12:13 as­r­­­­­­­­   1 noxos   noxos       152 May 16 12:13 auxv­r­­­­­­­­   1 noxos   noxos        36 May 16 12:13 cred­­w­­­­­­­   1 noxos   noxos         0 May 16 12:13 ctllr­x­­­­­­   1 noxos   noxos         0 May 16 12:13 cwd ­>dr­x­­­­­­   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.max­sem­ops         syslog=off     [ deny count ]

process.max­sem­nsems       syslog=off     [ deny count ]

project.max­sem­ids         syslog=off     [ no­basic 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