OpenSolaris
Upcoming SlideShare
Loading in...5
×
 

OpenSolaris

on

  • 5,249 views

 

Statistics

Views

Total Views
5,249
Views on SlideShare
5,219
Embed Views
30

Actions

Likes
1
Downloads
55
Comments
0

1 Embed 30

http://www.slideshare.net 30

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

OpenSolaris OpenSolaris Presentation 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)# ls 0         14470  18279  19575  22216  2496   28190  3782   4622   605 1          1464   18340  19604  22610  25190  28252  398    4636   606 10192   1465   18709  19634  22645  25229  285    421      472    6347 10622   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: Procesos Ejemplo: (root@carlos)# cd 29039 (root@carlos)# ls ­l total 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 ctl lr­x­­­­­­   1 noxos   noxos         0 May 16 12:13 cwd ­> dr­x­­­­­­   2 noxos   noxos      8208 May 16 12:13 fd ... (root@carlos)#    
  • OpenSolaris: Procesos Ficheros: ➢ /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 pagesize podemos 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 ­k Loading 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 el 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 Pablo Coronel Brayann Peralta Diego Román Carlos