Tengo un script que crea muchos archivos y directorios. El script realiza pruebas de caja negra para un programa que funciona con muchos archivos y directorios. El recuento de pruebas aumentó y las pruebas tardaban demasiado (más de 2 segundos). Pensé en ejecutar las pruebas en un disco RAM.
Hice la prueba en /dev/shm. Curiosamente no corrió más rápido. El tiempo de ejecución promedio fue aproximadamente el mismo que en el disco duro normal. También lo intenté en undisco ram basado en fusible escrito en perl. El sitio web desapareció pero lo encontré en elarchivo de internet. El tiempo de ejecución promedio en el disco del ariete fusible es aún más lento. Quizás debido a la implementación subóptima del código Perl.
Aquí hay una versión simplificada de mi script:
#! /bin/sh
preparedir() {
mkdir foo
mkdir bar
touch bar/file
mkdir bar/baz
echo qux > bar/baz/file
}
systemundertest() {
# here is the black box program that i am testing
# i do not know what it does exactly
# but it must be reading the files
# since it behaves differently based on them
find $1 -type f -execdir cat '{}' \; > /dev/null
singletest() {
mkdir actual
(cd actual; preparedir)
systemundertest actual
mkdir expected
(cd expected; preparedir)
diff -qr actual expected
}
manytests() {
while read dirname; do
rm -rf $dirname
mkdir $dirname
(cd $dirname; singletest)
done
}
seq 100 | manytests
El script real realiza un poco más de verificación de errores y recopilación de resultados y un resumen. Es findun modelo ficticio para el programa real que estoy probando.
Me pregunto por qué el script de mi sistema de archivos intensivo no se ejecuta más rápido en un sistema de archivos respaldado por memoria. ¿Es porque el kernel de Linux maneja el caché del sistema de archivos de manera tan eficiente que prácticamente es un sistema de archivos respaldado por memoria?
Respuesta1
En términos generales, todas las operaciones se realizan primero en la RAM: los sistemas de archivos se almacenan en caché. Hay excepciones a esta regla, pero estos casos bastante especiales suelen surgir de requisitos bastante específicos. Por lo tanto, hasta que comience a vaciar el caché, no podrá notar la diferencia.
Otra cosa es que el rendimiento dependemuchoen el sistema de archivos exacto: algunos apuntan a un acceso más fácil a grandes cantidades de archivos pequeños, algunos son eficientes en transferencias de datos en tiempo real hacia y desde archivos grandes (captura/transmisión multimedia), algunos enfatizan la coherencia de los datos y otros pueden diseñarse para tener pequeña huella de memoria/código.
Volviendo a su caso de uso: en una sola pasada de bucle genera alrededor de 20 procesos nuevos, la mayoría de los cuales simplemente crean un directorio/archivo (tenga en cuenta que ()crea un sub-shell y findgenera catpara cada coincidencia); el cuello de botella de hecho no es el sistema de archivos (y si su sistema utilizaASLRy no tiene una buena fuente rápida de entropía (el grupo de aleatoriedad de su sistema también se agota bastante rápido). Lo mismo ocurre con FUSE escrito en Perl: no es la herramienta adecuada para el trabajo.
Respuesta2
Una respuesta algo más larga que mi comentario acerca de que las pruebas se componen principalmente de pequeñas transacciones.
Carga de trabajo insuficiente para realizar la prueba
Si desea probar su sistema de archivos, necesitará conjuntos de trabajo más grandes.
Dependiendo de la cantidad de memoria que tenga en su caja, incluso decenas de miles de operaciones de creación de carpetas no mostrarán una diferencia notable entre las dos. Por lo tanto, modifique su carga de trabajo para probar suficientemente los sistemas de archivos, teniendo en cuenta su memoria, que se utilizará como búfer.
Hay una variedad de formas de diseñar una prueba que anule los beneficios de la memoria RAM de su sistema y otros factores que distorsionarán los resultados de la prueba.
O puede utilizar un conjunto de pruebas estandarizado, como bonnie++