Question L'application Meteor déployée sur Digital Ocean bloquée à 100% du CPU et du MOO


J'ai une application Meteor (0.8.0) déployée à l'aide de Meteor Up to Digital Ocean qui a été bloquée à 100% du processeur, mais qui s'est écrasée avec une mémoire insuffisante, et a redémarré à 100% du processeur. Il a été bloqué comme ça depuis 24 heures. La partie étrange est que personne n'utilise le serveur et meteor.log ne montre pas beaucoup d'indices. J'ai MongoHQ avec oplog pour la base de données.

Spécifications de l'océan numérique:

1 Go de disque SSD Ram de 30 Go New York 2 Ubuntu 12.04.3 x64

Capture d'écran montrant le problème:

enter image description here

Notez que la capture d'écran a été capturée hier et qu'elle est restée fixée à 100% du processeur jusqu'à ce qu'il se bloque avec un manque de mémoire. Le journal indique:

FATAL ERROR: Échec de l'allocation d'évacuation - processus hors mémoire   erreur: le script détecté a été tué par le signal: erreur SIGABRT:   Redémarrage du script pour 5 fois

Les affichages supérieurs:

26308 météores 20 0 1573m 644m 4200 R 98.1 64.7 32: 45.36 nœud

Comment ça a commencé: J'ai une application qui prend une liste de courriels via csv ou mailchimp oauth, les envoie à fullcontact via leur appel de traitement par lots http://www.fullcontact.com/developer/docs/batch/ puis met à jour les collections Meteor en fonction du statut de la réponse. Un extrait d'une réponse 200

if (result.statusCode === 200) {
            var data = JSON.parse(result.content);
            var rate_limit = result.headers['x-rate-limit-limit'];
            var rate_limit_remaining = result.headers['x-rate-limit-remaining'];
            var rate_limit_reset = result.headers['x-rate-limit-reset'];
            console.log(rate_limit);
            console.log(rate_limit_remaining);
            console.log(rate_limit_reset);
            _.each(data.responses, function(resp, key) {
                var email = key.split('=')[1];
                if (resp.status === 200) {
                    var sel = {
                        email: email,
                        listId: listId
                    };
                    Profiles.upsert({
                        email: email,
                        listId: listId
                    }, {
                        $set: sel
                    }, function(err, result) {
                        if (!err) {
                            console.log("Upsert ", result);
                            fullContactSave(resp, email, listId, Meteor.userId());                            
                        }
                    });
                    RawCsv.update({
                        email: email,
                        listId: listId
                    }, {
                        $set: {
                            processed: true,
                            status: 200,
                            updated_at: new Date().getTime()
                        }
                    }, {
                        multi: true
                    });
                }
                });
                }

Localement, sur mon ordinateur portable Windows, exécutant Vagrant, je n'ai aucun problème de performance à traiter des centaines de milliers d'e-mails à la fois. Mais sur Digital Ocean, il ne peut même pas gérer 15 000, semble-t-il (j'ai vu le pic du processeur à 100%, puis le crash avec MOO, mais après, il se stabilise ... pas cette fois). Ce qui m'inquiète, c'est que le serveur n'a pas du tout récupéré malgré une activité minime sur l'application. Je l'ai vérifié en examinant les analyses - GA montre 9 sessions au total sur 24 heures, ne faisant rien de plus que de frapper / rebondir, MixPanel affiche seulement 1 utilisateur connecté (moi) dans la même période. Et la seule chose que j'ai faite depuis l’échec initial est de vérifier la facts paquet, qui montre:

multipongeurs d'observations mongo-pyreata 13 observe-drivers-oplog 13

oplog-watchers 16 observe-manipule 15 temps passé en phase de QUERYING

87828 temps passé en phase FETCHING 82 corps

invalidation-crossbar-listeners 16 abonnements 11 sessions 1

Meteor APM ne montre rien non plus, le meteor.log ne montre aucune activité météorite en dehors du MOO et des messages de redémarrage. MongoHQ ne signale aucune requête lente ou activité importante - 0 requêtes, mises à jour, insertions, suppressions sur avg de regarder leur tableau de bord de surveillance. Donc, pour autant que je sache, il n'y a pas eu beaucoup d'activité pendant 24 heures, et certainement pas quelque chose d'intensif. J'ai depuis essayé d'installer newrelic et nodetime mais ni l'un ni l'autre ne fonctionne vraiment - newrelic ne montre aucune donnée et meteor.log a un message de débogage nodetime

Echec de l'extension nodetime-native chargée.

Donc, quand j'essaie d'utiliser le profileur de CPU de nodetime, il apparaît vide et l'instantané de tas revient avec Erreur: les outils V8 ne sont pas chargés.

Je suis à court d'idées à ce stade, et comme Node est assez nouveau pour moi, j'ai l'impression que je prends des coups dans le noir ici. S'il vous plaît aider.

Mettre à jour: Le serveur est toujours indexé à 100% quatre jours plus tard. Même un init 6 ne fait rien - Le serveur redémarre, le processus de nœud démarre et retourne à 100% du processeur. J'ai essayé d'autres outils comme memwatch et webkit-devtools-agent, mais je n'ai pas réussi à les faire travailler avec Meteor.

Ce qui suit est la sortie strace

strace -c -p 6840

Processus 6840 attaché - interruption pour quitter

^ Processus 6840 détaché

% secondes secondes usecs / appels appels d'erreur syscall


77,17 0,073108 1 113701 epoll_wait

11,15 0,010559 0 80106 39908 mmap

6,66 0,006309 0 116907 lire

2,09 0,001982 0 84445 futex

1,49 0,001416 0 45176 écrire

0.68 0.000646 0 119975 munmap

0,58 0,000549 0 227402 clock_gettime

0.10 0.000095 0 117617 rt_sigprocmask

0,04 0,000040 0 30471 epoll_ctl

0,03 0,000031 0 71428 gettimeofday

0.00 0.000000 0 36 mprotect

0.00 0.000000 0 4 brk


100.00 0.094735 1007268 39908 au total

Il semble donc que le processus de noeud passe le plus clair de son temps dans epoll_wait.


13
2018-04-18 17:15


origine


Réponses:


J'ai eu un problème similaire. Je n'ai pas eu besoin d'Oplog et on m'a suggéré d'ajouter le paquet meteor "disable-oplog". Je l'ai donc fait, et l'utilisation du processeur a été beaucoup réduite. Si vous ne tirez pas vraiment parti de Oplog, il serait préférable de le désactiver. meteor add disable-oplog et voir ce qui se passe.

J'espère que ça aide.


2
2018-05-11 17:05



-Vous utilisez Meteor-up? J'utilise aussi New York 2

Dans mon environnement local, avec un serveur Ubuntu, la boîte virtuelle fonctionne à merveille avec seulement 512 Mo et 1 Core.

J'ai le même problème sur DigitalOcean 4 Go de RAM, 2 cœurs VPS + Meteorup (et mon application bien sûr).

LOCAL ENVIROMENT on virtualbox - 1 CORE - 512 MB - New York 2 - ubuntu 14.04 x86.
-------------------------------------
>Meteor.js = 0.8.0,
>Node = 0.10.26,
>MongoDB shell version = 2.4.10,

>%CPU = 20.8 avg,
>%MEM = 27.4 avg

DIGITALOCEAN 4 GB RAM - 2 CPUS - ubuntu 14.04 x64.
-------------------------------------
>Meteor.js = 0.8.0,
>Node = 0.10.26,
>MongoDB shell version = 2.4.10,

>%CPU = 101.8 avg,
>%MEM = 27.4 avg

> PID meteoru+  20   0 1644244 796692   6228 R **102.2** **32.7**  84:47.08 node 

En outre, mon application fait quelque chose comme le vôtre. J'utilise CFS package from atmosphere, et node-csv pour lire le fichier CSV que je télécharge. Le téléchargement fonctionne très bien, même node-csv fonctionne très bien .... mais je peux vous confirmer si c'est le problème, il semble que NODE fonctionne sur DigitalOcean.     Mon MongoDB fonctionne très bien aussi ...


0
2018-04-30 03:30