On Tue, 18 Feb 2003, Santiago Vila wrote:
> hector debian escribi�:
> > mat� el proceso en el top y luego coment� todas las l�neas del archivo
> > /etc/cron.daily/find (donde hab�a un updatedb) con eso creo que se arreglo.
>
> Felicidades, acabas de estropear la orden "locate" de tu sistema.
No necesariamente. Una persona consciente de lo que hace puede desear
hacer updatedb manualmente de vez en cuando.
Por otra parte imagina que en el momendo que se activa la tarea updatedb
tienes un dispositivo removible cualquiera montado y lleno de ficheros.
Te hace la gracia de meterte un mont�n de informaci�n seguramente inutil
en esa BD de ficheros.
Yo he alterado un poco las cosas y lo ejecuto como tarea un par de veces
por semana. He a�adido un cron.2_weekly y he colocado las horas de forma
que esas tareas no me incomoden tanto como antes pero continua incomod�ndome.
Por si a alguien le interesa paso mi /etc/crontab
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# (mon = 3,6 = Miercoles,Sabado)
# m h dom mon dow user command
55 8 * * * root test -e /usr/sbin/anacron || run-parts --report
/etc/cron.daily
0 9 * * 3,6 root test -e /usr/sbin/anacron || run-parts --report
/etc/cron.2_weekly
0 9 * * 7 root test -e /usr/sbin/anacron || run-parts --report
/etc/cron.weekly
10 9 1 * * root test -e /usr/sbin/anacron || run-parts --report
/etc/cron.monthly
#
Lo que estar�a bien es que el sistema de gesti�n de prioridad de ejecuci�n
de procesos hiciera que los procesos poco prioritarios consumieran mucho
menos recursos que los procesos con prioridad m�s alta pero yo creo que
esto se nota demasiado poco. No me refiero solo a usar un parche para que
el kernel sea preentivo (o como si diga en espa�ol). Eso solo mejora la
catastr�fica situaci�n en que quedan normalmente los procesos interactivos
cuando el sistema esta sobrecargado. Me refiero a que updatedb es una tarea
que tarda unos pocos minutos pero no tendr�a ninguna importancia si ese
proceso y otros muchos de mantenimiento del sistema tardaran diez o veinte
veces m�s con tal de no hacer ni el menor estorbo.
Una cosa que se puede hacer es mandar a esos procesos una se�al SIGSTOP
(kill -19) para detenerlos y una se�al SIGCONT (kill -18) para reanudarlos
a conveniencia, pero es una chapuza incomoda si hay que hacerlo manualmente.
Un proceso detenido no libera todos los recursos pero si libera memoria,
CPU, y entrada/salida que son los que generalmente los entran en deficit.
Lo ideal ser�a hacer una especie de supernice capaz de lanzar procesos
que se detengan y que se reactiven siguiendo una pol�tica que permita
dosificar el nivel de carga del sistema.
--
Un saludo
Antonio Castro
/\ /\ Ciberdroide Inform�tica
\\W// << http://www.ciberdroide.com >>
_|0 0|_
+-oOOO-(___o___)-OOOo---------------------+
| . . . . U U . Antonio Castro Snurmacher |
| . . . . . . . [EMAIL PROTECTED] |
+()()()---------()()()--------------------+
