Hemos estado ejecutando un servidor en una VM en una empresa de alojamiento, y acabamos de suscribirnos a un host dedicado (AMD Opteron 3250, 4 núcleos, 8 GB de RAM, 2 x 1 TB en RAID de software, ext3).

Al ejecutar pruebas de rendimiento, notamos que algunas transiciones SQLite (combinación de inserciones, eliminaciones y / o actualizaciones) demoraban entre 10 y 15 veces más que en mi MacBook Pro 2010.

Después de mucho googlear y leer, pudimos ver las opciones de montaje, que fueron:

    data=ordered,barrier=1

Experimentamos un poco y obtuvimos el mejor rendimiento con

    data=writeback,barrier=0

He leído sobre estos y entiendo los conceptos básicos de lo que están haciendo, pero no tengo un buen sentido / sensación de si es una buena idea que corramos así.

Preguntas

¿Es razonable considerar la configuración anterior para un servicio alojado?

Si tuvimos un corte de energía, o un colapso, entonces podríamos terminar con la pérdida de datos o la corrupción de los archivos. Si tomáramos instantáneas de la base de datos cada 15 minutos, eso podría mitigar la situación, pero la base de datos podría no sincronizarse cuando se toma la instantánea. ¿Cómo deberíamos (podemos) asegurarnos de la integridad de tal instantánea?

¿Hay otras opciones que deberíamos considerar?

Gracias

Primer consejo
Si no puede permitirse perder ningún dato (quiero decir, una vez que un usuario ingresó nuevos datos, si eso no se puede perder en los próximos segundos) y debido a que no tiene algo como un UPS, entonces no eliminaría la barrera de escritura, tampoco cambiaría a reescritura.

Eliminación de barreras de escritura
Si elimina la barrera de escritura, entonces, en caso de bloqueo o pérdida de energía, el sistema de archivos necesitará hacer un fsck para reparar la estructura del disco (tenga en cuenta que incluso con la barrera activada, la mayoría de los sistemas de archivos de registro diario aún funcionarían) aunque la repetición de la revista debería haber sido suficiente). Al eliminar la barrera de escritura, es recomendable eliminar cualquier almacenamiento en caché de disco (en el hardware) si es posible, esto ayuda a minimizar el riesgo. Sin embargo, debe comparar el impacto de dicho cambio. Puede probar este comando (si su hardware lo admite) hdparm -W0 /dev/<your HDD>.
Tenga en cuenta que ext3 usa 2 barreras para el cambio de metadatos, mientras que ext4 usa solo una cuando usa la opción de montaje journal_async_commit.

Aunque Ted T'so explicó por qué ocurrieron algunos pocos daños en los datos en los primeros días de ext3 (las barreras estaban DESACTIVADAS de forma predeterminada hasta Kernel 3.1 ), el diario se coloca de una manera que a menos que ocurra un ajuste de registro del diario (el diario es un registro cíclico) los datos se escriben en el disco en un orden seguro , primero en el diario, segundo en los datos, incluso con el disco duro admite el reordenamiento de las escrituras.
Básicamente, sería desafortunado que se produzca un bloqueo del sistema o una pérdida de energía cuando se ajusta el registro del diario. Sin embargo, debes mantenerte data=ordered. Intenta hacer un benchmark con data=ordered,barrier=0además.

Si puede permitirse perder unos segundos de datos, puede activar ambas opciones data=writeback,barrier=0pero luego intentar experimentar con el commit=<nrsec>parámetro también. Consulte el manual de este parámetro aquí . Básicamente, le das una cantidad de segundos, que es un período en que el sistema de archivos ext3 sincronizará sus datos y metadatos.
También puede intentar tocar el violín y comparar con algunos parámetros ajustables del núcleo con respecto a las páginas sucias (aquellas que necesitan escribirse en el disco), aquí hay un buen artículo que explica todo acerca de estos parámetros ajustables y cómo jugar con ellos.

Resumen sobre barreras
Debe comparar algunas combinaciones más de sintonizables:

1. Usar data=writeback,barrier=0en conjunto conhdparm -W0 /dev/<your HDD>
2. Utilizar data=ordered,barrier=0
3. Úselo data=writeback,barrier=0junto con la otra opción de montaje commit=<nrsec>y pruebe diferentes valores para nrsec
4. Use la opción 3. e intente sintonizar aún más en el nivel del núcleo con respecto a las páginas sucias.
5. Use la caja fuerte data=ordered,barrier=1, pero pruebe otros sintonizables: especialmente el elevador del sistema de archivos (CFQ, Deadline o Noop) y sus respetables sintonizables.

Considerar pasar a ext4 y compararlo
Como se dijo, ext4 requiere menos barrera que ext3 para una escritura. Además, ext4 admite extensiones que para archivos grandes pueden brindar un mejor rendimiento. Por lo tanto, es una solución que vale la pena explorar, especialmente porque es fácil migrar de una ext3 a una ext4 sin reinstalar: documentación oficial ; Lo hice en un sistema pero usando esta guía de Debian . Ext4 es realmente estable desde el kernel 2.6.32, por lo que es seguro de usar en producción.

Última consideración
Esta respuesta está lejos de ser completa, pero le brinda suficientes materiales para comenzar a investigar. Esto depende tanto de los requisitos (a nivel del usuario o del sistema) que es difícil tener una respuesta directa, lo siento.

Advertencia: puede haber imprecisiones a continuación. He estado aprendiendo sobre muchas de estas cosas a medida que avanzo, así que tómalo con una pizca de sal. Esto es bastante largo, pero puedes leer los parámetros con los que estábamos jugando y luego saltar a la conclusión al final.

Hay varias capas en las que puede preocuparse por el rendimiento de escritura de SQLite:

Observamos los resaltados en negrita. Los parámetros particulares fueron

• Disco de caché de escritura. Los discos modernos tienen caché RAM que se utiliza para optimizar las escrituras del disco con respecto al disco giratorio. Con esto habilitado, los datos pueden escribirse en bloques desordenados, por lo que si ocurre un bloqueo, puede terminar con un archivo parcialmente escrito. Verifique la configuración con hdparm -W / dev / ... y configúrelo con hdparm -W1 / dev / ... (para encenderlo y -W0 para apagarlo).
• barrera = (0 | 1). Muchos comentarios en línea que dicen "si ejecuta con barrera = 0, entonces no tiene habilitado el almacenamiento en caché de escritura en disco". Puede encontrar un debate sobre las barreras en http://lwn.net/Articles/283161/
• datos = (diario | ordenado | reescritura). Consulte http://www.linuxtopia.org/HowToGuides/ext3JournalingFilesystem.html para obtener una descripción de estas opciones.
• commit = N. Le dice a ext3 que sincronice todos los datos y metadatos cada N segundos (predeterminado 5).
• Pragma SQLite sincrónico = ON | APAGADO. Cuando está activado, SQLite se asegurará de que una transacción se "escriba en el disco" antes de continuar. Desactivar esto esencialmente hace que las otras configuraciones sean irrelevantes.
• SQLite pragma cache_size. Controla la cantidad de memoria que SQLite usará para su caché en memoria. Intenté dos tamaños: uno en el que toda la base de datos cabría en la memoria caché y otra en la que la memoria caché era la mitad del tamaño máximo de la base de datos.

Lea más sobre las opciones de ext3 en la documentación de ext3 .

Realicé pruebas de rendimiento en varias combinaciones de estos parámetros. La ID es un número de escenario, mencionado a continuación.

Comencé ejecutando con la configuración predeterminada en mi máquina como escenario 1. El escenario 2 es lo que supongo que es el "más seguro", y luego probé varias combinaciones, según corresponda / solicitada. Esto es probablemente más fácil de entender con el mapa que terminé usando:

Escribí un script de prueba que ejecutaba muchas transacciones, con inserciones, actualizaciones y eliminaciones, todo en tablas con INTEGER, TEXT (con columna de identificación) o mixto. Ejecuté esto varias veces en cada una de las configuraciones anteriores:

Los dos escenarios inferiores son # 6 y # 17, que tienen "pragma synchronous = off", tan sorprendente que fueron los más rápidos. El siguiente grupo de tres son # 7, # 11 y # 19. Estos tres están resaltados en azul en el "mapa de configuración" anterior. Básicamente, la configuración es caché de escritura en disco activada, barrera = 0 y conjunto de datos en algo diferente a 'diario'. Cambiar la confirmación entre 5 segundos (# 7) y 60 segundos (# 11) parece hacer poca diferencia. En estas pruebas, no parecía haber mucha diferencia entre datos = ordenados y datos = reescritura, lo que me sorprendió.

La prueba de actualización mixta es el pico medio. Hay un grupo de escenarios que son claramente más lentos en esta prueba. Todos estos son con data = journal . De lo contrario, no hay mucho entre los otros escenarios.

Tuve otra prueba de tiempo, que hizo una mezcla más heterogénea de inserciones, actualizaciones y eliminaciones en las diferentes combinaciones de tipos. Estos tomaron mucho más tiempo, por lo que no lo incluí en el diagrama anterior:

Aquí puede ver que la configuración de reescritura (# 19) es un poco más lenta que las ordenadas (# 7 y # 11). Esperaba que la reescritura fuera un poco más rápida, pero tal vez depende de sus patrones de escritura, o tal vez todavía no he leído lo suficiente en ext3 :-)

Los diversos escenarios eran algo representativos de las operaciones realizadas por nuestra aplicación. Después de elegir una lista breve de escenarios, realizamos pruebas de tiempo con algunas de nuestras suites de pruebas automatizadas. Estaban en línea con los resultados anteriores.

Conclusión

• El parámetro commit parecía hacer poca diferencia, así que lo dejamos en 5s.
• Vamos con caché de escritura en disco, barrera = 0 , y datos = ordenados . Leí algunas cosas en línea que pensaban que esta era una mala configuración, y otras que parecían pensar que esto debería ser lo predeterminado en muchas situaciones. Supongo que lo más importante es que tome una decisión informada, sabiendo qué compensaciones está haciendo.
• No vamos a usar el pragma síncrono en SQLite.
• Establecer el pragma SQLite cache_size para que la base de datos encajara en la memoria mejoró el rendimiento en algunas operaciones, como esperábamos.
• La configuración anterior significa que estamos tomando un poco más de riesgo. Utilizaremos la API de copia de seguridad SQLite para minimizar el peligro de falla del disco en una escritura parcial: tomar una instantánea cada N minutos y mantener la última M alrededor. Probé esta API mientras ejecutaba pruebas de rendimiento, y nos dio confianza para seguir este camino.
• Si aún quisiéramos más, podríamos mirar a la basura con el núcleo, pero mejoramos las cosas lo suficiente sin tener que ir allí.

Gracias a @Huygens por varios consejos y sugerencias.