![[índice]](../../images/back.gif){kind=small}
![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[Índice de documentos] [Sección 10 - Gestión del sistema] [Sección 12 - Cuestiones sobre plataformas específicas]
Es probable que quien tenga un servidor, una pasarela, o un cortafuegos con mucha carga, prefiera o necesite realizar algunos ajustes en los parámetros predeterminados con el fin de obtener un rendimiento óptimo. En la página del manual de options(4) se encuentran las opciones de configuración existentes para el núcleo del sistema. Estas opciones se deben escribir en el fichero de configuración del núcleo antes de compilar un núcleo personalizado, y algunas opciones se pueden configurar mediante el fichero config(8). Véase el capítulo 5 de estas preguntas frecuentes para obtener más detalles sobre la configuración e instalación del núcleo del sistema.
Un parámetro que puede ser necesario cambiar para un servidor, pasarela, o cortafuegos con mucha carga, es NMBCLUSTERS. Esta opción controla el tamaño del mapa de asignación de grupos (clusters) del núcleo, mbuf. Si se reciben mensajes en la máquina del tipo "mb_map full", entonces es necesario incrementar el valor de este parámetro. Si en una interfaz de red el tráfico se parara sin un motivo aparente, podría ser una indicación de que es necesario incrementar el valor de NMBCLUSTERS. Un valor razonable en la plataforma i386 con la mayoría de interfaces de ethernet de 100Mbps (no importa cuántas tenga la máquina), es 8192.
option NMBCLUSTERS=8192
El número de NMBCLUSTERS predeterminado varía según la plataforma, y va desde 256 hasta 2048. El valor de este número se determina en un fichero de cabecera dependiente de la plataforma, a menos que se anule mediante una opción en el fichero de configuración del núcleo.
NMBCLUSTERS también se puede modificar usando config(8), lo que elimina la necesidad de tener que compilar un nuevo núcleo y basta con reiniciar para cambiar esta opción.
# config -e -o bsd.new /bsd
OpenBSD 3.4 (GENERIC) #18: Wed Sep 17 03:34:47 MDT 2003
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Enter 'help' for information
ukc> nmbclust
nmbclusters = 2048
ukc> nmbclust 8192
nmbclusters = 8192
ukc> quit
Saving modified kernel.
Con esto se crea un nuevo núcleo, bsd.new, en el directorio apropiado, y se modifican los parámetros de NMBCLUSTERS del núcleo actual. Si todo se ha realizado correctamente, no hay que olvidarse de copiar bsd.new a /bsd antes de reiniciar el sistema.
La velocidad de E/S del disco es un hecho significativo en la velocidad total de la máquina. Su importancia es aún mayor cuando la máquina en cuestión es la anfitriona en un entorno multiusuario (usuarios de todas clases, desde los que ingresan de modo interactivo hasta los que la usan como un servidor de ficheros, o un servidor de web... ). El almacenamiento de datos requiere antención constante, y en especial cuando las particiones se quedan sin espacio o cuando los discos fallan. OpenBSD dispone de varias opciones para incrementar la velocidad de las operaciones del disco y para proveer tolerancia ante los fallos.
Índice de contenidos
La primera opción es usar ccd(4), el «Controlador de Discos Concatenados» (Concatenated Disk Driver). Este controlador permitirá unir varias particiones en un sólo disco virtual (y por tanto, la posibilidad de hacer que varios discos parezcan uno sólo). Este concepto es similar al de LVM («gestión lógica de volumen»), que se encuentra en muchos Unix comerciales.Si se está usando el núcleo GENERIC, ccd ya se encuentra activado de forma predeterminada (en /usr/src/sys/conf/GENERIC). Si se ha personalizado el núcleo del sistema, es probable que haya que volver a incluirlo en la configuración del núcleo. De cualquier modo, tiene que existir una línea como la siguiente en el fichero de configuración del núcleo:
pseudo-device ccd 4 # concatenated disk devicesEl ejemplo anterior vale para un máximo de 4 dispositivos ccd (discos virtuales). Ahora es necesario saber qué particiones de los discos reales se quiere dedicar para ccd. Para marcar estas particiones como tipo 'ccd' se debe usar disklabel(5). En algunas arquitecturas es probable que disklabel no permita hacerlo. En este caso hay que marcarlas como 'ffs'.
Si se usa ccd para desmontarlo y ganar así rendimiento, nótese que no se obtendrá un rendimiento óptimo a menos que se use el mismo modelo de discos con las mismas configuraciones de disklabel(5).
Hay que editar /etc/ccd.conf y modificarlo para que quede parecido a lo siguiente (para más información sobre la configuración de ccd, véase ccdconfig(8)):
# Fichero de configuración para dispositivos de discos # concatenados # # ccd ileave flags component devices ccd0 16 none /dev/sd2e /dev/sd3ePara que los cambios surtan efecto hay que ejecutar lo siguiente:
# ccdconfig -CMientras /etc/ccd.conf exista, ccd se configurará a sí mismo de forma automática durante el arranque. Ahora ya tenemos un nuevo disco, ccd0, una combinación de /dev/sd2e y /dev/sd3e. A continuación se usará disklabel sobre el nuevo disco como se haría normalmente para crear la partición o particiones que se quieran utilizar. No se debe usar la partición 'c' como si fuera una partición normal. Es necesario asegurarse de que las particiones utilizables están, como mínimo, un cilindro más allá del comienzo del disco.
Otra solución es raid(4), para lo que habrá que utilizar raidctl(8) para controlar los dispositivos de raid. En OpenBSD, RAID está basado en el porte de NetBSD de Greg Oster del software CMU RAIDframe. OpenBSD tiene soporte para los niveles 0, 1, 4 y 5 de RAID.Con raid, como con ccd, el soporte debe residir en el núcleo del sistema. A diferencia de ccd, el soporte para RAID no está activado en el núcleo GENERIC, y se debe compilar con el núcleo (el soporte para RAID añade unos 500Kb al tamaño de un núcleo para i386).
pseudo-device raid 4 # RAIDframe disk deviceLa configuración de RAID en algunos sistemas operativos es, cuanto menos, confusa y complicada. No es lo mismo con RAIDframe. La información completa sobre esto se encuentra en las páginas del manual de raid(4) y raidctl(8). Existen muchas opciones y posibles configuraciones disponibles, y una explicación detallada iría más allá del objetivo de este documento.
En servidores de archivos con memoria de sobra se puede incrementar BUFCACHEPERCENT. O sea, determinar qué porcentaje de la memoria de acceso aleatoria (RAM) debería usarse como sistema de archivos de memoria intermedia. Esta opción puede cambiar cuando el «caché de memoria intermedia unificado» (Unified Buffer Cache) se haya completado y forme parte de OpenBSD. Mientras tanto, para incrementar BUFCACHEPERCENT es necesario añadir una línea como la siguiente a la configuración del núcleo:
option BUFCACHEPERCENT=30
Se puede hacer que sea un porcentaje tan bajo como el 5% (predeterminado), o tan alto como el 50% (o más si fuera necesario).
BUFCACHEPERCENT también se puede modificar usando config(8), tal y como se explica en la sección sobre ``Redes'', lo que elimina la necesidad de tener compilar un núcleo sólo para cambiar esta opción.
Otra herramienta que se puede usar para aumentar la velocidad del sistema es softupdates. Una de las operaciones más lentas en el sistema de archivos tradicional de BSD es la actualización de la metainformación (que ocurre, entre otras, cuando se crean o generan ficheros y directorios). Softupdates intenta actualizar la metainformación en la memoria de acceso, RAM, en lugar de escribir al disco duro cada vez que se actualiza la metainformación. Otro efecto de esto es que la metainformación en el disco debería estar siempre completa, aunque no siempre actualizada. Por lo tanto, tras un caída del sistema no debería ser necesaria la comprobación y reparación de la consistencia de los sistemas de archivos con fsck(8) durante el arranque, sino simplemente la ejecución de una versión de fondo de fsck(8) que realice cambios de la metainformación en la RAM (como softupdates). Esto implica que reiniciar un servidor será mucho más rápido, ya que no será necesario esperar a que termine fsck(8) (OpenBSD todavía no dispone de esta funcionalidad). Hay más información al respecto en la sección del capítulo 14 que trata sobre SoftUpdates.
NVNODE=integer
del núcleo. Esto ya no es necesario y en su lugar se debe
utilizar la orden
sysctl(8).
El caché de traducción de nombre a nodo-i (también conocido como namei(3)) controla la velocidad de la traducción del nombre de la ruta (pathname) a inode(5). Esta memoria de caché tiene predeterminadas un número de entradas de NPROC * (80 + NPROC / 8). NPROC está configurado para 20 + 16 * MAXUSERS; en la página del manual de config(8) puede verse una explicación del parámetro de configuración del núcleo maxusers. Un modo razonable para la obtención de un valor derivado para el caché, en el caso en que un gran número de fallos de caché namei() fueran detectados con una herramienta como systat(1), sería examinar el valor actual computado por el sistema con sysctl(8) (que llama a este parámetro kern.maxvnodes), e incrementar este valor hasta que el número de aciertos del caché namei() mejore; o hasta que se determine que el sistema no obtiene un beneficio substancial de un incremento en el tamaño del caché namei(). Después de que el valor haya sido determinado, se puede fijar como valor predeterminado en el inicio del sistema con sysctl.conf(5).
(Nota: esta sección se centra fuertemente en la arquitectura de i386. Esto quiere decir que... otras arquitecturas no ofrecen tantas posibilidades de elección)
El rendimiento de las aplicaciones depende en gran medida del sistema operativo y de las facilidades que éste ofrezca. Ésta puede ser, en parte, la razón por la que alguien esté usando OpenBSD. El rendimiento de las aplicaciones tambiйn depende mucho del equipo sobre el que se utilicen. Para muchos usuarios, el ratio precio/rendimiento de un PC nuevo con un procesador Intel Pentium IV o AMD Athlon, es más importante que el ratio precio/rendimiento de una estación Sun UltraSparc 60. Aunque queda claro que el precio de OpenBSD no tiene competidor.
Si se está pensando en comprar un nuevo PC, tanto si se va a comprar por piezas o montado al completo, antes hay que asegurarse de que las partes que se vayan a comprar sean fiables. En el mundo del PC esto no es fácil. Componentes en mal estado o de escasa fiabilidad pueden hacer que OpenBSD funcione mal o sufra frecuentes caídas. El mejor consejo que podemos ofrecer es que se tenga cuidado, que se compren marcas y componentes que hayan sido revisados por una autoridad que sea de confianza. A veces, un ahorro en el precio de un PC puede significar una pérdida en calidad.
Hay algunas cosas que ayudarán a obtener el rendimiento máximo para un equipo:
Si se está montando un servidor y se necesita más de un disco, hay que tener en cuenta los discos SCSI. IDE se limita a dos discos por controladora, y el acceso concurrente a estos dos discos puede tener un impacto negativo sobre los resultados de E/S de los mismos. El límite de Wide SCSI es de 15 por controladora, y tiene mejor soporte que IDE para el acceso concurrente. Aunque SCSI sea más caro, la flexibilidad y el rendimiento justifican estos costes en algunos entornos.
Pregunta: «Yo simplemente ejecuto 'mount -u -o async /', lo que me
permite utilizar cierto paquete.
¿Por qué el montaje asincrónico no se usa por
definición (como en otros Unix)? ¿No es un modo mucho
más simple, y por lo tanto más seguro, que mejorar el
rendimiento de algunas aplicaciones?»
Respuesta: «Los montajes asincrónicos son más
rápidos que los montajes sincrónicos, pero también
son menos seguros. ¿Qué sucedería si hubiera un
fallo eléctrico? ¿O un problema de hardware? La
consecución de la velocidad no debe implicar el sacrificio de la
fiabilidad y estabilidad del sistema. Más información en
la página del manual de
mount(8).»
async Toda E/S al sistema de archivos debería llevarse
a cabo de forma asincrónica. Éste es un
indicador peligroso de activar, ya que no garantiza que
mantendrá una estructura consistente en el disco
del sistema de archivos. No se debe usar este
indicador a menos que se esté preparado para
recrear el sistema de archivos si hubiera una
caída del sistema. El uso más
común de este indicador es el de acelerar
restore(8), en donde se puede dar un factor de
incremento de doble velocidad.
Por otra parte, si se estuviera tratando con datos temporales que se pudieran recrear desde cero después de una caída del sistema, se podría ganar en velocidad usando una partición separada sólo para esos datos, montada en modo asincrónico. Esto sólo debe hacerse si no importa perder todos los datos en la partición cuando algo vaya mal. Las particiones de mfs(8) se montan en modo asincrónico, ya que se eliminan y se vuelven a generear durante cada vez que se reinicia.
Con monitores multi-sync se puede conseguir que un servidor de X funcione con una resolución aceptable. Si alguien ha intentado ajustar la frecuencia con las utilidades xf86config o XF86Setup, es probable que no habrá podido obtener resultados óptimos. Uno de los aspectos más difíciles es, precisamente, el de lograr que el monitor funcione con la resolución deseada y conseguir que la frecuencia de barrido vertical se configure como mínimo a 72-75Hz; una frecuencia en la que la pantalla parpadea es mucho menos visible para los humanos. Y al contrario, ¿qué ocurriría si se intentara ajustar con una frecuencia de barrido vertical muy baja? Se puede fijar a 50Hz para que pueda ser capturada en el vídeo sin que parpadee, pero los métodos para conseguirlo no están muy claros con las herramientas y la documentación incluidas en XFree86.
Con las resoluciones que utilizan muchos usuarios con monitores VGA de bajo precio (800x600, 1024x768, 1152x900, 1280x1024) es posible (por lo menos en monitores más nuevos) usar frecuencias de barrido vertical de 85Hz y superiores, y lograr así una imagen extremadamente pulida y clara. El servidor de X de XFree86 dispone de un mecanismo que permite describir en detalle el modo de vídeo deseado, y éste es el ModeLine. Un ModeLine tiene cuatro secciones: un número de una sola cifra para el reloj de pixelación (pixel clock), de cuatro cifras para los tiempos de refresco horizontales (horizontal timings), de cuatro cifras para los tiempos de refresco verticales (vertical timings), y una sección opcional con una lista de indicadores que especifican otras características del modo (como Interlace, DoubleScan, y muchas otras que se pueden ver en detalle en la página del manual de XF86Config(5)).
Generar un ModeLine es cosa de magia negra... pero por suerte existen unos guiones de ejecución (scripts) que generan este proceso. Uno de ellos es Colas XFree86 ModeLine Generator. El otro es The XFree86 Modeline Generator, hospedado en SourceForge. Hay otros disponibles en Freshmeat. Antes de poder usar estos generadores de ModeLine, es preciso conocer los límites de sincronización horizontal y vertical del monitor. Esta información suele aparecer en el manual del monitor, o en su defecto en las páginas del fabricante en Internet. Si no se encuentra en ninguno de estos dos sitios, algunas personas han recopilado listas con la información sobre varios monitores que se pueden encontrar en Internet.
Pongamos como ejemplo un monitor Dell D1226H. Después de un intensa búsqueda en las páginas de Dell, descubrimos que la frecuencia de barrido horizontal está entre 30-50KHz, y la vertical entre 50-160Hz. A continuación irémos a la página del generador ModeLine e introducirémos esta información. Acto seguido tendremos que especificar la frecuencia de barrido vertical mínima que deseamos. Cualquier frecuencia por encima de 72Hz producirá un leve parpadeo. Según se vaya incrementando la frecuencia, la imagen en pantalla irá apareciendo más clara.
Con toda esta información, el guión de ejecución
generará un ModeLine para cada una de las resoluciones 4x3
factibles que pueda soportar el monitor, por encima de la frecuencia de
barrido vertical mínima que hayamos introducido. Si alguien
introdujera las especificaciones anteriores para Dell y una frecuencia
de barrido vertical mínima de 75Hz, el guión le
mostraría algo como esto:
ModeLine "320x240" 20.07 320 336 416 448 240 242 254 280 #160Hz
ModeLine "328x246" 20.86 328 344 424 456 246 248 260 286 #160Hz
...
ModeLine "816x612" 107.39 816 856 1056 1136 612 614 626 652 #145Hz
ModeLine "824x618" 108.39 824 864 1064 1144 618 620 632 658 #144Hz
ModeLine "832x624" 109.38 832 872 1072 1152 624 626 638 664 #143Hz
...
ModeLine "840x630" 109.58 840 880 1080 1160 630 632 644 670 #141Hz
ModeLine "848x636" 110.54 848 888 1088 1168 636 638 650 676 #140Hz
...
ModeLine "1048x786" 136.02 1048 1096 1336 1432 786 788 800 826 #115Hz
ModeLine "1056x792" 136.58 1056 1104 1344 1440 792 794 806 832 #114Hz
ModeLine "1064x798" 137.11 1064 1112 1352 1448 798 800 812 838 #113Hz
...
ModeLine "1432x1074" 184.07 1432 1496 1816 1944 1074 1076 1088 1114 #85Hz
ModeLine "1576x1182" 199.86 1576 1648 2008 2152 1182 1184 1196 1222 #76Hz
ModeLine "1584x1188" 198.93 1584 1656 2016 2160 1188 1190 1202 1228 #75Hz
Ahora bien, las especificaciones de este monitor dicen que soporta
1600x1200 @ 75Hz, pero el guión de ejecución no nos da esa
resolución dentro de los 75Hz. Así pues, si de verdad se
desea una resolución exacta de 1600x1200, habrá que
disminuir un poco la frecuencia de barrido vertical mínima... (en
el ejemplo la bajaremos a 70Hz):
ModeLine "1592x1194" 197.97 1592 1664 2024 2168 1194 1196 1208 1234 #74Hz
ModeLine "1600x1200" 199.67 1600 1672 2032 2176 1200 1202 1214 1240 #74Hz
ModeLine "1608x1206" 198.65 1608 1680 2040 2184 1206 1208 1220 1246 #73Hz
ModeLine "1616x1212" 197.59 1616 1688 2048 2192 1212 1214 1226 1252 #72Hz
ModeLine "1624x1218" 199.26 1624 1696 2056 2200 1218 1220 1232 1258 #72Hz
ModeLine "1632x1224" 198.15 1632 1704 2064 2208 1224 1226 1238 1264 #71Hz
ModeLine "1640x1230" 199.81 1640 1712 2072 2216 1230 1232 1244 1270 #71Hz
ModeLine "1648x1236" 198.64 1648 1720 2080 2224 1236 1238 1250 1276 #70Hz
Aquí se puede ver que el monitor puede soportar 1600x1200 @ 74Hz cuando el ancho de banda (dot clock) se limita a 200MHz. El ancho de banda lo configuraremos de acuerdo con los límites definidos por el monitor.
Una vez que ya tengamos los ModeLines, los incluiremos en el fichero
/etc/X11/XF86Config, comentando los viejos ModeLines para que
podamos usarlos de nuevo si los nuevos no llegaran a funcionar. A
continuación escogeremos la resolución a la que queremos
que funcione. Primero averiguaremos si X está en modo acelerado
(suele estarlo con la mayoría de tarjetas de vídeo), para
saber cuál de las secciones "Screen" de
XF86Config debemos modificar. O, simplemente, modificaremos todas las
secciones "Screen".
Section "Screen"
Driver "Accel"
Device "Primary Card"
Monitor "Primary Monitor"
DefaultColorDepth 32
SubSection "Display"
Depth 32
Modes "1280x1024" "1024x768"
EndSubSection
La primera resolución que se verá a continuación de la línea "Modes" será la resolución con la que se iniciará X. Se puede pasar desde una hasta otra de las resoluciones que estén en esta lista desde X pulsando CTRL-ALT-<-> o CTRL-ALT-<+>. De acuerdo con la sección anterior, X intentará iniciar en modo de color de 32 bits (a través de la directiva DefaultColorDepth, sin la cual iniciaría en modo de color de 8 bits). La primera resolución que intentará usar será 1280x1024 (siguiendo el orden de la línea "Modes"). Nótese que "1280x1024" sólo es una clasificación para los valores en ModeLine.
Nótese asimismo que el guión generador de ModeLine dispone de opciones para relajar sus tiempos en los monitores más viejos o más pequeños, y que también tiene la capacidad de proveer ModeLines para resoluciones específicas. Dependiendo del tipo de hardware del que se disponga, es posible que no resulte fácil usarlo con las opciones predefinidas. Si la imagen es demasiado alta, demasiado ancha, o demasiado pequeña, o si está corrida horizontal o verticalmente, y si los controles del monitor no bastan para corregirlo, se puede usar xvidtune(1) para ajustar el ModeLine y sincronizarlo mejor con los tiempos del monitor.
En la mayoría de los monitores modernos no existe un límite fijo para el ancho de banda, por lo que no aparecen en la lista de especificaciones. Lo que ocurre es que cuanto más se incrementa el ancho de banda, más borrosa aparece la imagen en pantalla. En este caso se puede añadir el ancho de banda de la tarjeta de vídeo (también llamado dotclock) para hacer comprobaciones sin peligro de dañar el monitor, y disminuir de forma progresiva el ancho de banda con el fin de obtener una imagen nítida.
Si todo esto parece complicado e innecesario, es porque en realidad lo es. XFree86 4.0 aborda este problema y hace que este proceso sea mucho más fácil, ya que tiene varios modos integrados y es capaz de leer las capacidades de monitores plug and play a través DDC y DDC2.
El guión de ejecución Colas XFree86 ModeLine Generator se puede obtener desde http://koala.ilog.fr/ftp/pub/Klone/. También es necesario bajarse el intérprete Klone y compilarlo. Está en el directorio de portes como lang/klone. Los guiones de ejecución se encuentran en el subdirectorio scripts/ de la distribución de Klone (el porte los instala en /usr/local/lib/klone/scripts).
Existen dos versiones, una de ellas en versión CGI idéntica a la página web de arriba, y la segunda en una versión no-CGI que usará el fichero completo de XF86Config, descodificará las especificaciones que se hayan introducido en xf86config o XF86Setup para el monitor (piénselo antes, ¿introdujo las especificaciones del monitor, o simplemente escogió las genéricas?), y configurará los ModeLines existentes de acuerdo con éstas.
[Índice de documentos] [Sección 10 - Gestión del sistema] [Sección 12 - Cuestiones sobre plataformas específicas]
www@openbsd.org