SafeChildren Banner

Havoc Oracle Solaris Experts

viernes, 26 de febrero de 2010

Manejo de Project y Configuraciones Dinámicas en Solaris 10 - Parte 2

Introducción
Hasta ahora hemos visto cómo gestionar los parámetros dinámicamente mediante el uso de <prctl> y project sin embargo, Cómo saber si se están superando los límites? Bien, para ello, tenemos el comando <rctladm> que nos permite examinar y modificar los parámetros globales de nuestro sistema de control de recursos.

Vamos a utilizar <rctladm> para habilitar el sistema de log y de esta forma, poder ver cuándo y quién está sobrepasando los límites que hemos asignado.

Si ejecutamos el comando <rctladm> sin ningún argumento, se nos mostrará el estado de cada una de las opciones del resource manager donde podremos ver si tenemos activado el sistema de log <syslog=notice> o, si por el contrario está apagado <syslog=off> -que es su valor por defecto-
# rctladm
process.max-port-events     syslog=off     [ deny count ]
process.max-msg-messages    syslog=off     [ deny count ]
process.max-msg-qbytes      syslog=off     [ deny bytes ]
process.max-sem-ops         syslog=off     [ deny count ]
process.max-sem-nsems       syslog=off     [ deny count ]
process.max-address-space   syslog=off     [ lowerable deny no-signal bytes ]
process.max-file-descriptor syslog=notice  [ lowerable deny count ]
process.max-core-size       syslog=off     [ lowerable deny no-signal bytes ]
process.max-stack-size      syslog=off     [ lowerable deny no-signal bytes ]
process.max-data-size       syslog=off     [ lowerable deny no-signal bytes ]
process.max-file-size       syslog=off     [ lowerable deny file-size bytes ]
process.max-cpu-time        syslog=off     [ lowerable no-deny cpu-time inf seconds ]
task.max-cpu-time           syslog=off     [ no-deny cpu-time no-obs inf seconds ]
task.max-lwps               syslog=notice  [ count ]
project.max-contracts       syslog=off     [ no-basic deny count ]
project.max-device-locked-memory syslog=off     [ no-basic deny bytes ]
project.max-locked-memory   syslog=off     [ no-basic deny bytes ]
project.max-port-ids        syslog=off     [ no-basic deny count ]
project.max-shm-memory      syslog=off     [ no-basic deny bytes ]
project.max-shm-ids         syslog=off     [ no-basic deny count ]
project.max-msg-ids         syslog=off     [ no-basic deny count ]
project.max-sem-ids         syslog=off     [ no-basic deny count ]
project.max-crypto-memory   syslog=off     [ no-basic deny bytes ]
project.max-tasks           syslog=off     [ no-basic count ]
project.max-lwps            syslog=off     [ no-basic count ]
project.cpu-cap             syslog=off     [ no-basic deny no-signal inf count ]
project.cpu-shares          syslog=n/a     [ no-basic no-deny no-signal no-syslog count ]
zone.max-swap               syslog=off     [ no-basic deny bytes ]
zone.max-locked-memory      syslog=off     [ no-basic deny bytes ]
zone.max-shm-memory         syslog=off     [ no-basic deny bytes ]
zone.max-shm-ids            syslog=off     [ no-basic deny count ]
zone.max-sem-ids            syslog=off     [ no-basic deny count ]
zone.max-msg-ids            syslog=off     [ no-basic deny count ]
zone.max-lwps               syslog=off     [ no-basic count ]
zone.cpu-cap                syslog=off     [ no-basic deny no-signal inf count ]
zone.cpu-shares             syslog=n/a     [ no-basic no-deny no-signal no-syslog count ]
Para activar el sistema de log simplemente deberemos ejecutar el siguiente comando
#  rctladm -e syslog __nombre.propiedad__
Y para desactivar el sistema de log
#  rctladm -d syslog __nombre.propiedad__
Como siempre, si intentamos hacerlo desde la zona no global Solaris nos mostrará el siguiente error:
# rctladm -e syslog project.max-port-ids
rctladm: unable to update control block contents: Not owner
De esta forma, cada vez que un recurso supere los límites que hemos definido -y esté activo el log- nos escribirá una entrada en </var/adm/message> de la zona global, indicando propiedad y límite superado
# tail -f /var/adm/messages
Feb 23 18:11:32 test genunix: [ID 120576 kern.notice] basic rctl process.max-file-descriptor (value 256) exceeded by process 323.
Veamos un ejemplo completo. Vamos a limitar el número de procesos ligeros que Apache HTTP Server puede crear, vamos a permitir sólo 5
# projmod -sK 'task.max-lwps=(priv,3,deny)' user.www
# /opt/www/apache-1.3.41/bin/apachectl stop
# /opt/www/apache-1.3.41/bin/apachectl start
# dmesg|tail

Feb 23 17:51:53 test genunix: [ID 748619 kern.notice] privileged rctl task.max-lwps (value 3) exceeded by process 24512 in task 32260.
Feb 23 17:51:57 test genunix: [ID 748619 kern.notice] privileged rctl task.max-lwps (value 3) exceeded by process 24526 in task 32260.
Feb 23 17:51:58 test genunix: [ID 748619 kern.notice] privileged rctl task.max-lwps (value 3) exceeded by process 24533 in task 32260.
Como hemos visto en otras ocasiones, podemos modificar los valores de un proceso en ejecución sin tener que reiniciarlo, vamos a modificar el valor de max-lwps del PID 24582
# ps -u www -f
     UID   PID  PPID   C    STIME TTY         TIME CMD
     www 24582 24577   0 17:52:14 ?           0:00 /opt/www/apache-1.3.41/bin/httpd
     www 24581 24577   0 17:52:14 ?           0:00 /opt/www/apache-1.3.41/bin/httpd
     www 24579 24577   0 17:52:14 ?           0:00 /opt/www/apache-1.3.41/bin/httpd
     www 24580 24577   0 17:52:14 ?           0:00 /opt/www/apache-1.3.41/bin/httpd
     www 24691 24577   0 17:54:20 ?           0:00 /opt/www/apache-1.3.41/bin/httpd
     www 24578 24577   0 17:52:14 ?           0:00 /opt/www/apache-1.3.41/bin/httpd
# prctl -n task.max-lwps -i process 24582
process: 24582: /opt/www/apache-1.3.41/bin/httpd
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
task.max-lwps
        privileged        250       -   deny                                 -
# prctl -r -t priv -n task.max-lwps -v 350 -i process 24582
# prctl -n task.max-lwps -i process 24582
process: 24582: /opt/www/apache-1.3.41/bin/httpd
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
task.max-lwps
        privileged        350       -   none                                 -

<< Configuraciones Dinámicas Parte 1

Conclusión
Poco a poco vamos avanzando en el uso de Resource Manager y vemos como podemos aplicarlo a nuestras instalaciones. Os dejo que hagáis vuestras pruebas y ver cómo se comporta.

Referencias

miércoles, 24 de febrero de 2010

Cómo saber el PID del proceso actual

Introducción
Para saber el PID del proceso actual, simplemente debemos utilizar la variable de $$, así que si hacemos un <echo $$> nos devolverá el PID de nuestro Shell
$ ps -f -u postgres |grep bash|grep -v grep
postgres  4518  3433   0 20:36:59 pts/7       0:00 -bash
$ echo $$
4518

Referencias

lunes, 22 de febrero de 2010

Número de descriptores de ficheros abiertos en Solaris 10

Introducción
Por defecto, Solaris viene con una configuración muy conservadora, y por lo tanto, debemos ajustar algunos parámetros, entre ellos, el número máximo de descriptores de ficheros.

Este parámetro antiguamente había que declararlo en el archivo </etc/system> y requería un reboot del sistema para que se aplicara.

En Solaris 10 esto ya no es necesrio y se puede gestionar con una propiedad del proceso <process.max-file-descriptor> y, por lo tanto gestionable en caliente. Ya hemos visto en post anteriores como Gestionar Dinámicamente Parámetros en Solaris 10, pues bien, ahora vamos a ver otra aplicación del comando <prctl>

Para aquellos que tengaís Solaris 9 u 8, para poder definir el número máximo de descriptores permitidos hay que declarar las siguientes variables en el archivo de configuración </etc/system>. Recordar que este archivo es muy importante, y si tiene errores sintácticos Solaris NO Arrancará, así que editarlo con cuidado y recordar que los comentarios empiezan con "*" y no con "#"


Solaris 8 y 9

# vi /etc/system
  *
  * rflim_fd_max
  *       Limite de descriptores maximos de archivos abiertos
  *       por defecto: 1024
  *
  set rlim_fd_max=16384

  *
  * rlim_fd_cur
  *       por defecto: 64
  *
  set rlim_fd_cur=8192

:wq
Solaris 10
Ya hemos dicho que en Solaris 10 debemos utilizar <prctl> para gestionar estos parámetros dinámicos del sistema -si queremos podemos incluirlos en el /etc/system-
# echo $$
3433
# ulimit -a
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
open files                    (-n) 8192
pipe size          (512 bytes, -p) 10
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 29980
virtual memory        (kbytes, -v) unlimited
# prctl -r -t privileged -n process.max-file-descriptor -v 1024 -i process 3433
# ulimit -a                                                                   
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 10
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 29980
virtual memory        (kbytes, -v) unlimited
Hemos utilizado el comando <prctl> para modificar el valor de descriptores máximos permitidos al proceso 3433. Ahora bien, si queremos que la configuración se aplique a un conjunto de procesos, utilizaremos un project e incluiremos la propiedad en la definición.

Por ejemplo, para permitir que el usuario postgres tenga 1024 descriptores de archivos, haremos lo siguiente -asumimos que existe un project para el grupo postgres:
# projmod -sK 'process.max-file-descriptor=(priv,1024,deny)' group.postgres                                                                         
# su - postgres

POSTGRES VERSION: 8.4
POSTGRES HOME   : /u01/app/postgres/8.4/db
PGDATA          : /var/postgres/8.4/data
PGARCH          : 64

$ ulimit -a
core file size        (blocks, -c) unlimited
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 10
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 29980
virtual memory        (kbytes, -v) unlimited

Conclusión
Hemos visto como editando el archivo </etc/system> se puede tunear muchos límites que en la versión inicial de Solaris debemos mejorar. Además si todavía eres de los que no ven claro los project y la configuración dinámica aquí tienes una excusa nueva para, poco a poco, enamorarte de esta funcionalidad.


Referencias

viernes, 19 de febrero de 2010

Actualizar Guest Additions de Virtual Box para Solaris 10

Introducción
Con cada nueva versión de VirtualBox, debemos instalar el paquete VBoxGuest que se encluye. Sin embargo, si intentamos hacerlo sin desinstalar la versión anterior, Solaris nos informará de que no es posible tener varias instalaciones del paquete y por ello debemos primero desinstalarlo.

Veamos un ejemplo del error que nos mostrará Solaris
# cd /cdrom/
bash-3.00# ls -l
total 10
lrwxrwxrwx   1 root     nobody        27 feb 18 22:34 cdrom0 -> ./vboxadditions_3.1.4_57640
drwxr-xr-x   2 root     nobody       512 dic  1 23:10 vboxadditions_3.1.0_55467
drwxr-xr-x   2 root     nobody       512 ene 10 12:29 vboxadditions_3.1.2_56127
dr-xr-xr-x   2 root     sys         2048 feb 12 20:32 vboxadditions_3.1.4_57640
# cd vboxadditions_3.1.4_57640/
# pkgadd -G -d VBoxSolarisAdditions.pkg

The following packages are available:
  1  SUNWvboxguest     Sun VirtualBox Guest Additions
                       (i386) 3.1.4,REV=r57640.2010.02.12.20.26

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:all

Procesando versión del software desde

Sun VirtualBox Guest Additions(i386) 3.1.4,REV=r57640.2010.02.12.20.26

La administración actual precisa la creación de una única versión del
paquete . No obstante, ya se ha alcanzado el numero
máximo de versiones del paquete que pueden admitirse a la vez en el
mismo sistema.

No se hicieron cambios en el sistema.
Ahora, vamos a ver cómo podemos hacer la instalación de forma correcta. Para ello, primero debemos eliminar el paquete SUNWvboxguest y lo volveremos a instalar.
# pkgrm SUNWvboxguest

El siguiente paquete se está instalado en este momento:
   SUNWvboxguest  Sun VirtualBox Guest Additions
                  (i386) 3.1.1,REV=r56127.2009.12.17.13.24

?Quiere eliminar este paquete? [y,n,?,q] y

## Eliminando entrada de paquete instalado

Este paquete contiene archivos de comandos que serán ejecutados con
permiso de superusuario durante el proceso de instalación de este
paquete.

Quiere continuar con la eliminación de este paquete [y,n,?,q] y
## Verificando las dependencias del paquete en la zona global
## Procesando información del paquete.
## Ejecutando secuencia de pre-eliminación.
Sun VirtualBox Guest Additions - preremove script
This script will unload the VirtualBox Guest kernel module...
VirtualBox FileSystem kernel module not loaded.
VirtualBox guest kernel module unloaded.
Restoring X.Org...
Done.
## Borrar nombre de rutas de acceso en clase
## Borrar nombre de rutas de acceso en clase
...

...
...
## Actualizando información del sistema.

Quitar se hizo con éxito.
# pkgadd -G -d VBoxSolarisAdditions.pkg
The following packages are available:
  1  SUNWvboxguest     Sun VirtualBox Guest Additions
                       (i386) 3.1.4,REV=r57640.2010.02.12.20.26

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: all


...
... mensajes de información de la instalación
... 
Por último, simplemente rebotaremos el sistema y ya tendremos la nueva versión. Para comprobar la nueva versión instalada utilizaremos el comando <pkginfo>
# pkginfo -l SUNWvboxguest
   PKGINST:  SUNWvboxguest
      NAME:  Sun VirtualBox Guest Additions
  CATEGORY:  application
      ARCH:  i386
   VERSION:  3.1.4,REV=r57640.2010.02.12.20.26
   BASEDIR:  /
    VENDOR:  Sun Microsystems, Inc.
      DESC:  VirtualBox Guest Additions for Solaris guests
    PSTAMP:  vboxguest20100212202648_r57640
  INSTDATE:  feb 18 2010 22:50
   HOTLINE:  Please contact your local service provider
     EMAIL:  info@virtualbox.org
    STATUS:  completely installed
     FILES:       51 installed pathnames
                   3 linked files
                   4 directories
                  18 executables
                   1 setuid/setgid executables
               16473 blocks used (approx)
Referencias

miércoles, 17 de febrero de 2010

Solaris Network Cache and Accelerator, Cache Web a Nivel de Kernel - Parte 1

Introducción
Solaris Network Cache and Accelerator (NCA) es un sistema de caché a nivel de kernel. Se encarga de mantener las páginas más accedidas a nuestro servidor web en memoria incrementando el rendimiento de nuestros servidores Web.

Actualmente los servidores que soportan este funcionamiento optimizado en Solaris -sin cambios- son: Apache incluido en Solaris, Sun Web Server y Zeus. El funcionamiento se basa en la modificación del tipo de socket AF_INET por AF_NCA. No quiero entrar en mucho detalle de su funcionamiento, pero se basa en el uso de memoria compartida y un sistema de acceso rápido.

Y qué pasa con los Apaches -compilados- por nosotros que no tienen soporte nativo para AF_NCA? No hay problema. Simplemente deberemos precargar la bilbioteca /usr/lib/libnca_addr.so antes de ejecutar nuestros servicios (para 32bits) y /usr/lib/64/ncad_addr.so para 64bits.

Como hemos comentado en otras ocasiones, para precargar una biblioteca simplemente exportaremos la variable de entorno LD_PRELOAD_32 o LD_PRELOAD_64

Activar NCA
Para activar NCA, simplemente deberemos editar los archivos /etc/nca/nca.if y /etc/nca/ncakmod.conf y reiniciar la máquina. Veamos los sencillos pasos, lo primero que debemos hacer, es activar los interfaces en los cuales NCA va a escuchar -en el archivo /etc/nca/nca.if-. Los interfaces deben tener el archivo /etc/hostname._interface_ creado y dado de alta en el archivo /etc/hosts
# vi /etc/nca/nca.if
ce0
:wq
# ls -ltr /etc/hostname.ce0
-rw-r--r--   1 root     root          16 oct 15 13:35 /etc/hostname.ce0
# vi /etc/nca/ncakmod.conf
 status=enabled
 httpd_door_path=/var/run/nca_httpd_1.door
 nca_active=disabled
:wq
El módulo NCA, por defecto escucha en el puerto 80, pero podemos definir los puertos -y las IPs- en los que queremos que lo haga editando el archivo /etc/nca/ncalogd.conf
# cat /etc/nca/ncaport.conf
 ncaport=*/80
 ncaport=*/8080
:wq
Por último, podemos activar -no es obligatorio- el sistema de Log, editando el archivo /etc/nca/ncalogd.conf y pondremos la variable status=enabled y reiniciaremos la máquina para que los cambios tengan efecto.
# vi /etc/nca/ncalogd.conf
 status=enabled
 logd_path_name="/var/nca/log"
 logd_file_size=1000000
:wq
# reboot
Conclusiones
En esta primera parte hemos visto cómo activar NCA es realmente sencillo. En las siguientes partes, veremos si el Caché a nivel de kernel, es una solución aplicable a nuestra arquitectura.

Es muy importante tener en cuenta que si activamos NCA, es muy recomendable -si tenemos un volumen muy elevado de peticiones- que la dediquemos exclusivamente como servicio Web, o al menos, que intentemos limitar el número de procesos  de kernel para evitar sustos.

Referencias