J’essaie de démarrer un forum sur le Compute Engine de GCP, en l’exécutant sur un e2-micro. Je pense qu’un fichier swap de 2 Go a été créé lorsque j’ai essayé de l’exécuter pour la première fois.
10 Go n’ont pas fonctionné car c’était trop peu, si je me souviens bien, je l’ai donc augmenté à 20 Go.
Après avoir exécuté ./launcher rebuild app, il a commencé à faire son truc. Quand il faisait ...[@embroider/webpack, cela a pris tellement de temps que je suis parti et je suis revenu plus tard (~2h plus tard).
J’ai constaté que c’était terminé, mais je ne pouvais pas accéder à mon forum, même si j’avais connecté mon enregistrement A Namecheap à l’adresse IP externe de la VM.
J’ai réessayé, et voici les journaux complets (les journaux sont trop longs) : GCP e2-micro discourse logs.txt (176,7 Ko)
Et pourtant, mon site Discourse ne fonctionne pas. J’obtiens :
Réduire le nombre de travailleurs Unicorn à 1 dans containers/app.yml pour économiser de la mémoire, puis reconstruire l’application avec ./launcher rebuild app fonctionne-t-il par hasard ?
Ou vous pouvez temporairement mettre à niveau votre instance vers e2-small ou une version supérieure, terminer la reconstruction, puis la redimensionner à nouveau à e2-micro.
La reconstruction a déjà pris environ 2 heures. Je ne pense pas vouloir attendre aussi longtemps pour la 3ème fois.
Par ailleurs, mon e-mail ne fonctionne plus.
L’e-mail fonctionne maintenant, mais j’ai peur d’installer des plugins, car la reconstruction prendra environ 2 heures. Je sais que ce n’est pas normal, alors y a-t-il un moyen d’accélérer le processus sans changer les ressources de la VM ?
Ce pourrait être le cas. Si cela ne vous dérange pas que je vous demande, quelles sont les spécifications système du VP ?
Il y a assez longtemps maintenant. L’un des serveurs que je gère en tant que bénévole était sur un VP de base de 20 Go. Et même avec la taille de la base de données, cela ne prenait généralement qu’environ 15 minutes.
Finalement, le client a été contraint de migrer vers un serveur plus grand après qu’il ait planté sévèrement. À l’époque, ils n’ont pas tenu compte de mon indiquant que le serveur allait planter car il ne pouvait plus être reconstruit via la ligne de commande.
Ils ont donc payé un membre ici pour le déplacer vers un nouveau serveur avec un plan de 256 Go. Cela leur a coûté beaucoup d’interruptions de service, environ 2,5 semaines pour avoir ignoré le problème.
Le point positif est que, pour la plupart, ils écoutent mieux maintenant les lorsqu’ils sont donnés.
Je pense qu’il s’agit de 0,25 vCPU et 1 Go de RAM. La configuration a créé un fichier swap de 2 Go. Le serveur d’origine était livré avec 10 Go de stockage. Mais l’installation a indiqué qu’elle avait besoin de plus pour continuer car il restait environ 1,7 Go. J’ai donc augmenté à 20 Go et je n’ai pas encore vu d’avertissements liés au stockage.
indiquant que le serveur allait planter car il ne pouvait plus être reconstruit via la ligne de commande.