Subject: One more spanish translated chapter of "The NetBSD Guide"
To: None <netbsd-docs-es@NetBSD.org, uair9@yahoo.com, www@NetBSD.org>
From: None <uair@acelerate.com>
List: netbsd-docs-es
Date: 05/30/2005 22:15:07
--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi:
Here you go one more chapter of "The NetBSD Guide" translated into spanish. Sorry for the delay, I was a little busy migrating from
NetBSD/i386 to NetBSD/amd64 because I bought some new hardware and I couldn't make NetBSD to recognize my Sata Disk, but now is
all resolved and I'm back on translating the guide.
Changing the matter, I'm not sure if I have to translate the commented parts of the originals or not, but this time I did not. And
another issue is if I still have to send the translated copies to www@NetBSD.org or only to netbsd-docs-es@NetBSD.org or both or to
another address.
Saludos
Hugo
--MGYHOYXEY6WxJCY8
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: attachment; filename="chap-tuning.xml"
Content-Transfer-Encoding: 8bit
<!-- $NetBSD$ -->
<!-- Id: chap-tuning.xml,v 1.5 2005/03/13 03:12:13 reed Exp -->
<chapter id="chap-tuning">
<title>Afinando &os;</title>
<sect1 id="tuning-intro">
<title>Introducción</title>
<sect2 id="tuning-intro-overview">
<title>Descripción</title>
<para>
Esta sección cubre una variedad de asuntos respecto al afinamiento del
desempeño de su sistema. Procura atravesar el tema desde la
perspectiva del administrador al programador. El arte de afinar el
funcionamiento es muy viejo. Afinar algo significa hacer que funcione
más eficientemente, sea que uno se refiere al servidor técnico basado
en &os; o una escoba, la meta es mejorar algo, sea la manera en que se
hace algo, cómo trabaja o cómo se arma.
</para>
<sect3 id="tuning-intro-overview-whatis">
<title>¿Qué es afinar el desempeño?</title>
<para>
Una visión desde 3000 metros dicta muy aproximadamente que todo lo que
hacemos está orientado a alguna función, esto es pertinente al sistema
&os; también. Cuando el sistema arranca, comienza automáticamente a
realizar una variedad de tareas. Cuando un usuario inicia una sesión,
generalmente tiene una amplia variedad de tareas que tiene que realizar.
En el alcance de este documento, sin embargo, afinar el funcionamiento
significa estrictamente mejorar el desempeño del sistema &os;.
</para>
<para>
El pensamiento más común que acecha la mente de las personas cuando se
habla de <quote>afinar</quote> es alguna clase de aumento de la velocidad
o reducción del tamaño del núcleo - mientras que ésas son maneras de
mejorar el funcionamiento, no son las únicas medidas que un administrador
puede tener que tomar para lograr un aumento en la eficacia del sistema.
Para nuestros propósitos, afinar significa esto: <emphasis>Hacer que el
sistema &os; funcione en un estado óptimo.</emphasis>
</para>
<para>
Lo cuál podría significar una variedad de cosas, no necesariamente mejoras
en la velocidad. Un buen ejemplo de esto son los parámetros de formato del
sistema de archivos, en un sistema que tenga muchos archivos pequeños
(algo así como un almacén de fuentes) un administrador puede necesitar
aumentar el número de nodos haciendo su tamaño más pequeño (digamos 1024k)
y después aumentar la cantidad de nodos. En este caso el número de nodos
fue aumentado, evitando al administrador de recibir ésos molestos mensajes
que se refieren a la falta de nodos, que en última instancia hace al sistema
más eficiente.
</para>
<para>
El afinamiento gira normalmente alrededor de encontrar y de eliminar
embotellamientos. La mayor parte del tiempo, tales embotellamientos son
falsos, por ejemplo, un lanzamiento de Mozilla que no maneje los Java
applets demasiado bien puede hacer que Mozilla haga tambalear al CPU,
especialmente con applets mal hechos. Las ocasiones cuando los procesos
parecen girar sin rumbo y se comen al CPU se resuelven casi siempre con
un comando kill. Hay casos, sin embargo, en los que la resolución de los
embotellamientos dura mucho, por ejemplo, digamos que un servidor
sincronizado sólo crece y crece; lentamente, el funcionamiento comienza a
decrecer y el administrador puede tener que llevar alguna clase de acción
para acelerar las cosas, sin embargo, la situación es relativa en relación
con una emergencia con un CPU repentinamente clavado.
</para>
</sect3>
<sect3 id="tuning-intro-overview-when">
<title>¿Cuándo se debe afinar?</title>
<para>
Muchos de los usuarios de &os; raramente tienen que afinar un sistema. El
núcleo GENÉRICO puede funcionar muy bien y la disposición/configuración
del sistema también es muy buena. De la misma manera, como un pragma, es
siempre bueno saber afinar un sistema. La mayoría de las veces, afinar
viene como resultado de un repentino embotellamiento (que puede ocurrir
aleatoriamente) o una pérdida gradual del desempeño. En éste sentido, le
sucede a cada uno hasta cierto punto, un proceso que se esté comiendo al
CPU es un embotellamiento tanto como un aumento gradual en la paginación.
Así pues, la pregunta no debe ser cuándo afinar sino, más adecuadamente,
cuándo aprender a afinar.
</para>
<para>
Otra posibilidad de ajuste es que si puede afinar de una manera preventiva
(y piense que lo va a necesitar) entonces hágalo. Un ejemplo de esto es un
sistema que necesitó reiniciarse rápidamente. En vez de esperar, hice todo
lo que pude para ajustar el núcleo y cerciorarme de que allí no funcionaba
nada que no era absolutamente necesario, incluso quité los controladores
que tenían dispositivos pero nunca eran utilizados (lp). El resultado
reducía el tiempo de reinicio por casi dos tercios. A largo plazo, fue
una acción elegante afinarlo antes de que se convirtiera en un problema.
</para>
</sect3>
<sect3 id="tuning-intro-overview-notcovered">
<title>Lo que éste documento no cubre</title>
<para>
Antes de que me interne en la introducción, pienso que es importante
observar lo que éste documento no cubrirá. Esta guía pertenece solamente
a &os;. Es decir no cubrirá afinar la configuración de un servidor de
internet para hacer que funcione mejor; sin embargo, puede que mencione
cómo afinar &os; para funcionar mejor como servidor de internet. La lógica
detrás de esto es simple: servidores de internet, software de base de
datos, etc. son de terceros. Podría estancarme fácilmente en los detalles
que no se aplican al sistema &os;. De todos modos, casi todo el software
de terceros tiene documentación sobre sus propios ajustes.
</para>
</sect3>
<sect3 id="tuning-intro-overview-layout">
<title>Cómo están dispuestos los ejemplos</title>
<para>
Puesto que hay documentación amplia en las páginas del manual (man), sólo las opciones
y argumentos usados en los ejemplos se discuten. En algunos casos, el
material se trunca por razones de brevedad y no se discute a fondo porque,
simplemente, es demasiado. Por ejemplo, cada entrada del controlador de
dispositivos en el núcleo no será discutida, sin embargo, un ejemplo para
determinar si un sistema necesita alguna si. Nada en esta guía es
concreto, el afinado y el funcionamiento son muy subjetivos, en su lugar,
ésta es una guía para que el lector aprenda lo que se puede hacer con
algunas de las herramientas disponibles.
</para>
</sect3>
</sect2>
</sect1>
<sect1 id="tuning-considerations">
<title>Consideraciones de afinación</title>
<para>
Afinar un sistema no es demasiado difícil cuando uno hace un afinado
activo. Este documento se refiere a un afinamiento preventivo. Mientras
que afinar en el tiempo libre que uno tiene es considerablemente más fácil
contra, digamos, un servidor que se empantana casi totalmente y deja un
0.1% del tiempo disponible, siguen existiendo algunas cosas que deben ser
revisadas sobre el afinamiento antes que realmente hacerlas, incluso,
antes de que un sistema esté instalado.
</para>
<sect2 id="tuning-considerations-general">
<title>Configuración general del sistema</title>
<para>
Por supuesto que cómo el sistema está acondicionado marca una gran
diferencia. Los ítemes pequeños a veces pueden ser pasados por alto, lo
que puede acarrear un problema de funcionamiento a largo plazo.
</para>
<sect3 id="tuning-considerations-general-fs">
<title>Discos y sistemas de archivos</title>
<para>
Cómo el sistema de archivos se presenta en relación a los controladores de
disco es muy importante. En sistemas de hardware RAID, no es un asunto tan
preponderante, pero, muchos de los usuarios de &os; lo usan
específicamente en hardware viejo donde la opción del hardware RAID no
está disponible. Es una buena idea que <filename>/</filename> se encuentre
cerca al primer dispositivo de disco, pero si existen varios dispositivos
que puedan ser el primero ¿será el más apropiado el que elijamos para
<filename>/</filename>?. De manera relacionada, ¿será lo mejor separar
<filename>/usr</filename> en una partición diferente? ¿usará el sistema,
por ejemplo, <filename>/usr/pkgsrc</filename> en gran manera?, podría ser
una buena idea utilizar un dispositivo veloz en
<filename>/usr/pkgsrc</filename>, o podría no serlo. Como todas las cosas
que se refieren al afinamiento, está también es subjetiva.
</para>
</sect3>
<sect3 id="tuning-considerations-general-swap">
<title>Configuración de la memoria de intercambio</title>
<para>
Hay tres corrientes de pensamiento relacionadas con el tamaño de la
memoria de intercambio y cerca de cincuenta acerca de cómo usar archivos
partidos de la memoria de intercambio con prioridad y cómo debe ser hecho.
En la <quote>arena</quote> del tamaño de la memoria de intercambio, las
corrientes comerciales (por lo menos las más comerciales) tienen
generalmente sus propias fórmulas por cada SO. Como ejemplo, en una
versión particular de HP-UX con una versión particular de Oracle la
fórmula era:
</para>
<screen>
2.5 GB * Número_del_procesador
</screen>
<para>
Bien, realmente todo depende de qué tipo de uso está teniendo la base de
datos y cuan grande es, por ejemplo si es tan grande que debe ser
distribuida, la fórmula no sirve mucho.
</para>
<para>
La siguiente línea de pensamiento sobre el tamaño de la memoria de
intercambio es algo extraña pero tiene cierto sentido, dice, si es
posible, consiga una cantidad de referencia de la memoria utilizada por el
sistema. Es algo como esto:
</para>
<orderedlist>
<listitem>
<para>
Arranque una máquina y estime el total de memoria necesaria corriendo
todo lo que pueda ser usado al mismo tiempo: base de datos, servidores
de internet, .... lo que sea. Sume el total.
</para>
</listitem>
<listitem>
<para>
Añada unos cuantos MB por precaución.
</para>
</listitem>
<listitem>
<para>
Reste el total de memoria RAM física a este total.
</para>
</listitem>
</orderedlist>
<para>
Si la cantidad que le queda es 3 veces el tamaño de la memoria RAM física,
considere conseguir más memoria RAM. El problema, por supuesto, está en
calcular qué es necesario y cuánto espacio tomará. Hay también otro
defecto en este método, algunos programas no se comportan bien. Un ejemplo
que se deslumbra del software de mal comportamiento son los navegadores de
red. En ciertas versiones de Netscape, cuando algo salía mal tenía la
tendencia de desestabilizarse y comerse la memoria de intercambio. Así
pues, más espacio disponible, más tiempo en matarlo.
</para>
<para>
Por último está el probado y comprobado método de MEMORIA_RAM * 2. En
máquinas modernas e incluso en las más viejas (con propósito limitado por
supuesto) éste parece el mejor método.
</para>
<para>
Después de todo, es difícil decir cuando el intercambio comenzará.
Inclusive en pequeñas máquinas con 16MB de RAM (o menos), &os; ha
trabajado siempre bien para la mayoría de la gente hasta que el software
de mal comportamiento funciona.
</para>
</sect3>
</sect2>
<sect2 id="tuning-considerations-services">
<title>Servicios del sistema</title>
<para>
En servidores, los servicios del sistema tienen un impacto más grande.
Conseguir lo mejor de su funcionamiento requiere casi siempre cierta clase
de cambio del nivel de red o un aumento fundamental de la velocidad en el
sistema subyacente (que por supuesto es de lo se trata que esto). Hay
casos cuando algunas soluciones simples pueden mejorar los servicios. Un
ejemplo, un servidor ftp está perdiendo velocidad y un nuevo lanzamiento
del servidor ftp que se envía con el sistema es realizado y, sucede que,
éste nuevo lanzamiento corre más rápido. Actualizando el software del ftp
un alza en el funcionamiento es lograda.
</para>
<para>
Otro buen ejemplo donde se refieren los servicios es la vieja pregunta:
<quote>¿utilizar inetd o no utilizar inetd?</quote>. Un gran ejemplo de
servicios es pop3. Las conexiones pop3 pueden estorbar a inetd. Mientras
que el servicio pop3 comienza a degradarse lentamente por sí mismo, otros
servicios que se multiplexan a través de inetd también se degradarán
(en algunos casos más que pop3). Poner a funcionar a pop3
independientemente y fuera de inetd puede ayudar.
</para>
</sect2>
<sect2 id="tuning-considerations-kernel">
<title>El núcleo de &os;</title>
<para>
Obviamente, el núcleo de &os; protagoniza un papel dominante en cómo un
sistema se desempeña, mientras que la reconstrucción y afinamiento del
núcleo se cubre más adelante en el texto, vale la pena discutir el tema en
el contexto actual desde un nivel alto.
</para>
<para>
Afinar el núcleo de &os; implica tres área principales:
</para>
<orderedlist>
<listitem>
<para>
quitar controladores innecesarios
</para>
</listitem>
<listitem>
<para>
configurar opciones
</para>
</listitem>
<listitem>
<para>
disposición del sistema
</para>
</listitem>
</orderedlist>
<sect3 id="tuning-considerations-kernel-drivers">
<title>Quitando controladores innecesarios</title>
<para>
El retirar los controladores del núcleo que no son necesarios alcanza
varios resultados; primero, el sistema arranca más rápidamente puesto que
el núcleo es más pequeño, en segundo lugar, otra vez, puesto que el núcleo
es más pequeño, más memoria está libre para los usuarios y los procesos y
tercero, el núcleo tiende a responder más aprisa.
</para>
</sect3>
<sect3 id="tuning-considerations-kernel-options">
<title>Opciones de configuración</title>
<para>
Las opciones de configuración tales como habilitar/deshabilitar ciertos
subsistemas, hardware específico o sistemas de archivos pueden también
mejorar bastante el funcionamiento, de la misma manera que lo hace quitar
controladores no requeridos. Un ejemplo muy simple de esto es un servidor
ftp que únicamente contiene archivos ftp y nada más. En este servidor en
particular no hay necesidad de tener todo, solamente soporte nativo del
sistema de archivos y quizás algunas opciones para ayudar a acelerar las
cosas. ¿Para que necesitaría soporte de NTFS por ejemplo? Además, si
después lo necesitara, el soporte para NTFS se puede agregar luego. En un
caso opuesto, una estación de trabajo puede necesitar soportar muchos y
diversos tipos de sistemas de archivos para poder compartir y tener
acceso a archivos.
</para>
</sect3>
<sect3 id="tuning-considerations-kernel-settings">
<title>Disposición del sistema</title>
<para>
Los ajustes generales del sistema son controlados por el núcleo, algunos
ejemplos son los ajustes de sistema de archivos, ajustes de la red y los
ajustes del mismo núcleo tales como el número máximo de procesos. Casi
todos los ajustes del sistema por lo menos se pueden mirar o modificar vía
la facilidad del sysctl. Los ejemplos que usan la facilidad del sysctl se
dan más adelante.
</para>
</sect3>
</sect2>
</sect1>
<sect1 id="tuning-vtools">
<title>Herramientas de supervisión visual</title>
<para>
&os; viene ya con una variedad de herramientas de supervisión del
funcionamiento del sistema. La mayoría de estas herramientas son comunes
en todos los sistemas UNIX. En esta sección se da algunos ejemplos con la
debida interpretación de su salida.
</para>
<sect2 id="tuning-vtools-top">
<title>El supervisor de procesos top</title>
<para>
El monitor top hace exactamente lo qué dice: exhibe los procesos del CPU
en el sistema. Para ejecutar el monitor, escriba simplemente
<quote>top</quote> en el intérprete de comandos. Sin ningún argumento, debe
verse así:
</para>
<screen>
load averages: 0.09, 0.12, 0.08 20:23:41
21 processes: 20 sleeping, 1 on processor
CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Memory: 15M Act, 1104K Inact, 208K Wired, 22M Free, 129M Swap free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
13663 root 2 0 1552K 1836K sleep 0:08 0.00% 0.00% httpd
127 root 10 0 129M 4464K sleep 0:01 0.00% 0.00% mount_mfs
22591 root 2 0 388K 1156K sleep 0:01 0.00% 0.00% sshd
108 root 2 0 132K 472K sleep 0:01 0.00% 0.00% syslogd
22597 jrf 28 0 156K 616K onproc 0:00 0.00% 0.00% top
22592 jrf 18 0 828K 1128K sleep 0:00 0.00% 0.00% tcsh
203 root 10 0 220K 424K sleep 0:00 0.00% 0.00% cron
1 root 10 0 312K 192K sleep 0:00 0.00% 0.00% init
205 root 3 0 48K 432K sleep 0:00 0.00% 0.00% getty
206 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
208 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
207 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
13667 nobody 2 0 1660K 1508K sleep 0:00 0.00% 0.00% httpd
9926 root 2 0 336K 588K sleep 0:00 0.00% 0.00% sshd
200 root 2 0 76K 456K sleep 0:00 0.00% 0.00% inetd
182 root 2 0 92K 436K sleep 0:00 0.00% 0.00% portsentry
180 root 2 0 92K 436K sleep 0:00 0.00% 0.00% portsentry
13666 nobody -4 0 1600K 1260K sleep 0:00 0.00% 0.00% httpd
</screen>
<para>
La utilidad top es excelente para encontrar procesos del CPU, procesos en
fuga o grupos de procesos que pueden estar causando problemas. La salida
mostrada arriba indica que este sistema en particular está en buen estado.
Ahora, la siguiente exhibición muestra algunos resultados muy distintos:
</para>
<screen>
load averages: 0.34, 0.16, 0.13 21:13:47
25 processes: 24 sleeping, 1 on processor
CPU states: 0.5% user, 0.0% nice, 9.0% system, 1.0% interrupt, 89.6% idle
Memory: 20M Act, 1712K Inact, 240K Wired, 30M Free, 129M Swap free
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
5304 jrf -5 0 56K 336K sleep 0:04 66.07% 19.53% bonnie
5294 root 2 0 412K 1176K sleep 0:02 1.01% 0.93% sshd
108 root 2 0 132K 472K sleep 1:23 0.00% 0.00% syslogd
187 root 2 0 1552K 1824K sleep 0:07 0.00% 0.00% httpd
5288 root 2 0 412K 1176K sleep 0:02 0.00% 0.00% sshd
5302 jrf 28 0 160K 620K onproc 0:00 0.00% 0.00% top
5295 jrf 18 0 828K 1116K sleep 0:00 0.00% 0.00% tcsh
5289 jrf 18 0 828K 1112K sleep 0:00 0.00% 0.00% tcsh
127 root 10 0 129M 8388K sleep 0:00 0.00% 0.00% mount_mfs
204 root 10 0 220K 424K sleep 0:00 0.00% 0.00% cron
1 root 10 0 312K 192K sleep 0:00 0.00% 0.00% init
208 root 3 0 48K 432K sleep 0:00 0.00% 0.00% getty
210 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
209 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
211 root 3 0 48K 424K sleep 0:00 0.00% 0.00% getty
217 nobody 2 0 1616K 1272K sleep 0:00 0.00% 0.00% httpd
184 root 2 0 336K 580K sleep 0:00 0.00% 0.00% sshd
201 root 2 0 76K 456K sleep 0:00 0.00% 0.00% inetd
</screen>
<para>
En principio, debe ser algo obvio que proceso está ocupando al sistema,
sin embargo, lo que es interesante en este caso es porqué. El programa
bonnie es una herramienta de creación de puntos de referencia en el disco
que puede escribir archivos grandes en una variedad de tamaños y maneras.
Lo que la salida anterior indica es solamente que el programa bonnie es un
proceso del CPU, pero no porqué.
</para>
<sect3 id="tuning-vtools-top-other">
<title>Otras cosas acerca de top</title>
<para>
Una examinación cuidadosa de la página del manual &man.top.1; demuestra
que hay mucho más que se puede hacer con top, por ejemplo, los procesos
pueden tener su prioridad cambiante y matada. Además, ciertos filtros se
pueden fijar para mirar procesos.
</para>
</sect3>
</sect2>
<sect2 id="tuning-vtools-systat">
<title>La utilidad sysstat</title>
<para>
Como la página man &man.sysstat.1; indica, la utilidad del sysstat muestra
una variedad de estadísticas del sistema usando la librería de curses.
Durante su funcionamiento, la pantalla es exhibida en dos porciones, la
ventana superior muestra el promedio actual de la carga mientras que la
pantalla más baja depende de los comandos del usuario. La excepción a la
separación de la pantalla es cuando la exhibición de vmstat toma la
pantalla entera. Lo que sigue a continuación es cómo se ve sysstat en un
sistema bastante desocupado sin argumentos dados cuando fue invocada:
</para>
<screen>
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |
/0 /10 /20 /30 /40 /50 /60 /70 /80 /90 /100
<idle> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</screen>
<para>
Básicamente muchos tiempo muerto por allí, así que ahora echémos una
mirada proporcionando algunos argumentos, en éste caso, <command>sysstat
inet.tcp</command> que se ve algo así:
</para>
<screen>
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |
0 connections initiated 19 total TCP packets sent
0 connections accepted 11 data
0 connections established 0 data (retransmit)
8 ack-only
0 connections dropped 0 window probes
0 in embryonic state 0 window updates
0 on retransmit timeout 0 urgent data only
0 by keepalive 0 control
0 by persist
29 total TCP packets received
11 potential rtt updates 17 in sequence
11 successful rtt updates 0 completely duplicate
9 delayed acks sent 0 with some duplicate data
0 retransmit timeouts 4 out of order
0 persist timeouts 0 duplicate acks
0 keepalive probes 11 acks
0 keepalive timeouts 0 window probes
0 window updates
</screen>
<para>
Eso si que es informativo. La primera encuesta es acumulativa, así que es
posible ver mucha información en la salida cuando se invoca sysstat.
Ahora, mientras eso puede ser interesante, que tal echar una mirada en el
caché del almacenador intermediario con
<command>systat bufcache</command>:
</para>
<screen>
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average
There are 1642 buffers using 6568 kBytes of memory.
File System Bufs used % kB in use % Bufsize kB % Util %
/ 877 53 6171 93 6516 99 94
/var/tmp 5 0 17 0 28 0 60
Total: 882 53 6188 94 6544 99
</screen>
<para>
Nuevamente un sistema aburrido, pero muy buena información para tener
disponible. Mientras que todo esto es agradable de mirar, es hora de poner
una carga falsa en el sistema para ver cómo sysstat se puede utilizar como
herramienta de supervisión de funcionamiento. Como con top, bonnie++ será
utilizado para poner una alta carga en los subsistemas de I/O y un poco en
el CPU. El bufcache será mirado otra vez para apreciar si allí hay alguna
diferencia notable:
</para>
<screen>
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |||
There are 1642 buffers using 6568 kBytes of memory.
File System Bufs used % kB in use % Bufsize kB % Util %
/ 811 49 6422 97 6444 98 99
Total: 811 49 6422 97 6444 98
</screen>
<para>
Primero que nada, note que el promedio de la carga subió, esto es de
esperar, por supuesto, después, mientras que la mayoría de los números
están cerca, note que la utilización está en el 99%. A través del tiempo
que bonnie++ funcionaba el porcentaje de la utilización se mantuvo en 99,
ésto por supuesto tiene sentido, sin embargo, en una situación con
problemas de ejecución verdadera, podría ser indicativo de un proceso que
hace un intercambio I/O pesado en un archivo o sistema de archivos en
particular.
</para>
</sect2>
</sect1>
<sect1 id="tuning-mtools">
<title>Herramientas de supervisión</title>
<para>
Además de los supervisores y herramientas de pantalla, el sistema &os;
también incluye un sistema de herramientas orientado al intérprete de
comandos. Muchas de las herramientas que vienen con &os; se pueden
encontrar en otros sistemas UNIX y cómo-UNIX.
</para>
<sect2 id="tuning-mtools-fstat">
<title>fstat</title>
<para>
La utilidad &man.fstat.1; reporta el estado de archivos abiertos en el
sistema, mientras que no es lo que consideran muchos administradores como
un monitor de funcionamiento, puede ayudar a descubrir si un usuario o un
proceso en particular está utilizando una cantidad excesiva de archivos,
generando archivos grandes e información similar.
</para>
<para>
A continuación hay un ejemplo de la salida de fstat:
</para>
<screen>
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W
jrf tcsh 21607 wd / 29772 drwxr-xr-x 512 r
jrf tcsh 21607 3* unix stream c057acc0<-> c0553280
jrf tcsh 21607 4* unix stream c0553280 <-> c057acc0
root sshd 21597 wd / 2 drwxr-xr-x 512 r
root sshd 21597 0 / 11921 crw-rw-rw- null rw
nobody httpd 5032 wd / 2 drwxr-xr-x 512 r
nobody httpd 5032 0 / 11921 crw-rw-rw- null r
nobody httpd 5032 1 / 11921 crw-rw-rw- null w
nobody httpd 5032 2 / 15890 -rw-r--r-- 353533 rw
...
</screen>
<para>
Los campos son explicativos; mientras que esta herramienta no es
orientada al desempeño como otras, puede ser muy útil en lo que refiere
al uso de ficheros.
</para>
</sect2>
<sect2 id="tuning-mtools-iostat">
<title>iostat</title>
<para>
El comando &man.iostat.8; hace exactamente lo que usted piensa, divulga el
estado de los subsistemas de I/O en el sistema. Cuando se emplea iostat,
el usuario típicamente lo corre con cierto número de cuentas y un
intervalo entre ellas como:
</para>
<screen>
&uprompt <userinput>iostat 5 5</userinput>
tty wd0 cd0 fd0 md0 cpu
tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id
0 1 5.13 1 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100
0 54 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100
0 18 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100
0 18 8.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100
0 28 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100
</screen>
<para>
La salida anterior es de un servidor ftp muy apacible. Los campos
representan los varios dispositivos de I/O, tty (que, irónicamente es el
más activo porque iostat está funcionando), wd0 que es el disco IDE
primario, cd0, el dispositivo cdrom, fd0, el disquete y el sistema de
archivos de la memoria.
</para>
<para>
Ahora, veamos si podemos aporrear el sistema con algo de uso pesado.
Primero, una transacción ftp grande que consiste en un archivo comprimido
del código fuente de netbsd-current junto con el programa bonnie++ que
funciona al mismo tiempo.
</para>
<screen>
&uprompt; <userinput>iostat 5 5</userinput>
tty wd0 cd0 fd0 md0 cpu
tin tout KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s KB/t t/s MB/s us ni sy in id
0 1 5.68 1 0.00 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0 100
0 54 61.03 150 8.92 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 1 0 18 4 78
0 26 63.14 157 9.71 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 1 0 20 4 75
0 20 43.58 26 1.12 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 9 2 88
0 28 19.49 82 1.55 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 1 0 7 3 89
</screen>
<para>
Como se puede esperar, note que wd0 está muy activo; lo qué es
interesante acerca de esta salida es cómo la I/O del procesador parece
elevarse en proporción con wd0. Esto tiene perfecto sentido , sin embargo,
vale la pena observar que solamente porque este servidor ftp esté siendo
apenas utilizado no significa que eso no pueda ser notado. Si, por
ejemplo, el subsistema I/O del CPU estuviera ya bajo carga moderada y el
subsistema del disco estuviera bajo la misma carga que está ahora, podría
parecer que el CPU está atorado cuando de hecho habría sido el disco. En
tal caso, podemos observar que "una" herramienta raramente basta para
analizar totalmente un problema. Un vistazo rápido en los procesos
probablemente nos diría (después de mirar la salida de iostat) qué
procesos causaban problemas.
</para>
</sect2>
<sect2 id="tuning-mtools-ps">
<title>ps</title>
<para>
Al usar el comando &man.ps.1; o estatus de procesos, una gran cantidad de
información sobre el sistema puede ser descubierta. La mayor parte del
tiempo, el comando ps se utiliza para aislar a un proceso particular
por nombre, grupo, propietario, etc. Invocado sin opciones o argumentos,
ps imprime simplemente la información sobre el usuario que la ejecuta.
</para>
<screen>
&uprompt; <userinput>ps</userinput>
PID TT STAT TIME COMMAND
21560 p0 Is 0:00.04 -tcsh
21564 p0 I+ 0:00.37 ssh jrf.odpn.net
21598 p1 Ss 0:00.12 -tcsh
21673 p1 R+ 0:00.00 ps
21638 p2 Is+ 0:00.06 -tcsh
</screen>
<para>
No muy emocionante. Los campos son explicativos, a excepción de STAT que
es el estado en el que un proceso se encuentra. Las banderas están todas
documentadas en la página man, sin embargo, en el ejemplo anterior, I
significa ocioso, S durmiendo, R corriendo, + significa que el proceso
está en un primero plano, y s significa que es un líder de sesión. Todo
esto tiene perfecto sentido al mirar a las banderas, por ejemplo, PID
21560 es un intérprete de comandos, está ocioso y (como esperaría) el
intérprete es el líder de los procesos.
</para>
<para>
En la mayoría de los casos, se busca algo muy específico en el listado de
procesos. Como ejemplo, mirar todos los procesos se especifica con -a, ver
todos los procesos más ésos sin terminales de control es -ax y conseguir
un listado mucho más prolijo (todo más la información sobre el impacto
que los procesos están teniendo) -aux:
</para>
<screen>
&rprompt; <userinput>ps aux</userinput>
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 0 0.0 9.6 0 6260 ?? DLs 16Jul02 0:01.00 (swapper)
root 23362 0.0 0.8 144 488 ?? S 12:38PM 0:00.01 ftpd -l
root 23328 0.0 0.4 428 280 p1 S 12:34PM 0:00.04 -csh
jrf 23312 0.0 1.8 828 1132 p1 Is 12:32PM 0:00.06 -tcsh
root 23311 0.0 1.8 388 1156 ?? S 12:32PM 0:01.60 sshd: jrf@ttyp1
jrf 21951 0.0 1.7 244 1124 p0 S+ 4:22PM 0:02.90 ssh jrf.odpn.net
jrf 21947 0.0 1.7 828 1128 p0 Is 4:21PM 0:00.04 -tcsh
root 21946 0.0 1.8 388 1156 ?? S 4:21PM 0:04.94 sshd: jrf@ttyp0
nobody 5032 0.0 2.0 1616 1300 ?? I 19Jul02 0:00.02 /usr/pkg/sbin/httpd
...
</screen>
<para>
Una vez más, la mayoría de los campos son explicativos, a excepción de VSZ
y RSS que pueden ser un poco confusos. RSS es el tamaño verdadero de un
proceso en 1024 unidades byte, mientras que VSZ es el tamaño virtual.
Todo esto es genial, pero nuevamente, ¿cómo puede ayudar ps? Bien, eche
una ojeada a esta versión modificada de la misma salida:
</para>
<screen>
&rprompt; <userinput>ps aux</userinput>
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
root 0 0.0 9.6 0 6260 ?? DLs 16Jul02 0:01.00 (swapper)
root 23362 0.0 0.8 144 488 ?? S 12:38PM 0:00.01 ftpd -l
root 23328 0.0 0.4 428 280 p1 S 12:34PM 0:00.04 -csh
jrf 23312 0.0 1.8 828 1132 p1 Is 12:32PM 0:00.06 -tcsh
root 23311 0.0 1.8 388 1156 ?? S 12:32PM 0:01.60 sshd: jrf@ttyp1
jrf 21951 0.0 1.7 244 1124 p0 S+ 4:22PM 0:02.90 ssh jrf.odpn.net
jrf 21947 0.0 1.7 828 1128 p0 Is 4:21PM 0:00.04 -tcsh
root 21946 0.0 1.8 388 1156 ?? S 4:21PM 0:04.94 sshd: jrf@ttyp0
nobody 5032 9.0 2.0 1616 1300 ?? I 19Jul02 0:00.02 /usr/pkg/sbin/httpd
...
</screen>
<para>
Dado eso en este servidor, nuestra línea de fondo indica un sistema
relativamente tranquilo, el PID 5032 usa una cantidad inusualmente
grande de CPU. Esto puede también causar a veces números grandes en el
TIEMPO (TIME). El comando ps puede ser usado junto a grep para obtener
PIDs, nombre de usuario y el nombre de proceso y por lo tanto ayuda para
seguir de cerca a los procesos que pueden experimentar problemas.
</para>
</sect2>
<sect2 id="tuning-mtools-vmstat">
<title>vmstat</title>
<para>
Al usar &man.vmstat.1;, la información que pertenece a la memoria virtual
puede ser supervisada y medida. No muy diferente a iostat, vmstat se
puede invocar con una cuenta y un intervalo. Lo que sigue es una muestra
usando 5 5 como en el ejemplo de iostat:
</para>
<screen>
&rprompt; <userinput>vmstat 5 5</userinput>
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr w0 c0 f0 m0 in sy cs us sy id
0 7 0 17716 33160 2 0 0 0 0 0 1 0 0 0 105 15 4 0 0 100
0 7 0 17724 33156 2 0 0 0 0 0 1 0 0 0 109 6 3 0 0 100
0 7 0 17724 33156 1 0 0 0 0 0 1 0 0 0 105 6 3 0 0 100
0 7 0 17724 33156 1 0 0 0 0 0 0 0 0 0 107 6 3 0 0 100
0 7 0 17724 33156 1 0 0 0 0 0 0 0 0 0 105 6 3 0 0 100
</screen>
<para>
Con todo, otra vez, relativamente tranquilo, para la posteridad,
exactamente la misma carga que fue puesta en este servidor en el ejemplo
del iostat será utilizada en este caso. La carga es una gran transferencia
de archivos y el programa de prueba bonnie.
</para>
<screen>
&rprompt; <userinput>vmstat 5 5</userinput>
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr w0 c0 f0 m0 in sy cs us sy id
1 8 0 18880 31968 2 0 0 0 0 0 1 0 0 0 105 15 4 0 0 100
0 8 0 18888 31964 2 0 0 0 0 0 130 0 0 0 1804 5539 1094 31 22 47
1 7 0 18888 31964 1 0 0 0 0 0 130 0 0 0 1802 5500 1060 36 16 49
1 8 0 18888 31964 1 0 0 0 0 0 160 0 0 0 1849 5905 1107 21 22 57
1 7 0 18888 31964 1 0 0 0 0 0 175 0 0 0 1893 6167 1082 1 25 75
</screen>
<para>
Apenas un poco diferente. Nótese, puesto que la mayoría del trabajo era
basado en I/O , la memoria real usada no era mucha. Aún que este sistema
utiliza mfs para <filename>/tmp</filename>, ciertamente puede conseguir
ser sobrecargado. Eche una mirada a esto:
</para>
<screen>
&rprompt; <userinput>vmstat 5 5</userinput>
procs memory page disks faults cpu
r b w avm fre flt re pi po fr sr w0 c0 f0 m0 in sy cs us sy id
0 2 0 99188 500 2 0 0 0 0 0 1 0 0 0 105 16 4 0 0 100
0 2 0111596 436 592 0 587 624 586 1210 624 0 0 0 741 883 1088 0 11 89
0 3 0123976 784 666 0 662 643 683 1326 702 0 0 0 828 993 1237 0 12 88
0 2 0134692 1236 581 0 571 563 595 1158 599 0 0 0 722 863 1066 0 9 90
2 0 0142860 912 433 0 406 403 405 808 429 0 0 0 552 602 768 0 7 93
</screen>
<para>
Algo escalofriante. Esto fue ocasionado al ejecutar bonnie en
<filename>/tmp</filename> en un sistema de archivos basado en memoria. Si
continuara así demasiado tiempo, es posible que el sistema empezara a
fallar. Note que aunque el subsistema VM esta bajo ataque, los procesadores
todavía no eran muy maltratados.
</para>
</sect2>
</sect1>
<sect1 id="tuning-ntools">
<title>Herramientas de trabajo en red</title>
<para>
Algunas veces un problema de funcionamiento no se debe a una máquina en
particular; es la red o una alguna clase de dispositivo de red, tal como
otro anfitrión, una puerta de enlace, etc. El efecto de otras máquinas que
proporcionan un servicio o una alguna clase de conectividad a un sistema
&os; y cómo actúan puede tener un impacto muy grande en el funcionamiento
del sistema &os; en sí, o la percepción del funcionamiento en los
usuarios. Un ejemplo realmente bueno de esto es cuando un servidor DNS que
un sistema &os; está utilizando repentinamente desaparece. Las operaciones
de búsqueda duran mucho y eventualmente fallan. Alguien en una sesión en
un sistema &os; que no es muy experimentado (suponiendo que no tiene
ninguna otra evidencia) culparía indudablemente al sistema &os;. Uno de
mis favoritos, <quote>el Internet se cayó</quote> generalmente significa
que el servicio DNS o una puerta de enlace ha caído fuera de línea. Sea
el caso que sea, el sistema &os; viene adecuadamente armado para ocuparse
en descubrir qué áreas de la red pueden ocasionar fallas, si la avería es
del sistema local o algún otro problema.
</para>
<sect2 id="tuning-ntools-ping">
<title>ping</title>
<para>
La clásica utilidad &man.ping.8; puede decirnos si hay conectividad llana,
puede también decirnos si la resolución del anfitrión (dependiendo de cómo
lo dicta <filename>nsswitch.conf</filename>) está trabajando. A
continuación sigue una salida típica de ping en una red local con una
cuenta de 3 especificada:
</para>
<screen>
&rprompt; <userinput>ping -c 3 marie</userinput>
PING marie (172.16.14.12): 56 data bytes
64 bytes from 172.16.14.12: icmp_seq=0 ttl=255 time=0.571 ms
64 bytes from 172.16.14.12: icmp_seq=1 ttl=255 time=0.361 ms
64 bytes from 172.16.14.12: icmp_seq=2 ttl=255 time=0.371 ms
----marie PING Statistics----
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.361/0.434/0.571/0.118 ms
</screen>
<para>
No solamente ping nos dice si un anfitrión está vivo, también nos dice
cuánto tiempo tomó y da algunos detalles agradables al final. Si un
anfitrión no puede ser resuelto, se puede especificar sólo la dirección
IP:
</para>
<screen>
&rprompt; <userinput>ping -c 1 172.16.20.5</userinput>
PING ash (172.16.20.5): 56 data bytes
64 bytes from 172.16.20.5: icmp_seq=0 ttl=64 time=0.452 ms
----ash PING Statistics----
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.452/0.452/0.452/0.000 ms
</screen>
<para>
Ahora, como en cualquier otra herramienta, los tiempos son muy subjetivos,
especialmente en lo que se refiere al establecimiento de una red. Por
ejemplo, mientras que los tiempos en los ejemplos son buenos, eché una
ojeada al ping en el anfitrión local:
</para>
<screen>
&rprompt; <userinput>ping -c 4 localhost</userinput>
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.091 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.129 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.120 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.122 ms
----localhost PING Statistics----
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.091/0.115/0.129/0.017 ms
</screen>
<para>
Mucho más pequeños porque la petición nunca salió de la máquina. Los pings
se pueden utilizar para recopilar la información sobre cuan bien una red
se está desempeñando. Es también bueno para el aislamiento de problemas,
por ejemplo, si hay tres (relativamente del mismo tamaño) sistemas &os; en
una red y uno de ellos simplemente tiene tiempos horribles de ping, lo más
probable es que algo anda mal en esa máquina en particular.
</para>
</sect2>
<sect2 id="tuning-ntools-traceroute">
<title>traceroute</title>
<para>
El comando &man.traceroute.8; es excelente para cerciorarse de que una
trayectoria está disponible o para detectar problemas en una trayectoria
en particular. Como ejemplo, aquí está un trazado entre el servidor ftp
del ejemplo y ftp.NetBSD.org:
</para>
<screen>
&rprompt; <userinput>traceroute ftp.NetBSD.org</userinput>
traceroute to ftp.NetBSD.org (204.152.184.75), 30 hops max, 40 byte packets
1 208.44.95.1 (208.44.95.1) 1.646 ms 1.492 ms 1.456 ms
2 63.144.65.170 (63.144.65.170) 7.318 ms 3.249 ms 3.854 ms
3 chcg01-edge18.il.inet.qwest.net (65.113.85.229) 35.982 ms 28.667 ms 21.971 ms
4 chcg01-core01.il.inet.qwest.net (205.171.20.1) 22.607 ms 26.242 ms 19.631 ms
5 snva01-core01.ca.inet.qwest.net (205.171.8.50) 78.586 ms 70.585 ms 84.779 ms
6 snva01-core03.ca.inet.qwest.net (205.171.14.122) 69.222 ms 85.739 ms 75.979 ms
7 paix01-brdr02.ca.inet.qwest.net (205.171.205.30) 83.882 ms 67.739 ms 69.937 ms
8 198.32.175.3 (198.32.175.3) 72.782 ms 67.687 ms 73.320 ms
9 so-1-0-0.orpa8.pf.isc.org (192.5.4.231) 78.007 ms 81.860 ms 77.069 ms
10 tun0.orrc5.pf.isc.org (192.5.4.165) 70.808 ms 75.151 ms 81.485 ms
11 ftp.NetBSD.org (204.152.184.75) 69.700 ms 69.528 ms 77.788 ms
</screen>
<para>
Después de todo, no está mal. El trazado fue desde el anfitrión a la
puerta de enlace local, luego hacia la red del proveedor y
finalmente hacia el Internet buscando el destino final. Cómo interpretar
traceroute, es subjetivo también, pero los períodos anormalmente altos en
porciones de una trayectoria pueden indicar un embotellamiento en alguna
parte del equipo de la red. No muy diferente a ping, si el anfitrión en sí
es sospechoso, ejecute traceroute desde otro anfitrión al mismo destino.
Ahora, para el peor de los casos:
</para>
<screen>
&rprompt; <userinput>traceroute www.microsoft.com</userinput>
traceroute: Warning: www.microsoft.com has multiple addresses; using 207.46.230.220
traceroute to www.microsoft.akadns.net (207.46.230.220), 30 hops max, 40 byte packets
1 208.44.95.1 (208.44.95.1) 2.517 ms 4.922 ms 5.987 ms
2 63.144.65.170 (63.144.65.170) 10.981 ms 3.374 ms 3.249 ms
3 chcg01-edge18.il.inet.qwest.net (65.113.85.229) 37.810 ms 37.505 ms 20.795 ms
4 chcg01-core03.il.inet.qwest.net (205.171.20.21) 36.987 ms 32.320 ms 22.430 ms
5 chcg01-brdr03.il.inet.qwest.net (205.171.20.142) 33.155 ms 32.859 ms 33.462 ms
6 205.171.1.162 (205.171.1.162) 39.265 ms 20.482 ms 26.084 ms
7 sl-bb24-chi-13-0.sprintlink.net (144.232.26.85) 26.681 ms 24.000 ms 28.975 ms
8 sl-bb21-sea-10-0.sprintlink.net (144.232.20.30) 65.329 ms 69.694 ms 76.704 ms
9 sl-bb21-tac-9-1.sprintlink.net (144.232.9.221) 65.659 ms 66.797 ms 74.408 ms
10 144.232.187.194 (144.232.187.194) 104.657 ms 89.958 ms 91.754 ms
11 207.46.154.1 (207.46.154.1) 89.197 ms 84.527 ms 81.629 ms
12 207.46.155.10 (207.46.155.10) 78.090 ms 91.550 ms 89.480 ms
13 * * *
.......
</screen>
<para>
En este caso, el servidor de Microsoft no puede ser encontrado ya sea
debido a direcciones múltiples o en alguna parte a lo largo de la línea un
sistema o servidor no puede contestar a la petición de la información. En
éste punto, uno puede pensar en intentar un ping, en el caso de Microsoft,
un ping no obtiene respuesta, ya que probablemente en alguna parte de su
red el ICMP no está habilitado.
</para>
</sect2>
<sect2 id="tuning-ntools-netstat">
<title>netstat</title>
<para>
Otro problema que puede surgir en un sistema &os; está relacionado con las
cuestiones de la tabla de encaminamiento. Estas cuestiones no son siempre
culpa del sistema. Los comandos &man.route.8; y &man.netstat.1; pueden
mostrar la información sobre las rutas y las conexiones de red
(respectivamente).
</para>
<para>
El comando route se puede utilizar para mirar y modificar las tablas de
encaminamiento mientras que netstat puede exhibir información sobre
conexiones y rutas de red. Primero, aquí está una salida de route show:
</para>
<screen>
&rprompt; <userinput>route show</userinput>
Routing tables
Internet:
Destination Gateway Flags
default 208.44.95.1 UG
loopback 127.0.0.1 UG
localhost 127.0.0.1 UH
172.15.13.0 172.16.14.37 UG
172.16.0.0 link#2 U
172.16.14.8 0:80:d3:cc:2c:0 UH
172.16.14.10 link#2 UH
marie 0:10:83:f9:6f:2c UH
172.16.14.37 0:5:32:8f:d2:35 UH
172.16.16.15 link#2 UH
loghost 8:0:20:a7:f0:75 UH
artemus 8:0:20:a8:d:7e UH
ash 0:b0:d0:de:49:df UH
208.44.95.0 link#1 U
208.44.95.1 0:4:27:3:94:20 UH
208.44.95.2 0:5:32:8f:d2:34 UH
208.44.95.25 0:c0:4f:10:79:92 UH
Internet6:
Destination Gateway Flags
default localhost UG
default localhost UG
localhost localhost UH
::127.0.0.0 localhost UG
::224.0.0.0 localhost UG
::255.0.0.0 localhost UG
::ffff:0.0.0.0 localhost UG
2002:: localhost UG
2002:7f00:: localhost UG
2002:e000:: localhost UG
2002:ff00:: localhost UG
fe80:: localhost UG
fe80::%ex0 link#1 U
fe80::%ex1 link#2 U
fe80::%lo0 fe80::1%lo0 U
fec0:: localhost UG
ff01:: localhost U
ff02::%ex0 link#1 U
ff02::%ex1 link#2 U
ff02::%lo0 fe80::1%lo0 U
</screen>
<para>
La sección de las banderas muestra el estado y sí es o no una puerta de
enlace. En este caso vemos U, H y G (U significa que está en
funcionamiento, H anfitrión y G puerta de enlace, vea la página man para
las banderas adicionales).
</para>
<para>
Ahora una salida para netstat usando las opciones -r (encaminamiento) y -n
(mostrar número de la red):
</para>
<screen>
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 208.44.95.1 UGS 0 330309 1500 ex0
127 127.0.0.1 UGRS 0 0 33228 lo0
127.0.0.1 127.0.0.1 UH 1 1624 33228 lo0
172.15.13/24 172.16.14.37 UGS 0 0 1500 ex1
172.16 link#2 UC 13 0 1500 ex1
...
Internet6:
Destination Gateway Flags Refs Use
Mtu Interface
::/104 ::1 UGRS 0 0
33228 lo0 =>
::/96 ::1 UGRS 0 0
</screen>
<para>
La salida antedicha es un poco más prolija. Así pues, ¿cómo puede ayudar
esto? Bien, un buen ejemplo es cuando las rutas entre las redes cambian
mientras que los usuarios están conectados. Vi suceder esto varias veces
cuando alguien reiniciaba las puertas de enlace durante todo el día
después de cada cambio. Varios usuarios llamaron para decir que estaban
siendo expulsados y que les tomaba mucho tiempo volver a conectarse.
Resultó que, los clientes que se conectaban eran redirigidos a otra puerta
de enlace (que tomó una ruta muy larga) para volver a conectar. Observé la
bandera M o Modificado dinámicamente (por la re-dirección) en sus
conexiones. Suprimí las rutas e hice que los usuarios se volvieran a
conectar.
</para>
</sect2>
<sect2 id="tuning-ntools-tcpdump">
<title>tcpdump</title>
<para>
Por último está &man.tcpdump.8;, el succionador de la red que puede
obtener mucha información. En esta discusión, habrá una salida de muestra
y una explicación de algunas de las opciones más útiles de tcpdump.
</para>
<para>
Lo que sigue es un pequeño vistazo de tcpdump en acción mientras comienza:
</para>
<screen>
&rprompt <userinput>tcpdump</userinput>
tcpdump: listening on ex0
14:07:29.920651 mail.ssh > 208.44.95.231.3551: P 2951836801:2951836845(44) ack 2
476972923 win 17520 <nop,nop,timestamp 1219259 128519450> [tos 0x10]
14:07:29.950594 12.125.61.34 > 208.44.95.16: ESP(spi=2548773187,seq=0x3e8c) (DF)
14:07:29.983117 smtp.somecorp.com.smtp > 208.44.95.30.42828: . ack 420285166 win
16500 (DF)
14:07:29.984406 208.44.95.30.42828 > smtp.somecorp.com.smtp: . 1:1376(1375) ack 0
win 7431 (DF)
...
</screen>
<para>
Dado que éste servidor en particular es un servidor de correo, lo qué se
muestra tiene perfecto sentido, sin embargo, la utilidad es muy prolija;
lo que prefiero es ejecutar tcpdump sin opciones y enviar el texto de
salida a un archivo para luego digerir la información con más calma:
</para>
<screen>
&rprompt; <userinput>tcpdump > tcpdump.out</userinput>
tcpdump: listening on ex0
</screen>
<para>
Entonces, ¿qué es exactamente lo que estamos buscando? Resumiendo,
cualquier cosa que parezca fuera de lugar, por ejemplo, las extensiones
imperfectas de paquetes (como en muchos casos) se verán como una lente
incorrecta o paquetes mal formados (básicamente basura). Si, sin embargo,
estamos buscando algo específico, tcpdump puede ayudar dependiendo del
problema.
</para>
<sect3 id="tuning-ntools-tcpdump-usage">
<title>Uso específico de tcpdump</title>
<para>
Estos son sólo algunos ejemplos de las cosas que tcpdump puede hacer.
</para>
<para>
Buscar direcciones IP duplicadas:
</para>
<screen>
<userinput>tcpdump -e host ip-address</userinput>
</screen>
<para>
Por ejemplo:
</para>
<screen>
<userinput>tcpdump -e host 192.168.0.2</userinput>
</screen>
<para>
Problemas de direccionamiento:
</para>
<screen>
<userinput>tcpdump icmp</userinput>
</screen>
<para>
Hay una gran variedad de herramientas de terceros, sin embargo, &os; viene
equipado con un grupo de herramientas de calidad para hacer un seguimiento
de problemas de desempeño en la red.
</para>
</sect3>
</sect2>
</sect1>
<sect1 id="tuning-acct">
<title>Contabilidad</title>
<para>
El sistema &os; viene equipado con muchos monitores de funcionamiento para
la supervisión activa, pero ¿qué hay sobre la supervisión a largo plazo?
Bien, por supuesto la salida de una variedad de comandos se puede enviar a
algunos archivos y re-analizar más adelante con un guión de algún
intérprete de comandos o un programa significativo. &os; , por defecto,
ofrece una supervisión de bajo nivel extraordinaria, de gran alcance que
supervisa las herramientas para el programador, administrador o el
aficionado realmente astuto.
</para>
<sect2 id="tuning-acct-acct">
<title>Contabilidad</title>
<para>
Mientras que la contabilidad da uso al sistema en un nivel casi de
usuario, el seguimiento del núcleo con gprof proporciona uso explícito de
las llamadas al sistema.
</para>
<para>
Usar las herramientas de contabilidad puede ayudar a descubrir problemas
de desempeño que se podrían estar incubando, tales como el uso creciente
de compiladores o de servicios de red, por ejemplo.
</para>
<para>
Comenzar la contabilidad es bastante simple, como root, utilice el comando
&man.accton.8;. El sintaxis para comenzar con la contabilidad es:
<command>accton archivo</command>
</para>
<para>
Donde la información de la contabilidad es añadida al archivo, ahora, de
manera extraña, el comando lastcomm que lee de un archivo de salida de la
contabilidad, por defecto, mira en <filename>/var/account/acct</filename>
así que tiendo a utilizar el archivo por defecto, sin embargo, lastcomm
puede buscar en otra parte.
</para>
<para>
Para detener la contabilidad simplemente escriba accton sin argumentos.
</para>
</sect2>
<sect2 id="tuning-acct-reading">
<title>Leyendo la información de contabilidad</title>
<para>
Para leer la información de contabilidad, existen dos herramientas:
</para>
<itemizedlist>
<listitem>
<para>
&man.lastcomm.1;
</para>
</listitem>
<listitem>
<para>
&man.sa.8;
</para>
</listitem>
</itemizedlist>
<sect3 id="tuning-acct-reading-lastcomm">
<title>lastcomm</title>
<para>
El comando lastcomm exhibe en orden los últimos comandos ejecutados por
todos los usuarios. Puede, sin embargo, seleccionarlos por usuario:
</para>
<screen>
&uprompt <userinput>lastcomm jrf</userinput>
last - jrf ttyp3 0.00 secs Tue Sep 3 14:39 (0:00:00.02)
man - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:01:49.03)
sh - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:01:49.03)
less - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:01:49.03)
lastcomm - jrf ttyp3 0.02 secs Tue Sep 3 14:38 (0:00:00.02)
stty - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:00:00.02)
tset - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:00:01.05)
hostname - jrf ttyp3 0.00 secs Tue Sep 3 14:38 (0:00:00.02)
ls - jrf ttyp0 0.00 secs Tue Sep 3 14:36 (0:00:00.00)
...
</screen>
<para>
Muy agradable, el comando lastcomm consigue su información de la
localización por defecto de /var/account/acct, sin embargo, al usar la
opción -f, otro archivo puede ser especificado.
</para>
<para>
Aun que puede ser obvio, la salida del comando lastcomm puede ser un
poco abrumadora en sistemas con muchos usuarios. Aquí es donde sa
entra en acción.
</para>
</sect3>
<sect3 id="tuning-acct-reading-sa">
<title>sa</title>
<para>
El comando sa (que significa "impresión de las estadísticas de la
contabilidad del sistema", por su significado en ingles) se puede
utilizar para mantener la información. Puede también ser utilizado
interactivamente para crear informes. Lo que sigue es la salida por
defecto de sa:
</para>
<screen>
&uprompt <userinput>sa</userinput>
77 18.62re 0.02cp 8avio 0k
3 4.27re 0.01cp 45avio 0k ispell
2 0.68re 0.00cp 33avio 0k mutt
2 1.09re 0.00cp 23avio 0k vi
10 0.61re 0.00cp 7avio 0k ***other
2 0.01re 0.00cp 29avio 0k exim
4 0.00re 0.00cp 8avio 0k lastcomm
2 0.00re 0.00cp 3avio 0k atrun
3 0.03re 0.00cp 1avio 0k cron*
5 0.02re 0.00cp 10avio 0k exim*
10 3.98re 0.00cp 2avio 0k less
11 0.00re 0.00cp 0avio 0k ls
9 3.95re 0.00cp 12avio 0k man
2 0.00re 0.00cp 4avio 0k sa
12 3.97re 0.00cp 1avio 0k sh
...
</screen>
<para>
De izquierda a derecha, número total de veces llamado, tiempo real en
minutos, la suma de usuario y tiempo del sistema, en minutos, promedio
del número de operaciones de I/O por ejecución, tamaño, nombre del
comando.
</para>
<para>
El comando sa también se puede utilizar para crear archivos resumen o
informes basados en algunas opciones, por ejemplo, aquí está la salida
al especificar un orden por el uso promedio de la memoria de CPU:
</para>
<screen>
&uprompt; <userinput>sa -k</userinput>
86 30.81re 0.02cp 8avio 0k
10 0.61re 0.00cp 7avio 0k ***other
2 0.00re 0.00cp 3avio 0k atrun
3 0.03re 0.00cp 1avio 0k cron*
2 0.01re 0.00cp 29avio 0k exim
5 0.02re 0.00cp 10avio 0k exim*
3 4.27re 0.01cp 45avio 0k ispell
4 0.00re 0.00cp 8avio 0k lastcomm
12 8.04re 0.00cp 2avio 0k less
13 0.00re 0.00cp 0avio 0k ls
11 8.01re 0.00cp 12avio 0k man
2 0.68re 0.00cp 33avio 0k mutt
3 0.00re 0.00cp 4avio 0k sa
14 8.03re 0.00cp 1avio 0k sh
2 1.09re 0.00cp 23avio 0k vi
</screen>
<para>
El comando sa es muy útil en sistemas grandes.
</para>
</sect3>
</sect2>
<sect2 id="tuning-acct-enabling">
<title>Cómo poner la contabilidad en uso</title>
<para>
Los informes de contabilidad, como fue mencionado anteriormente, ofrecen
una manera de predecir tendencias, por ejemplo, en un sistema que tenga
cc y make siendo utilizados más y más puede indicar que en algunos meses
algunos cambios necesitarán ser realizados para mantener al sistema
funcionando en un nivel óptimo. Otro buen ejemplo es el uso de servidor
de portales de internet. Si comienza a aumentar gradualmente, otra vez,
alguna clase de acción puede necesitar ser tomada antes de que se
convierta en un problema. Afortunadamente, con las herramientas de
contabilidad, tales acciones se pueden predecir razonablemente y
planearlas con una ventaja de tiempo.
</para>
</sect2>
</sect1>
<sect1 id="tuning-kprof">
<title>Seguimiento del núcleo</title>
<para>
El hacer el seguimiento de un núcleo se emplea normalmente cuando la
meta es comparar la diferencia de nuevos cambios en el núcleo a uno
anterior o de supervisar alguna clase de problema de funcionamiento de
bajo nivel. Dos sistemas de datos sobre comportamiento del código se
registran independientemente: frecuencia de llamadas de función y tiempo
pasado en cada función.
</para>
<sect2 id="tuning-kprof-starting">
<title>Comenzando</title>
<para>
Primero, eché una ojeada tanto a <xref linkend="tuning-kernel" /> y a
<xref linkend="chap-kernel" />. La única diferencia en el procedimiento
para compilar un núcleo con seguimiento permitido es que cuando usted
ejecuta config agregue la opción -p. El área de construcción es
<filename>../compile/<KERNEL_NAME>.PROF</filename>, por ejemplo,
un núcleo GENÉRICO sería <filename>../compile/GENERIC.PROF</filename>.
</para>
<para>
Lo que sigue es un resumen rápido de cómo compilar un núcleo con
seguimiento permitido en el port i386, las asunciones son que las
fuentes apropiadas están disponibles en <filename>/usr/src</filename> y
que se está utilizando la configuración GENÉRICA, por supuesto, que
puede que no siempre sea ésta la situación:
</para>
<orderedlist>
<listitem>
<para>
<userinput>cd /usr/src/sys/arch/i386/conf</userinput>
</para>
</listitem>
<listitem>
<para>
<userinput>config -p GENERIC</userinput>
</para>
</listitem>
<listitem>
<para>
<userinput>cd ../compile/GENERIC.PROF</userinput>
</para>
</listitem>
<listitem>
<para>
<userinput>make depend && make</userinput>
</para>
</listitem>
<listitem>
<para>
<userinput>cp /netbsd /netbsd.old</userinput>
</para>
</listitem>
<listitem>
<para>
<userinput>cp netbsd /</userinput>
</para>
</listitem>
<listitem>
<para>
<userinput>reboot</userinput>
</para>
</listitem>
</orderedlist>
<para>
Una vez que el nuevo núcleo esté en su lugar y que el sistema sea
reiniciado, es hora de empezar la supervisión y empezar a buscar
resultados.
</para>
<sect3 id="tuning-kprof-starting-kgmon">
<title>Usando kgmon</title>
<para>
Para iniciar kgmon:
</para>
<screen>
&uprompt; <userinput>kgmon -b</userinput>
kgmon: kernel profiling is running.
</screen>
<para>
Luego, mande la información al archivo <filename>gmon.out</filename>:
</para>
<screen>
&uprompt; <userinput>kgmon -p</userinput>
</screen>
<para>
Ahora es el momento de hacer la salida legible:
</para>
<screen>
&uprompt; <userinput>gprof /netbsd > gprof.out</userinput>
</screen>
<para>
Ya que gmon esta buscando <filename>gmon.out</filename>, debe
encontrarlo en el directorio de trabajo actual.
</para>
<para>
Si solamente ejecuta kgmon, puede que usted no consiga la información
que necesita, sin embargo, si está comparando las diferencias entre dos
núcleos distintos, entonces una buena línea de fondo conocida debe ser
utilizada. Observe que generalmente es una buena idea tensionar el
subsistema si usted sabe cual es la línea de fondo con el núcleo más
nuevo (o distinto).
</para>
</sect3>
</sect2>
<sect2 id="tuning-kprof-intkgmon">
<title>Interpretación de la salida de kgmon</title>
<para>
Ahora que kgmon puede funcionar, recoger y analizar la información, es
hora de mirar realmente algo de esa información. En este caso
particular, un núcleo GENÉRICO está funcionando con seguimiento
permitido por alrededor de una hora con solamente procesos del sistema y
no hay carga adversa, en la sección de inserción de averías, el ejemplo
será lo bastante grande que incluso bajo detección mínima de carga del
problema debe ser fácil.
</para>
<sect3 id="tuning-kprof-intkgmon-flat">
<title>Perfil plano</title>
<para>
El perfil plano es una lista de funciones, el número de veces que fueron
llamadas y cuánto tiempo tomó (en segundos). Lo que sigue es una muestra
hecha del sistema mencionado:
</para>
<screen>
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ns/call ns/call name
99.77 163.87 163.87 idle
0.03 163.92 0.05 219 228310.50 228354.34 _wdc_ata_bio_start
0.02 163.96 0.04 219 182648.40 391184.96 wdc_ata_bio_intr
0.01 163.98 0.02 3412 5861.66 6463.02 pmap_enter
0.01 164.00 0.02 548 36496.35 36496.35 pmap_zero_page
0.01 164.02 0.02 Xspllower
0.01 164.03 0.01 481968 20.75 20.75 gettick
0.01 164.04 0.01 6695 1493.65 1493.65 VOP_LOCK
0.01 164.05 0.01 3251 3075.98 21013.45 syscall_plain
...
</screen>
<para>
Según lo esperado, el porcentaje más alto pertenece a la desocupación,
sin embargo, todavía había algunas cosas que sucedían, por ejemplo, un
poco más abajo de allí está la función <emphasis>vn_lock</emphasis>:
</para>
<screen>
...
0.00 164.14 0.00 6711 0.00 0.00 VOP_UNLOCK
0.00 164.14 0.00 6677 0.00 1493.65 vn_lock
0.00 164.14 0.00 6441 0.00 0.00 genfs_unlock
</screen>
<para>
Esto no es inesperado, ya que el asegurado todavía funciona.
</para>
</sect3>
<sect3 id="tuning-kprof-intkgmon-callgraph">
<title>Perfil gráfico de llamadas</title>
<para>
El gráfico de llamadas es una versión aumentada del perfil plano que
exhibe llamadas subsecuentes de las funciones listadas. Primero, aquí
está una muestra:
</para>
<screen>
Call graph (explanation follows)
granularity: each sample hit covers 4 byte(s) for 0.01% of 164.14 seconds
index % time self children called name
<spontaneous>
[1] 99.8 163.87 0.00 idle [1]
-----------------------------------------------
<spontaneous>
[2] 0.1 0.01 0.08 syscall1 [2]
0.01 0.06 3251/3251 syscall_plain [7]
0.00 0.01 414/1660 trap [9]
-----------------------------------------------
0.00 0.09 219/219 Xintr14 [6]
[3] 0.1 0.00 0.09 219 pciide_compat_intr [3]
0.00 0.09 219/219 wdcintr [5]
-----------------------------------------------
...
</screen>
<para>
Esto puede ser un poco confuso. El número del index es mapeado desde
y hasta el último número al final de la línea, por ejemplo,
</para>
<screen>
...
0.00 0.01 85/85 dofilewrite [68]
[72] 0.0 0.00 0.01 85 soo_write [72]
0.00 0.01 85/89 sosend [71]
...
</screen>
<para>
Acá vemos que dofilewrite fue llamado primero, ahora podemos ver
al número del index correspondiente a 64 y ver que ocurre allí:
</para>
<screen>
...
0.00 0.01 101/103 ffs_full_fsync <cycle 6> [58]
[64] 0.0 0.00 0.01 103 bawrite [64]
0.00 0.01 103/105 VOP_BWRITE [60]
...
</screen>
<para>
Y así, de ésta manera, un "rastro visual" puede establecerse.
</para>
<para>
Al final del gráfico de llamadas, justo después de la sección de
términos, está un index por nombre de función que puede ayudar
a mapear los indexes también.
</para>
</sect3>
</sect2>
<sect2 id="tuning-kprof-use">
<title>Poniéndolo en práctica</title>
<para>
En este ejemplo, he modificado un área del núcleo que sé que causará
un problema muy obvio.
</para>
<para>
He aquí la porción superior del perfil plano luego de correr el sistema
como una hora, con poca interacción con los usuarios:
</para>
<screen>
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls us/call us/call name
93.97 139.13 139.13 idle
5.87 147.82 8.69 23 377826.09 377842.52 check_exec
0.01 147.84 0.02 243 82.30 82.30 pmap_copy_page
0.01 147.86 0.02 131 152.67 152.67 _wdc_ata_bio_start
0.01 147.88 0.02 131 152.67 271.85 wdc_ata_bio_intr
0.01 147.89 0.01 4428 2.26 2.66 uvn_findpage
0.01 147.90 0.01 4145 2.41 2.41 uvm_pageactivate
0.01 147.91 0.01 2473 4.04 3532.40 syscall_plain
0.01 147.92 0.01 1717 5.82 5.82 i486_copyout
0.01 147.93 0.01 1430 6.99 56.52 uvm_fault
0.01 147.94 0.01 1309 7.64 7.64 pool_get
0.01 147.95 0.01 673 14.86 38.43 genfs_getpages
0.01 147.96 0.01 498 20.08 20.08 pmap_zero_page
0.01 147.97 0.01 219 45.66 46.28 uvm_unmap_remove
0.01 147.98 0.01 111 90.09 90.09 selscan
...
</screen>
<para>
Como es obvio, hay una gran diferencia en el funcionamiento. Lo primero
que salta a la vista es que el tiempo desocupado es perceptiblemente
menor. La diferencia principal aquí es que una función particular tiene
un tiempo grande a través del tablero con muy pocas llamadas. Esa
función es <emphasis>check_exec</emphasis>. Mientras que al principio,
esto puede no parecer extraño si muchos comandos han sido ejecutados,
cuando es comparado al perfil plano de la primera medida,
proporcionalmente no parece correcto:
</para>
<screen>
...
0.00 164.14 0.00 37 0.00 62747.49 check_exec
...
</screen>
<para>
La llamada en la primera medida se hace 37 veces y tiene un mejor
funcionamiento. Obviamente algo en o alrededor de esa función no es
correcto. Al eliminar otras funciones, una mirada al gráfico de
llamadas puede ayudar, aquí está la primera instancia de
<emphasis>check_exec</emphasis>:
</para>
<screen>
...
-----------------------------------------------
0.00 8.69 23/23 syscall_plain [3]
[4] 5.9 0.00 8.69 23 sys_execve [4]
8.69 0.00 23/23 check_exec [5]
0.00 0.00 20/20 elf32_copyargs [67]
...
</screen>
<para>
Note cómo el tiempo de 8.69 parece afectar a las dos funciones
anteriores. Es posible que haya algo mal con ellas, sin embargo, el
siguiente caso de <emphasis>check_exec</emphasis> parece probar otra
cosa:
</para>
<screen>
...
-----------------------------------------------
8.69 0.00 23/23 sys_execve [4]
[5] 5.9 8.69 0.00 23 check_exec [5]
...
</screen>
<para>
Ahora podemos ver que el problema, más probablemente, reside en
<emphasis>check_exec</emphasis>. Por supuesto, los problemas no son
siempre así de simples y de hecho, aquí son el código que fue insertado
después de <emphasis>check_exec</emphasis> (la función está en
<filename>sys/kern/kern_exec.c</filename>):
</para>
<screen>
...
/* A Cheap fault insertion */
for (x = 0; x < 100000000; x++) {
y = x;
}
..
</screen>
<para>
No es exactamente impresionante, pero es suficiente para registrar una gran
cambio con el seguimiento.
</para>
</sect2>
<sect2 id="tuning-kprof-summary">
<title>Resumen</title>
<para>
El seguimiento del núcleo puede aclarar muchas cosas para cualquier
persona y proporciona un método más refinado para cazar problemas de
funcionamiento que no sean fáciles de encontrar con medios
convencionales, y no es tan difícil como la mayoría de la gente piensa;
si usted puede compilar un núcleo, puede conseguir que el seguimiento
funcione.
</para>
</sect2>
</sect1>
<sect1 id="tuning-system">
<title>Afinado del sistema</title>
<para>
Ahora que se han tratado las herramientas de supervisión y de análisis,
es hora de mirar algunos métodos reales. En esta sección, se tratan las
herramientas y los métodos que pueden afectar cómo el sistema se
desempeña que se aplican sin recompilar el núcleo, la siguiente sección
examina al núcleo utilizando un recompilado para afinarlo.
</para>
<sect2 id="tuning-system-sysctl">
<title>Usando sysctl</title>
<para>
La utilidad sysctl se puede utilizar para mirar y en algunos casos
alterar los parámetros del sistema. Hay tantos parámetros que pueden ser
vistos y cambiados que no todos pueden ser demostrados aquí, sin embargo,
para el primer ejemplo aquí está un uso simple de sysctl para mirar la
variable de entorno del sistema PATH:
</para>
<screen>
&uprompt; <userinput>sysctl user.cs_path</userinput>
user.cs_path = /usr/bin:/bin:/usr/sbin:/sbin:/usr/pkg/bin:/usr/pkg/sbin:/usr/local/bin:/usr/local/sbin
</screen>
<para>
Bastante simple. Ahora algo que se relaciona realmente con el
funcionamiento. Como ejemplo, digamos que un sistema con muchos usuarios
está teniendo problemas con la apertura de archivos, examinando y quizás
levantando el parámetro kern.maxfiles el problema puede ser solucionado,
pero primero, una mirada:
</para>
<screen>
&uprompt; <userinput>sysctl kern.maxfiles</userinput>
kern.maxfiles = 1772
</screen>
<para>
Ahora, para cambiarla, como root con la opción -w especificada:
</para>
<screen>
&rprompt; <userinput>sysctl -w kern.maxfiles=1972</userinput>
kern.maxfiles: 1772 -> 1972
</screen>
<para>
Note que, cuando se reinicia el sistema, el viejo valor volverá, has dos
soluciones para esto: primero, modificar ese parámetro en el núcleo y
recompilar, y segundo (y más simple) agregue esta línea a
<filename>/etc/sysctl.conf</filename>:
</para>
<screen>
kern.maxfiles=1972
</screen>
</sect2>
<!-- XXX - At the moment of writing ideal vm.* values for machines with
thashing problems are still debated. So, we'll comment this section
out for now. When we add this, we should also add this excellent
mail by SODA Noriyuki:
http://mail-index.NetBSD.org/current-users/2004/09/01/0000.html
<sect2 id="tuning-system-ubc">
<title>UBC and sysctl</title>
<para>
From what I have gathered on a variety of lists, the most
commonly <quote>tweaked</quote> part of the system via sysctl is
the Unified Buffer Cache (UBC). In a really great
<ulink url="http://mail-index.NetBSD.org/tech-perform/2002/08/03/0000.html">email</ulink>
a developer made some excellent recommendations for tuning a system
with UBC, this section will peruse that for the example.
</para>
<para>
Following along with the maxfiles example above, even though there
can now be a larger amount of open files, there still may be more
that can be done to make the system run faster. Since more files
can be opened, it stands to reason that it would be good if the
caching were optimized as well. In the case of this machine,
there is a decent amount of RAM (256MB) that despite a lot of
low level activity (such as editing and small compiles) is not
being utilized to its full potential. This means that the buffer
cache could probably be expanded, thereby making performance better
since more would be in the cache versus rereading from disk. Now,
a word of warning, it is of course possible to raise the size to
a point where getting a cache hit is taking too long, but as
has been well documented, that number seems to be fairly high. So
what is the parameter? It is kern.maxvnodes and in the case of
this machine, 38k was used which gave a pretty decent performance boost. In general, it has been seen that a kern.maxvnodes operates
well when the size is set to between 1/6 to 1/4 of the amount of
RAM (depending on what the system is being used for).
</para>
<para>
You can also improve performance by tuning vm.anonmax, which
sets the amount of physical memory that can be reclaimed for anonymous
application data. Simon Burge wrote a
<ulink url="http://mail-index.NetBSD.org/tech-kern/2002/11/27/0005.html">very good post</ulink> to tech-kern
discussing this; it is highly recommended that you read his entire
e-mail before setting values for your system. For the lazy amongst us,
though, <command>sysctl -w vm.anonmax=95</command> seems to work well
for him on his pc532 with 8MB of RAM; it might work well for your
system too.
</para>
</sect2>
-->
<sect2 id="tuning-system-memfs">
<title>memfs & softdeps</title>
<para>
Un sistema operativo puede beneficiarse a menudo de algunos cambios de
configuración (a lo largo de las mismas líneas, puede también ser de
gran detrimento). Dos casos particulares donde el funcionamiento del
sistema puede ser cambiado son usando sistemas de ficheros basados en
memoria y/o actualizaciones de software (soft updates).
</para>
<sect3 id="tuning-system-memfs-memfs">
<title>Usando memfs</title>
<para>
Cuándo utilizar o no utilizar el sistema de archivos basado en memoria
pueden ser difícil de decidir en sistemas grandes multi-usuario. En algunos
casos, sin embargo, tiene bastante sentido, por ejemplo, en una máquina de
desarrollo usada por solamente un desarrollador a la vez, el directorio
obj pudo ser un buen lugar, o alguno de los directorios tmp para las
construcciones. En un caso cómo éste, tiene sentido en máquinas que
tienen una buena cantidad de RAM en ellas. La otra cara de la moneda, si
un sistema tiene solamente 16MB del RAM y <filename>/var/tmp</filename>
está basado en memfs, podría haber severos problemas en las aplicaciones
que ocurren.
</para>
<para>
El núcleo GENÉRICO tiene memfs permitido por defecto. Para utilizarlo en
un directorio en particular primero determínese donde está el espacio
de intercambio que usted desea utilizar, en el caso del ejemplo, una
mirada rápida en <filename>/etc/fstab</filename> indica que
<filename>/dev/wd0b</filename> es la partición de intercambio:
</para>
<screen>
mail% cat /etc/fstab
/dev/wd0a / ffs rw 1 1
/dev/wd0b none swap sw 0 0
/kern /kern kernfs rw
</screen>
<para>
Este sistema es un servidor de correo así que deseo solamente utilizar
<filename>/tmp</filename> con memfs, también en este sistema particular he
ligado <filename>/tmp</filename> a <filename>/var/tmp</filename> para ahorrar
espacio (ambos están en el mismo dispositivo). Todo lo que necesito hacer es
agregar la siguiente entrada:
</para>
<screen>
/dev/wd0b /var/tmp mfs rw 0 0
</screen>
<para>
Ahora, una palabra de advertencia, cerciórese de que dichos directorios
estén vacíos y nada los esté utilizando cuando usted monta el sistema de
ficheros de memoria. En este punto puedo <command>mount -a</command> o
reanudar el sistema.
</para>
</sect3>
<sect3 id="tuning-system-memfs-softdep">
<title>Usando softdeps</title>
<para>
Soft-dependencies es un mecanismo que no escribe meta-datos al disco
inmediatamente, sino que se escriben en una manera pedida, que mantiene
consistente al sistema de archivos.
<xref linkend="chap-boot-enabling-softdep" /> describe cómo habilitar
soft-dependencies. Mucha más información sobre las capacidades de
softdep se puede encontrar en la
<ulink url="http://www.mckusick.com/softdep/index.html">página del autor</ulink>.
</para>
</sect3>
</sect2>
</sect1>
<sect1 id="tuning-kernel">
<title>Afinado del núcleo</title>
<para>
A pesar de que muchos parámetros del sistema se pueden cambiar con
sysctl, muchas mejoras usando software del sistema realzado,
disposición del sistema y manejo de los servicios (moviéndolos dentro y
fuera de inetd por ejemplo) también se pueden alcanzar. Sin embargo
afinar el núcleo proporcionará un funcionamiento mejor, incluso si
parece ser marginal.
</para>
<sect2 id="tuning-kernel-prepare">
<title>Preparando la recompilación del núcleo</title>
<para>
Primero, consiga las fuentes del núcleo para el lanzamiento como está
descrito en <xref linkend="chap-cvs" />, se recomienda leer <xref
linkend="chap-kernel" /> para más información sobre la construcción del
núcleo . Observe, este documento puede ser utilizado para el afinado
-current, sin embargo, una lectura a la documentación del <ulink
url="http://www.NetBSD.org/Documentation/current/">Seguimiento de
-current</ulink> debe ser realizada primero.
</para>
</sect2>
<sect2 id="tuning-kernel-configure">
<title>Configurando el núcleo</title>
<!-- XXX: integrate this in chap-kernel -->
<para>
La configuración de un núcleo en &os; puede ser desalentadora. Esto es
debido a la múltiple línea de dependencias dentro del archivo de la
configuración en sí mismo, sin embargo, hay una ventaja en este método y
es que, todo lo que realmente se necesita es un redactor ASCII para
conseguir un nuevo núcleo configurado y una salida de dmesg. El archivo
de configuración del núcleo está en <filename>src/sys/arch/ARCH/conf</filename>
donde ARCH es su arquitectura (por ejemplo, en un SPARC estaría en
<filename>src/sys/arch/sparc/conf</filename>).
</para>
<para>
Después de que haya localizado su archivo de configuración del núcleo,
copiélo y retire (comente) todas las entradas que no necesita. Es aquí
donde &man.dmesg.8; se convierte en su amigo. Una salida de &man.dmesg.8;
mostrará todos los dispositivos detectados por el núcleo en el tiempo de
arranque. Al usar la salida de &man.dmesg.8;, las opciones de
dispositivos realmente necesarios pueden ser determinadas. Para cierta
automatización, compruebe el paquete "adjustkernel".
</para>
<sect3 id="tuning-kernel-configure-example">
<title>Algunos ejemplos de ítemes de configuración</title>
<para>
En este ejemplo, el núcleo de un servidor ftp se está configurando de
nuevo para funcionar con los controladores y las opciones mínimas y
cualquier otro ítem que pudiera hacer que funcione más rápidamente (otra
vez, no necesariamente más pequeño, aunque así será). La primera cosa
que hacer es echar una ojeada algunos de los ítemes principales de
configuración. Así pues, en
<filename>/usr/src/sys/arch/i386/conf</filename> el archivo GENÉRICO se
copia a FTP, entonces el archivo FTP es editado.
</para>
<para>
Al comienzo del archivo hay un manojo de opciones que comienzan con
maxusers, que no será alterado, sin embargo, en sistemas multi-usuario
más grandes puede ser que sea de ayuda elevar un poco éste valor. Luego
está el soporte del CPU, mirando la salida de dmesg eso se ve:
</para>
<screen>
cpu0: Intel Pentium II/Celeron (Deschutes) (686-class), 400.93 MHz
</screen>
<para>
Indicando que solamente las opciones I686_CPU necesitan ser utilizadas.
En la siguiente sección, todas las opciones se dejan intactas, excepto
PIC_DELAY el cual se recomienda a menos que sea una máquina vieja. En
este caso se permite puesto que los 686 son relativamente nuevos.
</para>
<para>
Entre la sección pasada y toda lo que siguió luego, no era realmente
necesario cambiar algo en este sistema en particular. En la sección
compat, sin embargo, hay varias opciones que no necesitan ser
habilitadas, ésto es, otra vez, porque esta máquina es terminantemente
un servidor ftp, todas las opciones de compat fueron deshabilitadas.
</para>
<para>
La próxima sección es la de sistema de archivos, y nuevamente, para
éste servidor, muy pocas son necesarias:
</para>
<screen>
# File systems
file-system FFS # UFS
file-system LFS # log-structured file system
file-system MFS # memory file system
file-system CD9660 # ISO 9660 + Rock Ridge file system
file-system FDESC # /dev/fd
file-system KERNFS # /kern
file-system NULLFS # loopback file system
file-system PROCFS # /proc
file-system UMAPFS # NULLFS + uid and gid remapping
...
options SOFTDEP # FFS soft updates support.
...
</screen>
<para>
Luego viene la sección de red. Las opciones que se dejaron fueron:
</para>
<screen>
options INET # IP + ICMP + TCP + UDP
options INET6 # IPV6
options IPFILTER_LOG # &man.ipmon.8; log support
</screen>
<para>
IPFILTER_LOG es una opción muy agradable para tenerla encendida, ya
que el servidor estará corriendo ipf.
</para>
<para>
La siguiente sección es de mensajes extensivos para los varios
subsistemas, puesto que esta máquina estaba ya corriendo y no tenía
ningún problema importante, todos se comentan.
</para>
</sect3>
<sect3 id="tuning-kernel-configure-drivers">
<title>Algunos controladores</title>
<para>
Los ítemes configurables en el archivo de configuración son
relativamente pocos y fáciles de cubrir, sin embargo, los controladores
de dispositivos son una historia muy distinta. En los ejemplos siguientes,
dos controladores se examinan y sus <quote>áreas</quote> asociadas en
el archivo se ajustan. Primero, un ejemplo pequeño: el cdrom, en dmesg,
es las líneas siguientes:
</para>
<screen>
...
cd0 at atapibus0 drive 0: <CD-540E, , 1.0A> type 5 cdrom removable
cd0: 32-bit data port
cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 2
pciide0: secondary channel interrupting at irq 15
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 (using DMA data transfer
...
</screen>
<para>
Ahora, es tiempo de encontrar esa sección abajo en el archivo de
configuración. Note que "cd"-drive está en un atapibus y requiere el
soporte de pciide. La sección que es de interés en este caso es la de
los dispositivos relacionados con "IDE and related devices". Vale el
observar en este punto, que en y alrededor de la sección IDE están
también ISA, PCMCIA etc., en esta máquina en la salida de &man.dmesg.8;
no existe ningún dispositivo de PCMCIA, así que es muy lógico razonar
que todas las referencias de PCMCIA pueden ser quitadas. Pero primero,
el dispositivo del "Cd".
</para>
<para>
Al principio de la sección IDE está lo siguiente:
</para>
<screen>
...
wd* at atabus? drive ? flags 0x0000
...
atapibus* at atapi?
...
</screen>
<para>
Bueno, es muy obvio que esas líneas son necesarias. Luego esto:
</para>
<screen>
...
# ATAPI devices
# flags have the same meaning as for IDE drives.
cd* at atapibus? drive ? flags 0x0000 # ATAPI CD-ROM drives
sd* at atapibus? drive ? flags 0x0000 # ATAPI disk drives
st* at atapibus? drive ? flags 0x0000 # ATAPI tape drives
uk* at atapibus? drive ? flags 0x0000 # ATAPI unknown
...
</screen>
<para>
El único dispositivo que estaba en la salida de &man.dmesg.8; era el cd,
el resto puede ser comentado.
</para>
<para>
El siguiente ejemplo es ligeramente más complicado, interfaces de red.
Ésta máquina tiene dos:
</para>
<screen>
...
ex0 at pci0 dev 17 function 0: 3Com 3c905B-TX 10/100 Ethernet (rev. 0x64)
ex0: interrupting at irq 10
ex0: MAC address 00:50:04:83:ff:b7
UI 0x001018 model 0x0012 rev 0 at ex0 phy 24 not configured
ex1 at pci0 dev 19 function 0: 3Com 3c905B-TX 10/100 Ethernet (rev. 0x30)
ex1: interrupting at irq 11
ex1: MAC address 00:50:da:63:91:2e
exphy0 at ex1 phy 24: 3Com internal media interface
exphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
...
</screen>
<para>
A primera vista, puede parecer que en realidad son tres dispositivos,
pero una mirada más detallada en está línea:
</para>
<screen>
exphy0 at ex1 phy 24: 3Com internal media interface
</screen>
<para>
Revela que existen únicamente dos tarjetas físicas, no muy distinto al
cdrom, simplemente con quitar nombres que no están en dmesg será suficiente.
Al principio de la sección de interfaces de red está:
</para>
<screen>
...
# Network Interfaces
# PCI network interfaces
an* at pci? dev ? function ? # Aironet PC4500/PC4800 (802.11)
bge* at pci? dev ? function ? # Broadcom 570x gigabit Ethernet
en* at pci? dev ? function ? # ENI/Adaptec ATM
ep* at pci? dev ? function ? # 3Com 3c59x
epic* at pci? dev ? function ? # SMC EPIC/100 Ethernet
esh* at pci? dev ? function ? # Essential HIPPI card
ex* at pci? dev ? function ? # 3Com 90x[BC]
...
</screen>
<para>
Ahí está el dispositivo ex. Así que el resto en la sección PCI puede
ser eliminado. Adicionalmente, cada línea por debajo de ésta:
</para>
<screen>
exphy* at mii? phy ? # 3Com internal PHYs
</screen>
<para>
puede ser comentada como el resto lo fue.
</para>
</sect3>
<sect3 id="tuning-kernel-configure-multipass">
<title>Múltiples pasos</title>
<para>
Cuando afino un núcleo, tengo gusto de hacerlo remotamente en una sesión
de ventanas X, en una ventana la salida de dmesg, en la otra el archivo
config. Puede tomar a veces algunos pasos para reconstruir un núcleo muy
ajustado puesto que es fácil quitar accidentalmente dependencias.
</para>
</sect3>
</sect2>
<sect2 id="tuning-kernel-building">
<title>Construyendo el nuevo núcleo </title>
<para>
Ahora es el momento de construir un nuevo núcleo y ponerlo en su lugar.
En el directorio conf del servidor ftp, el siguiente comando prepara la
construcción:
</para>
<screen>
&uprompt <userinput>config FTP</userinput>
</screen>
<para>
Cuando ya está hecho, un mensaje recordándome que realice "make depend" aparecerá,
luego:
</para>
<screen>
&uprompt <userinput>cd ../compile/FTP</userinput>
&uprompt <userinput>make depend && make</userinput>
</screen>
<para>
Una vez realizado, hago una copia de seguridad del antiguo núcleo y coloco
el nuevo en su lugar:
</para>
<screen>
&rprompt <userinput>cp /netbsd /netbsd.orig</userinput>
&rprompt <userinput>cp netbsd /</userinput>
</screen>
<para>
Ahora a reiniciar. Si el núcleo no puede iniciar, pare el proceso de
arranque cuando se le pide y escriba <userinput>boot netbsd.orig</userinput>
para arrancar con el núcleo anterior.
</para>
</sect2>
</sect1>
</chapter>
--MGYHOYXEY6WxJCY8--