El otro día se llenó el recurso compartido de nuestro servidor Samba (ubuntu 8.04 ltr), pero cuando fui a verlo no vi que ninguno de los recursos compartidos tuviera demasiado contenido.
Tenemos 5 acciones grupales y luego cada usuario tiene una acción individual.
Un usuario tiene 22 GB de cosas, otros tienen entre 10 y 20 MB de cosas y todos los demás están vacíos.
entonces tal vez como 26 gigas en total
Ayer eliminé algunos archivos y liberé alrededor de 250 MB de espacio hoy, cuando verifiqué que estaba completamente lleno nuevamente, eliminé algunos archivos más antiguos y liberé alrededor de 170 MB de cosas, pero puedo verlo disminuir lentamente en el espacio libre.
sigo ejecutando undf -h
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 241690180 229340500 169200 100% /
varrun 257632 260 257372 1% /var/run
varlock 257632 0 257632 0% /var/lock
udev 257632 72 257560 1% /dev
devshm 257632 52 257580 1% /dev/shm
lrm 257632 40000 217632 16% /lib/modules/2.6.24-28-generic
/volátil
¿Qué puedo hacer para intentar localizar lo que ocupa gran parte de mi disco duro? (soy bastante nuevo en Unix en general, así que pido disculpas si no se explica bien)
Respuesta1
(Esta es una respuesta centrada en Linux. Otras variantes de UNIX pueden ser diferentes).
Hay dos datos relevantes para su problema: (1) qué archivos están llenando su sistema de archivos y (2) qué procesos están escribiendo en esos archivos.
Notas
A continuación, cuando pongo el $carácter en los comandos, probablemente sea un marcador de posición donde necesitas sustituir un valor real. Con suerte, es obvio dónde hacer eso y dónde no.
¿Qué archivos?
Tenga en cuenta que en realidad hay dos recursos en la mayoría de los tipos de sistemas de archivos que pueden ser utilizados por archivos individuales: metadatos (por ejemplo, inodos) y datos reales. Puedes ver la cantidad de inodos (busca una definición en Google, pero son "punteros" a las estructuras que componen tus archivos) con un comando como:
df -i
... y como ya sabes, algo como esto mostrará el espacio que utilizan los datos reales:
df -h
Además, tenga en cuenta que el espacio del sistema de archivos puede estar ocupado por archivos que no existen en el disco. Estos archivos todavía están en estado abierto mediante algún proceso, pero se han eliminado (lo cubriremos a continuación).
Una vez que haya identificado los sistemas de archivos completos, deberá comenzar a buscar muchos archivos pequeños, algunos archivos grandes o ambos. Quedarse sin recursos de metadatos suele deberse a tener muchos archivos pequeños, mientras que quedarse sin recursos de datos reales suele deberse a unos pocos archivos grandes. Me gusta usar este comando para ayudar a encontrar archivos grandes:
sudo find $file_system -mount -ls | awk '{print $7, $11}' | sort -rn > $output
... y este comando para ayudar a encontrar directorios con muchos archivos pequeños (Actualizar:: terminación nula agregada para mejorar el manejo de nombres de archivos):
sudo find . -mount -print0 | xargs -0n 1 dirname | sort | uniq -c | sort -rn > $output
... tenga en cuenta que estos comandos pueden tardar un poco en ejecutarse y realizar muchas E/S, dependiendo. Una vez ejecutado, puede leer $outputpara encontrar los archivos o directorios infractores. El nombre y la ubicación de cada uno pueden darle una pista sobre de dónde provienen los datos, pero requiere algo de experiencia en Linux.
Una vez que haya identificado a los infractores, podrá rm $filedeshacerse del problema.
¿Qué procesos?
La forma más sencilla de encontrar los procesos que potencialmente llenan su sistema de archivos es ejecutar un comando como:
fuser -c $file_system 2>/dev/null
... que le indicará el PID de los procesos que tienen descriptores de archivos abiertos (archivos y sockets de red) para el sistema de archivos determinado (la 2>/dev/nullparte elimina cierta información que no necesita). Es posible que pueda deducir solo de estos PID qué proceso está llenando su sistema de archivos. Busque los procesos con:
ps -ef | grep $pid
También puede intentar ejecutar este comando que le brindará aún más detalles (y le ayudará a identificar archivos abiertos sin un nombre de archivo correspondiente en el disco; mencioné esto anteriormente):
sudo lsof $file_system | grep $directory_filling_up
... y si ha identificado un PID sospechoso a partir del fusercomando, puede hacer esto:
sudo lsof -p $pid
El problema con fusery lsofes que solo le brindan una instantánea del sistema en el momento en que ejecuta el comando. Si el proceso ofensivo no está escribiendo cuando los ejecuta, no tendrá suerte. Puede contrarrestar esto ejecutándolos repetidamente a lo largo del tiempo y guardando el resultado. Esto requerirá leer el resultado para encontrar patrones o escribir un programa para que lo haga por usted. Una alternativa es utilizar una herramienta comoSistemaTap. SystemTap le permite capturar todo tipo de información útil y es "programable". Incluso viene con algunos archivos fuente de muestra que le permitirán ver qué procesos están escribiendo en qué archivos durante un período de tiempo. Sería perfecto, pero es una herramienta avanzada y requiere muchos conocimientos de Linux.
Una vez que haya identificado los procesos infractores, puede eliminarlos (y tal vez reiniciarlos). Si el proceso está asociado con el sistema operativo o algún software bien empaquetado, probablemente habrá un mecanismo para reiniciarlos, pero dependerá de tu distribución de Linux (creo que Ubuntu te permitirá ejecutar algo como /etc/init.d/$init_script restart, pero tendrás para consultar la documentación de tu distribución). De lo contrario, puedes matarlo con kill $pido kill -9 $pidsi no se comporta. Tenga cuidado de anotar cómo se estaba ejecutando el proceso (por ejemplo, cuáles fueron los argumentos que se muestran en ps -ef) en caso de que necesite reiniciarlo (es posible que deba consultar la documentación de ese software).
Respuesta2
Utilícelo dupara localizar el directorio que contiene los archivos que llenan el disco.
cd /
du -h --max-depth 1
le mostrará qué directorio en / utiliza más espacio. Recorra el sistema de archivos ejecutando el comando du para encontrar al culpable.
p.ej
cd /
du -h --max-depth 1
muestra que /usr está usando 2.3G de los 3.5G usados en el sistema.
cd /usr
du -h --max-depth 1
muestra que /usr/lib usa 1.1G de los 2.3 en /usr ...
Esto también puede deberse a un archivo abierto que se ha eliminado.
Puedes usarlsofpara buscar archivos que están abiertos pero desvinculados (eliminados)
lsof +L1
debería funcionar. Como dice la página de manual:
Una especificación del formulario
+L1seleccionará los archivos abiertos que hayan sido desvinculados. Una especificación del formulario+L1 <file_system>seleccionará archivos abiertos no vinculados en el sistema de archivos especificado.
Respuesta3
Algo está llenando la partición /. Probablemente sea algo en /var/log, o en /home. Esto depende de su configuración. Busque también en los lugares donde sus usuarios tienen acceso.
Ejecute el siguiente comando en cada uno de los directorios en cuestión. Esto le mostrará los subdirectorios que consumen más espacio.
cd /directory
du -cks -x * .* |sort -n
Esta idea está tomada del ducksguión ( du -cks) deHacks de servidores Linuxde O'Reilly. Ejecuto este comando a menudo.
En mi experiencia, esto casi siempre se debe a archivos de registro grandes y en crecimiento. En este caso, utiliceLogrotar, yasegúrese de usar compresión. Al utilizar la compresión gzip con la relación de compresión predeterminada, sus archivos de registro se reducirán entre un 80 y un 95 % (un /var/log/messages de 1 GB se puede comprimir fácilmente hasta 200 MB o menos). Esto supone una cantidad moderada de carga para la CPU, pero rara vez he visto que esto afecte el rendimiento real de un servidor. Algunas personas prefieren usar la compresión Bzip2, o usarla, gzip --bestpero en mi experiencia esto causa una gran sobrecarga de CPU con pocos beneficios adicionales. gzipcon la relación predeterminada suele ser bastante buena.
Y obviamente, este problema en ocasiones se debe a que un usuario hace cosas malas. Utilice el ducomando anterior para encontrar al culpable.
Respuesta4
El probable culpable son los registros, pero aquí hay un comando que ordenará los archivos modificados (o creados) recientemente por tamaño:
D=$(date --rfc-3339 date);
sudo sh -c 'find / -xdev -mtime -1 -type f -print0 |xargs -0 du -0sbc' \
|tee ~/recent-files.$D |sort -zn |tee ~/recent-by-size.$D |xargs -0n1
Podrías ejecutar este comando diariamente; Probablemente haya una manera de hacer algo similar a SQL para ordenar estos archivos por crecimiento diario.
(editar) Para monitorear el crecimiento, usegt5
sudo aptitude install gt5
cd /
gt5
Un día después; buscar signos ±
gt5