Problème création évènement

Bonjour,

J’ai un léger soucis à la création d’un évènement. Ca marchait plutôt pas mal mais suite à une erreur de ma part (voulu créé un let’s encrypt pour un autre domaine avec le script initial), j’ai relancé l’installation (mais pas de flush de base de donnée).

Capture

Merci,

Salut,
Regarde dans les logs serveur (/apps/fabmanager/log/app-stdout.log) pour avoir plus de détails sur l’erreur qui survient. Au besoin, tu peux nous poster le message ici pour qu’on t’aide à trouver d’où vient le problème.
Bonne journée

Bonjour, étrangement je n’ai plus de problème.

Par contre, là je viens de redémarrer l’app et elle met bien plus longtemps, notamment les

redis_1 | 1:M 16 Sep 06:28:38.044 * 100 changes in 300 seconds. Saving…
redis_1 | 1:M 16 Sep 06:28:38.266 * Background saving started by pid 13
redis_1 | 13:C 16 Sep 06:28:38.285 * DB saved on disk
redis_1 | 13:C 16 Sep 06:28:38.286 * RDB: 0 MB of memory used by copy-on-write
redis_1 | 1:M 16 Sep 06:28:38.369 * Background saving terminated with success

Merci,

Que veux-tu dire par « bien plus longtemps » ? Tu parles du temps de démarrage ou de la latence à l’utilisation ?
Note qu’il est normal que l’app mette au moins 15/20 secondes pour démarrer …

Les logs que tu a copiés n’indiquent rien de spécial, c’est le fonctionnement normal de redis. Tu peux néanmoins regarder dans sidekiq https://adressedufab/admin/sidekiq/ pour voir si un nombre anormal de tâches asynchrones s’exécutent et ralentissent l’application.

Edit : est-ce que, par hasard, tu rencontres un problème similaire à celui-ci ?

Pardon, c’est en effet quand je fais docker-compose up (sans le -d).

J’ai l’impression .

root@home:/apps/fabmanager# date
lundi 16 septembre 2019, 14:46:42 (UTC+0200)
root@home:/apps/fabmanager# docker-compose up

Puis postgres_1, redis_1, fabmanager_1 et elasticsearch_1 me causent… puis je perds patience :slight_smile:

J’ai arrêté:

root@home:/apps/fabmanager# date
lundi 16 septembre 2019, 14:50:25 (UTC+0200)

le docker-compose up -d est quand à lui super rapide ^^

root@home:/apps/fabmanager# date
lundi 16 septembre 2019, 14:51:53 (UTC+0200)
root@home:/apps/fabmanager# docker-compose up -d
Starting fabmanager_redis_1 … done
Starting fabmanager_postgres_1 … done
Starting fabmanager_elasticsearch_1 … done
Starting fabmanager_fabmanager_1 … done
Starting fabmanager_nginx_1 … done
root@home:/apps/fabmanager# date
lundi 16 septembre 2019, 14:52:02 (UTC+0200)

docker-compose up (sans le -d) lance l’application au premier plan, ça n’a pas d’intérêt dans le cas de fab-manager, il vaut mieux utiliser le -d et suivre les logs avec tail -f /apps/fabmanager/log/app-stdout.log (par exemple).

De quelle quantité de mémoire vive dispose ton serveur ? Elasticsearch est assez gourmand de ce côté là …

Bonjour et merci pour tes réponses :slight_smile:
En effet, un -d est bien plus rapide.

Voici l’outputs d’un top:

top - 10:17:13 up 4 days, 20:36, 1 user, load average: 0,10, 0,09, 0,03
Tasks: 128 total, 1 running, 89 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1,3 us, 0,7 sy, 0,0 ni, 98,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem : 1992188 total, 99896 free, 1348420 used, 543872 buff/cache
KiB Swap: 2097148 total, 2018556 free, 78592 used. 441632 avail Mem

Le htop me donne 1.30/1.90G de mémoire (j’ai pris l’offre de base d’OVH).

Merci :slight_smile:

Tout à l’air normal pour moi … Qu’il soit lent à démarrer ne devrait pas t’inquiéter, si c’est lent à l’utilisation, là par contre c’est plus gênant ! 2 Go de RAM + 2 Go de swap, c’est ce qu’on recommande pour un fab de taille standard, donc pas de soucis