He realizado una serie de actualizaciones y he decidido que la forma más fácil de solucionar los errores de memoria es duplicar el espacio de intercambio a 4 GB. La desventaja es que en una instancia de 1 GB solo hay 25 GB de SSD, por lo que perder 4 GB para el espacio de intercambio es una cantidad significativa de espacio, y ya es un poco ajustado con solo 25 GB.
Entonces, ¿deberíamos cambiar discourse-setup para que el valor predeterminado sea 3 GB?
¿Qué opinas, @Falco?
Si eso soluciona el problema, estoy totalmente a favor.
¿Puedo sugerir encarecidamente que el script de instalación también establezca los dos parámetros ajustables del kernel que afectan el manejo de la memoria? Sería bueno saber que todos los que aparentemente tienen un problema tienen al menos un punto de partida de una buena configuración del kernel.
Me parece una idea sensata. No me imagino dónde los THP podrían ser valiosos en una instancia de discourse dedicada, y el overcommit puede ayudar a evitar OOM.
¿Podrías considerar ofrecer hacer cada una de estas cosas por separado, estableciéndolas como respuesta predeterminada, con la opción no predeterminada de optar por no participar?
Además, el script puede usar sysctl para averiguar si la configuración necesita ser cambiada en primer lugar antes de hacer un cambio. Si alguien ya ha hecho estos cambios con archivos diferentes, sería potencialmente confuso crear anulaciones duplicadas. Creo que no todas las distribuciones de Linux vienen con la memoria overcommit desactivada en primer lugar.
if $(sysctl -n vm.overcommit_memory) != 1 ; then
....
fi
A riesgo de diluir el importante mensaje sobre los parámetros ajustables del kernel, existe una segunda consideración: el script actual solo crea swap en una máquina con poca RAM. Creo que es un error, tanto porque la swap sigue siendo útil para maximizar la utilidad de la RAM, sino, lo que es más importante, porque causará problemas si alguien crea su Discourse en una máquina con mucha RAM, por velocidad o conveniencia, y luego la reduce a una máquina con poca RAM.
La configuración debería crear swap en todos los casos (a menos que ya haya suficiente). Es válido y a veces útil tener varios archivos de swap.
No soy quien decide, y yo configuro estas cosas en las máquinas que configuro, pero este es un script de shell que ejecutan (la mayoría) todos los que instalan Discourse. Debe ser lo más simple posible, ¿y estamos seguros de que esas configuraciones funcionan en Raspberry Pi y Mac y en cualquier otra tontería que la gente intente hacer? ¿Y cualquier método que utilices para comprobar si ya está configurado funciona en todas esas plataformas? Parece difícil.
Escribí discourse-setup y me da un poco de miedo hacerle cambios.
Ofrecer siempre crear swap no es una mala idea. ¿Quizás ofrecer siempre crear 3 o 4 GB de swap? Pero, ¿cuánto entonces? Una regla general que una vez conocí era tener el swap del mismo tamaño que la RAM. Y ahora mismo, si no creas swap, tu única opción es salir con control-c. Así que o vamos a obligar a la gente a crear swap o añadiremos otra pregunta de S/N (¡lo que me hará modificar mis scripts que ejecutan discourse-setup 
). ¡Oh! O podemos hacer que se controle con un interruptor --skip-swap. Eso me parece bien. Si eres lo suficientemente inteligente como para saber sobre swap, puedes encontrar el interruptor para omitirlo; podemos agregar una nota sobre el interruptor en ese mensaje de ADVERTENCIA.
Y tal vez también agregar una nota sobre --skip-connection-test cuando falle.
Creo que si ya tienen swap configurado, es seguro asumir que saben lo que están haciendo.
¡Gracias! Y sí, lo entiendo perfectamente, yo sentiría lo mismo. Requiere una reflexión y pruebas cuidadosas, sin duda. Y eso sería en al menos un par de máquinas baratas de proveedores de hosting, y también en Raspberry Pi. No estoy seguro sobre Windows o Mac; si se espera que sean compatibles, entonces supongo que sí. Esperaría que se usaran más como máquinas de desarrollo, que es una historia diferente.
Exacto. Lo que parezca necesario en este momento, quizás. Parece que ha dado un paso adelante. Pero me duele mucho no saber si estos informes incluyen o no el ajuste de overcommit. Estoy bastante seguro de que sabemos por discusiones anteriores que el overcommit marca la diferencia.
Y sabemos que en una instancia de 25G y más aún en una de 20G el espacio en disco es limitado. Estoy ejecutando en máquinas así: disco de 25G y 1G de RAM, que ya necesita 2G de swap y probablemente más hoy en día; y disco de 20G con 2G de RAM donde actualmente tengo 1G de swap.
No recomendaría más preguntas de Sí/No. Las opciones de línea de comandos parecen una mejor ruta.
Si vamos a cambiar este script, creo que recomendaría varios swapfiles de 1G, porque eso maximiza la flexibilidad, no desperdicia nada y es el momento más fácil para tomar esa decisión.
No estoy tan seguro de esto. Si la instancia más pequeña con Ubuntu o Debian “naked” ya tiene algo de swap —esto habría que comprobarlo—, entonces empezamos a tener problemas si no es suficiente. Mucho mejor medir RAM+swap usando free, ajustar como de costumbre para las configuraciones por debajo de 1G que existen (AWS creo, quizás Oracle), y luego añadir swapfiles de 1G hasta un número acordado, el que sea en este momento. Con suerte, un total de 4G es suficiente, con el overcommit del kernel configurado adecuadamente.
Estaré encantado de ayudar.
Hmm. Sí. Ojalá hubiera pensado en comprobar eso en los que acabo de ajustar.
Hmm. Pienso que uno es mejor, pero múltiples añaden flexibilidad y entonces sería posible hacer que discourse-setup añada otro archivo de intercambio si se necesita más intercambio, lo que significa que podríamos decirle a todos que ejecuten discourse-setup para “solucionar” su problema de intercambio. Y tal vez también el problema del overcommit, tal vez intentar explícitamente hacerlo solo para Linux, ya que es lo único que nos importa.
No estoy de acuerdo. El swap no es un bien universal. Solía ser importante para hacer que el código de la VM fuera más uniforme cuando no se intercambiaba en ciertas circunstancias, pero los algoritmos de la VM han cambiado.
Eso se basaba en heurísticas de código de kernel muy antiguas que ya no se aplican.
Además, al considerar la medición: ni siquiera sé qué querrías hacer para medir el swap y la memoria cuando se usa zswap. Sin embargo, este es probablemente un caso de “primero no hacer daño”.
Estoy bastante seguro de que la única desventaja de “demasiado swap” es usar más espacio en disco del absolutamente necesario. Es una razón por la que sería preferible tener varios swapfiles de tamaño modesto: se puede hacer swapoff y eliminarlos progresivamente, si hay necesidad de recuperar el espacio en disco. Además, creo que Linux hace un trabajo razonable al usarlos progresivamente:
NAME TYPE SIZE USED PRIO
/var/local/swap/swapfile.1 file 1024M 863.6M -2
/var/local/swap/swapfile.0 file 1024M 4.6M -3
La situación en la que nos encontramos es que las instancias baratas están bastante limitadas tanto en RAM como en espacio en disco, y Discourse utiliza cada vez más, a medida que evolucionan los muchos paquetes que contiene. Pero aun así, creo que hay formas de navegar esto sabiamente, para ayudar a aquellos que no están en posición de simplemente rendirse y duplicar o cuadruplicar su factura mensual.
El intercambio es lo suficientemente lento como para que no tomaría “apenas queda espacio ahora” como una razón para agregar más de 1 GB a la sugerencia predeterminada en este momento. Cada 1 GB es una gran cantidad de intercambio, como se experimentó en una instancia dedicada de Discourse.
Sí, por defecto Linux usa el intercambio en orden de prioridad, y es posible usar la misma prioridad en varios dispositivos para dividir explícitamente el intercambio. Pero agregar mucho intercambio para sitios pequeños no es particularmente valioso, sugeriría.
Entonces, si después de aproximadamente una década la gente solo se topa ocasionalmente con 2 GB, sugeriría pasar a 3 GB en lugar de 4 GB como predeterminado. Y la cantidad necesaria de intercambio para una instancia dedicada de Discourse no debería aumentar particularmente con la memoria, porque el contenido que realmente se intercambiaría no cambia particularmente mucho.
La idea de aumentar el intercambio con más memoria proviene principalmente de la computación de propósito general, basada en una suposición generalizada de que cuanto más RAM necesites, mayor será la demanda probable. Pero la presión de intercambio en una instancia especializada de Discourse no es probable que siga ese patrón, creo.
THP son específicos de las plataformas que admiten páginas grandes, que no son todas las plataformas. La forma genérica de manejar eso es ver si existe. En una Raspberry Pi que tengo:
$ sysctl sys.kernel.mm.transparent_hugepage.enabled
sysctl: cannot stat /proc/sys/sys/kernel/mm/transparent_hugepage/enabled: No such file or directory
$ echo $?
255
En contraste, el overcommit es un parámetro general de VM para Linux desde hace algunas décadas. En la misma Raspberry Pi:
$ sysctl vm.overcommit_memory
vm.overcommit_memory = 0
Analizar la salida de free en shell es un poco complicado. Hablando como el autor original de procps, para esto simplemente buscaría SwapFree en /proc/meminfo. 
Estoy de acuerdo en que en nuestros mundos con restricciones de costos, escalar el intercambio por tamaño de RAM ya no es un buen plan. La siguiente idea históricamente parece haber sido que la RAM es enorme y no necesitas intercambio. Después de eso viene la sabiduría de que algo de intercambio es útil porque permite un mejor uso de la RAM. (En un mundo sin restricciones, simplemente tenemos enormes cantidades de RAM, pero eso es un nicho).
Lo que estamos viendo en los últimos dos meses es que más personas tienen problemas de falta de memoria y fallas en la reconstrucción. Más personas encuentran que las actualizaciones web fallan, pero la línea de comandos funciona. Desde una perspectiva de soporte simple, y desde la perspectiva de la reputación del producto, creo que necesitamos un cambio en el consejo habitual y la configuración habitual. Creo que 3G de intercambio es el cambio más simple y pequeño y deberíamos hacerlo si no hacemos nada más.
Pero todavía creo que múltiples archivos de intercambio más pequeños es una opción más sabia, y hemos visto hilos de soporte aquí que apuntan a eso. Y todavía creo que sería mejor tratar de dimensionar RAM + intercambio porque ese es el factor limitante, lo que causa problemas a las personas. Puede que haya diferentes formas de hacer ese cálculo. Se aplican las advertencias habituales sobre qué tácticas son mantenibles, comprensibles y tendrán longevidad.
En cuanto a las páginas grandes transparentes, entiendo que es lo “transparente” lo que causa problemas: el kernel puede esforzarse, fusionando y desfusionando, con una penalización de rendimiento y sin grandes beneficios. Estoy bastante seguro de que las páginas grandes están desaconsejadas para sistemas más pequeños.
Se trata más de las características de la carga de trabajo que del tamaño del sistema. En un sistema con 1 GB de RAM y procesos bastante estables con fragmentos de RAM, las hugepages predeterminadas de 2 MB pueden reducir el thrashing de la TLB y mejorar el rendimiento; la TLB no empieza a cubrir las asignaciones de 1 GB de RAM. Generalmente es solo una compensación entre la CPU que se dedica a buscar memoria para agrupar y las fallas de caché de la TLB, y hay muchas cargas de trabajo en máquinas de 1 GB que pueden beneficiarse considerablemente de THP. (Muchas recomendaciones para deshabilitarlo provienen del principio de su implementación; ha sido mejorado sustancialmente desde entonces). La recomendación de deshabilitar THP para Discourse no se debe al tamaño de 1 GB de RAM, sino que es específica para usar redis con persistencia en disco, que es algo que Discourse utiliza:
https://redis.io/docs/management/optimization/latency/#latency-induced-by-transparent-huge-pages
Desafortunadamente, cuando un kernel de Linux tiene habilitadas las páginas enormes transparentes, Redis incurre en una gran penalización de latencia después de que se utiliza la llamada
forkpara persistir en disco. Las páginas enormes son la causa del siguiente problema:
…