Re: Solucionado creo Re: misterioso Find
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 |
| . . . . . . . acastro@ciberdroide.com |
+()()()---------()()()--------------------+
Reply to: