Server crashes

[fcladera]

Dejé el server corriendo toda una noche. Cuando traté de entrar esta mañana obtuve lo siguiente

Error: connect ECONNREFUSED
  <<< async stack >>>
  at GraphDatabase_prototype__getRoot__1 (lib/GraphDatabase._coffee:81:34)
  at GraphDatabase_prototype_getServices__2 (lib/GraphDatabase._coffee:104:21)
  at GraphDatabase_prototype_query__20 (lib/GraphDatabase._coffee:712:25)
  <<< raw stack >>>
    at errnoException (net.js:901:11)
    at Object.afterConnect [as oncomplete] (net.js:892:19)
worker 478 died

[fcladera]

Puede que tenga que ver con que nos quedamos sin RAM en el server. Este es el log de neo4j.

#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 12288 bytes for committing reserved memory.
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (os_linux.cpp:2827), pid=117, tid=140370668144384
#
# JRE version: OpenJDK Runtime Environment (7.0_95) (build 1.7.0_95-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.95-b01 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 2.6.4
# Distribution: Ubuntu 15.10, package 7u95-2.6.4-0ubuntu0.15.10.1

[fcladera]

Tenemos un memory footprint muy grande, causado principalmente por Firefox que queda siempre corriendo en el servidor. Me parece que al ejecutar grunt watch, Firefox queda siempre corriendo en el container con Xvfb, algo que no tiene lógica (salvo que se realice unit testing a cada cambio que se haga en los archivos del server). Esto es así? Propongo lo siguiente:

• En las imgs Docker que se ejecutan en los servidores, incluso si son dev, que el entrypoint sea grunt express para evitar la carga de Firefox.
• Que de alguna manera, tengamos un grunt watch que mate el proceso de Firefox después de hacer el unit testing. No tiene sentido que en un container headless tengamos corriendo un proceso de Firefox permanentemente (si tiene sentido si está "en nativo" porque recarga la página en tiempo real).

[andresmanelli]

Si, de hecho grunt watch tiene que ejecutarse solo para desarrollo, no en producción. Para producción deberia ser (creo):

• grunt compile
• node server/server.js

Esto es porque grunt build no hace el uglify ni el minify de archivos, justalente para poder saber la linea que nos da error en un trace. Compile deja todos los archivos lo mas comprimido posible degun tengo entendido, listo para producción. Una vez que se compila, grunt ya no sería necesario para correr el server. Porque no se necesitan más sus tasks

[andresmanelli]

Aclaro que no probé si esto anda bien. Hay unos temas con la forma se escribir javascript en angular que Hay que respetar para que el minify funcione y no estoy seguro de que esté hecho

[andresmanelli]

Asique habría que probar

• grunt build
• node server/server.js

[andresmanelli]

Correr la BDD fuera de docker traería alguna ventaja?

[fcladera]

Correr la db fuera de docker serviría, pero no por el momento.

En realidad creo que me expresé mal. No quiero algo para producción, el watch es genial porque recompila las cosas a medida de que se cambian. Pero lo que no quiero es que lance la instancia del navegador una vez que termina de recompilar. Me haría falta un

grunt watch:nobrowser

[andresmanelli]

Voy a probar en un rato PhantomJS (headless web browser) en karma con karma-phantomjs-launcher.

Parece que Travis lo soporta nativamente y no haría falta instalar xvfb ( Ver acá )

[fcladera]

Correr la db fuera de docker serviría, pero no por el momento.

En realidad creo que me expresé mal. No quiero algo para producción, el watch es genial porque recompila las cosas a medida de que se cambian. Pero lo que no quiero es que lance la instancia del navegador una vez que termina de recompilar (o que si levanta el browser para hacer unit testing, lo pare después). Me haría falta un

grunt watch:nobrowser

[andresmanelli]

Fijate #110 . Cambié la configuración de karma para que lo lance cada vez que hace unit testing. Y aparte lo cambié por PhantomJS. Si quieren seguir con firefox, elimino ese commit.

[fcladera]

Para mi es mejor no tener Firefox. Los unit test funcionan igual, son transparentes independientemente del browser?

[andresmanelli]

Van a funcionar igual por el momento porque nuestros tests (los pocos que hay) son de funcionamiento del código js, no de interacción en el navegador digamos. Hay bibliotecas para hacer eso creo, @francoa me decía que hacías clicks específicos y veías cómo respondía la vista. Sinceramente no sé si se puede hacer eso en PhantomJS, capaz que sí.

De todas maneras por lo pronto si te hace feliz, dejemos PhantomJS

[francoa]

Che Fer, y probaste con esto?:

Remember to set the number of allowed open files to 40000 or more. Read the Linux performance guide of Neo4J for details

Porque por defecto son pocos los archivos con que está configurado neo. Aunque si no estuviste haciendo nada durante la noche no debería joder.

[fcladera]

No lo he hecho lo de los archivos, pero en teoría no es eso. Es que nos estamos quedando sin memoria porque otros procesos se la acaparan, y neo4j se queda sin. Igual también habría que abrir un issue para arreglar lo open files en neo4j (en el dockerfile), pero no arreglaría este problema.

Yo creo que cuando tengamos phantomjs las cosas van a mejorar. Además voy a crear un archivo de swap en la máquina virtual para que no se muera si se queda sin memoria.

[fcladera]

Cierro esto, no hay mucho más para hacer en el tema.