Tengo un directorio con ~2 millones de enlaces simbólicos que apuntan a archivos reales en la misma unidad, que es un disco duro local real (no es un montaje de red). Todos los nombres de los archivos son únicos y los archivos a los que apuntan están dispersos en diferentes directorios, pero todos comparten la misma ruta principal. Estoy consolidando archivos en varios directorios mediante enlaces simbólicos.
/some/full/path/consolidated/my_file -> /some/full/path/mydir2/my_file
/some/full/path/consolidated/my_file2 -> /some/full/path/mydir3/my_file2
/some/full/path/consolidated/my_file3 -> /some/full/path/mydir4/my_file3
/some/full/path/consolidated/my_file4 -> /some/full/path/mydir4/my_file4
/some/full/path/consolidated/my_file5 -> /some/full/path/mydir2/my_file5
/some/full/path/consolidated/my_file6 -> /some/full/path/mydir3/my_file6
Se garantiza que los enlaces simbólicos no se romperán.
El problema es ese
time find "/some/full/path/consolidated/" -maxdepth 1 -type l -print > /tmp/foo
termina rápidamente:
1.24 user 0.83 system 0:02.08elapsed
Sin embargo,
time find -L "/some/full/path/consolidated/" -maxdepth 1 -type f -print > /tmp/foo
seguido por
watch wc -l /tmp/foo
muestra que llega a ~660.000 líneas muy rápidamente y luego se detiene, añadiendo unos cuantos miles de resultados de vez en cuando.
¿Por qué podría detenerse? ¿Y es posible hacer que el segundo comando sea tan rápido como el primero?
Editar:
/tmpno aparece en mountabsoluto (así que supongo que no es un tmpfs). Según htop no tengo poca memoria; Tengo unos 50 GB libres. El uso de CPU también es bajo. Para find -L path, que se detiene, /tmp/fooocupa aproximadamente 90 MB cuando se produce la desaceleración. Para find path, que no se detiene, /tmp/fooson 111 MB.
Tengo la misma desaceleración al redirigir la salida a ~/foo.
Editar: al observar iotop, find -Lmuestra una E/S del 99,99%, pero solo después de unos 10 segundos, que es mucho después de que findterminaría lo normal.
Respuesta1
intenta aumentar tu caché de inodo con
echo 50 | sudo tee /proc/sys/vm/vfs_cache_pressure
el valor 100 es promedio, valores más bajos = inodo más grande + caché de dentría
desventaja: un caché más grandepuede ser más lento, por lo que también puedes intentar disminuir tu caché con
echo 200 | sudo tee /proc/sys/vm/vfs_cache_pressure
o puede utilizar una lista de archivos en caché con
sudo updatedb
locate /some/full/path/consolidated
También esté atento al uso de inodos, los enlaces simbólicos ocupan inodos (también los enlaces físicos)
df -i
relacionado:https://serverfault.com/questions/338097/tuning-linux-cache-settings-for-inode-caching
más sobre el ajuste del disco:https://unix.stackexchange.com/questions/30286/can-i-configure-my-linux-system-for-more-aggressive-file-system-caching/41831