javascript - read - fs.writeFileSync da error: forma DESCONOCIDA y correcta de escribir un archivo sincrónico en nodejs

require(''fs'')

Question

Tengo una aplicación de servidor NodeJS. Tengo esta línea de código para mi registro:

fs.writeFileSync(__dirname + "/../../logs/download.html.xml", doc.toString());

Algunas veces funciona correctamente, pero bajo una gran carga da esta excepción:

Error: UNKNOWN, unknown error ''download.html.xml''

PD: Encontré un enlace aquí: http://www.daveeddy.com/2013/03/26/synchronous-file-io-in-nodejs/ Blogger describe que writeFileSync realmente no termina de escribir a la vuelta. ¿Hay alguna forma correcta de hacerlo de forma sincronizada, es decir, sin devoluciones?

Answer 1

Cuando haces una writeFileSync , obtienes un descriptor de archivo en el archivo. El sistema operativo limita el número de descriptores de archivos que se pueden abrir en un momento dado. Por lo tanto, bajo uso intensivo, en realidad puede estar llegando al límite. Una forma de averiguarlo es que este sea el caso de usar ulimit y establecerlo en ilimitado.

Otra posibilidad es errores IO. Por ejemplo, cerrar un descriptor de archivo fallará si se produce un error IO.

Answer 2

Para el OP parecía apreciar el comentario, lo puse en una respuesta con la esperanza de que ayudará a otros usuarios.

Me parece que el problema se debe al hecho de que muchos descriptores se writeFileSync llamar a writeFileSync . El enlace publicado en la pregunta parece confirmar la idea también.

En realidad, todavía estoy tratando de averiguar si existe una forma de saber cuándo la escritura está realmente terminada bajo el capó, no solo desde el punto de vista de nodejs. Tal vez este parámetro pueda ayudar, pero supongo que sufre del mismo problema.

De todos modos, uno puede evitar el problema mediante la implementación de un grupo de escritores con una cola en la que poner sus solicitudes de escritura.

El profesional es que la cantidad de descriptores abiertos se puede mantener bajo control. No exactamente, de hecho, debido al problema mencionado en el enlace publicado por el OP, pero, por supuesto, uno puede evitar agotar todos los recursos de un sistema.

Por otro lado, desafortunadamente, existe el problema de que esta solución tiende a ocupar mucha más memoria (ya que uno está estacionando allí sus documentos mientras espera a un trabajador disponible).

Por supuesto, podría ser una solución adecuada para la ráfaga de solicitudes separadas en el tiempo, pero tal vez no encaja bien con cargas fijas constantes en el tiempo.