C programa atascado en espera ininterrumpida durante la ejecución de E/S de disco en Mac OS X Snow Leopard

Question

Una línea de fondo: soy el desarrollador de Redis, a NoSQL database. Una de las nuevas funciones que estoy implementando es la memoria virtual, porque Redis toma todos los datos en la memoria. Gracias a VM Redis es capaz de transferir objetos raramente usados ​​de la memoria al disco, hay varias razones por las que esto funciona mucho mejor que dejar que el sistema operativo haga el trabajo por nosotros intercambiando (los objetos redis están construidos con muchos objetos pequeños asignados en no contiguos lugares, cuando Redis los serializa en disco, toman 10 veces menos espacio en comparación con las páginas de memoria donde viven, y así sucesivamente).

Ahora tengo una implementación alfa que funciona perfectamente en Linux, pero no tan bien en Mac OS X Snow Leopard. De vez en cuando, mientras Redis intenta mover una página de la memoria al disco, el proceso de redis ingresa en el estado de espera ininterrumpida durante minutos. No pude depurar esto, pero esto sucede en una llamada al fseeko() o al fwrite(). Después de unos minutos, la llamada finalmente vuelve y redis continúa funcionando sin problemas: no se bloquea.

La cantidad de datos transferidos es muy pequeño, algo así como 256 bytes. Por lo tanto, no debería tratarse de una gran cantidad de E/S realizadas.

Pero hay un detalle interesante sobre el archivo de intercambio que es el objetivo de la operación de escritura. Es un archivo grande (26 Gigabytes) creado abriendo un archivo con fopen() y luego ampliado con ftruncate(). Finalmente, el archivo es unlink() ed para que Redis continúe tomando una referencia al mismo, pero estamos seguros de que cuando el proceso Redis salga, el sistema operativo realmente liberará el archivo de intercambio.

Ok, eso es todo, pero estoy aquí para más detalles. Y por cierto, incluso puedes encontrar el código real en Redis git, pero no es trivial entenderlo en cinco minutos dado que es un sistema bastante complejo.

Muchas gracias por cualquier ayuda.

Answer 1

Como lo entiendo, HFS + tiene muy poco apoyo para los archivos dispersos. Por lo tanto, es posible que su escritura active una expansión de archivo que esté inicializando/materializando una gran fracción del archivo.

Por ejemplo, sé que mapear un nuevo archivo vacío grande y luego escribir en algunas ubicaciones aleatorias produce un archivo muy grande en el disco con HFS +. Es bastante molesto ya que mmap y los archivos dispersos son una forma extremadamente conveniente de trabajar con datos, y prácticamente cualquier otra plataforma/sistema de archivos maneja esto con gracia.

¿El archivo de intercambio está escrito de forma lineal? ¿Quiere decir que reemplazamos un bloque existente o escribimos un nuevo bloque al final e incrementamos un puntero de espacio libre?Si es así, quizás hacer llamadas ftruncate más frecuentes para expandir el archivo resultaría en pausas más cortas.

Como nota aparte, me llama la atención por qué Redis VM no usa mmap y luego simplemente mueve bloques en un intento de concentrar los bloques calientes en las páginas calientes.

Answer 2

¿Ha desactivado el almacenamiento en caché de archivos para su archivo? es decir fcntl (fd, F_GLOBAL_NOCACHE, 1)

Answer 3

Como dijo Linus una vez en la lista de correo de Git:

"Soy consciente de que la gente OS X tienen dificultades para aceptar, pero OS X sistemas de ficheros son generalmente total y basura total, incluso más que Windows ".

Answer 4

¿Ha intentado depurar con DTrace and o Instruments (frente experimental Dtrace de Apple)?

Exploring Leopard with DTrace

Debugging Chrome on OS X

Answer 5

antirez, no estoy seguro de que seré de mucha ayuda ya que mi experiencia con Apple se limita al Apple ][, pero lo intentaré.

Lo primero es una pregunta. Pensaría que, para la memoria virtual, la velocidad de operación sería una medida más importante que el espacio en disco (especialmente para un DB NoSQL donde la velocidad es el punto, de lo contrario estarías usando SQL, ¿no?). Pero, si su archivo de intercambio es 26G, tal vez no :-)

Algunas cosas que debe probar (si es posible).

1. Trate de aislar realmente el problema al buscar o escribir. Me cuesta mucho creer que una búsqueda podría tomar tanto tiempo, ya que, en el peor de los casos, debería ser un cambio de puntero del buffer. Aún así, no escribí OSX, así que no puedo estar seguro.
2. Intenta ajustar el tamaño del archivo de intercambio para ver si eso es lo que está causando el problema.
3. ¿Alguna vez amplió dinámicamente el archivo de intercambio (en lugar de la preasignación)? Si lo haces, eso puede ser lo que está causando el problema.
4. ¿Siempre escribe lo más bajo que pueda en el archivo? Puede ser que la creación de un archivo 26G no llene realmente los datos, pero si lo crea y escribe en el último byte, el sistema operativo puede tener que poner a cero los bytes antes de eso (posponiendo la inicialización, si corresponde).
5. ¿Qué sucede si solo asigna previamente el archivo completo (escribe en cada byte) y no lo desenlaza? En otras palabras, deja el archivo allí entre las ejecuciones de tu programa (creándolo si no existe ya, por supuesto). Luego, en su código de inicio para Redis, simplemente inicialice el archivo (punteros y demás). Esto puede eliminar cualquier problema como los del punto 4 anterior.
6. Pregunte en los diferentes sitios de BSD también. No estoy seguro de cuánto cambió Apple bajo las sábanas, pero OSX es solo BSD en el nivel más bajo (patos Pax para cubrir).
7. También considere pedir en los sitios de Apple (si aún no lo ha hecho).

Bueno, esa es mi pequeña contribución, espero que ayude. Buena suerte con tu proyecto.