additional-information
ERDDAP™- Mettez en place votre propreERDDAP™
Ce que vous devez savoir
Erreurs de proxy
Parfois, une demande deERDDAP™retournera une erreur Proxy, une erreur HTTP 502 Bad Gateway, ou une erreur similaire. Ces erreurs sont lancées par Apache ou Tomcat, pasERDDAP™lui-même.
- Si chaque requête génère ces erreurs, surtout lorsque vous êtes en train de configurer votreERDDAP™, alors c'est probablement un proxy ou une mauvaise erreur de passerelle, et la solution est probablement à corrigerERDDAPLes paramètres proxy. C'est peut-être aussi le problème lorsqu'unERDDAP™soudainement commence à jeter ces erreurs pour chaque demande.
- Autrement, les erreurs "proxy" sont généralement en fait des erreurs de sortie de temps lancées par Apache ou Tomcat. Même quand ils se produisent relativement rapidement, c'est une sorte de réponse d'Apache ou de Tomcat qui se produit lorsqueERDDAP™est très occupé, la mémoire limitée, ou limitée par une autre ressource. Dans ces cas, voir les conseils ci-dessous pour traiterERDDAP™répondre lentement.
Demandes de longue durée (> 30 points de temps) d'un ensemble de données maillées sont sujettes à des défaillances de temps, qui apparaissent souvent comme des erreurs proxy, parce qu'il faut beaucoup de temps pourERDDAP™pour ouvrir tous les fichiers de données un par un. SiERDDAP™est autrement occupé pendant la demande, le problème est plus susceptible de se produire. Si les fichiers de l'ensemble de données sont compressés, le problème est plus probable, bien qu'il soit difficile pour un utilisateur de déterminer si les fichiers d'un ensemble de données sont compressés. La solution est de faire plusieurs requêtes, chacune avec une plus petite plage de temps. Combien de temps ? Je suggère de commencer très petit (~30 points de temps ?) Alors (environ) doubler la plage de temps jusqu'à ce que la demande échoue, puis revenir un doublement. Puis faites toutes les demandes (chacun pour un autre morceau de temps) nécessaire pour obtenir toutes les données. UneERDDAP™administrateur peut atténuer ce problème en augmentant leParamètres de timeout Apache.
Surveillance
Nous voulons tous que nos services de données trouvent leur public et soient largement utilisés, mais parfois votreERDDAP™peut être utilisé trop, causant des problèmes, y compris des réponses super lentes pour toutes les demandes. Notre plan pour éviter les problèmes est :
- MoniteurERDDAP™parpage web status.html. Il a des tonnes d'informations utiles. Si vous voyez qu'un grand nombre de demandes arrivent, ou des tonnes de mémoire sont utilisées, ou des tonnes de demandes échouées, ou que chaque Major LoadDatasets prend beaucoup de temps, ou voir tout signe de choses se coincer et répondre lentement, alors regardez dansERDDAP'sfichier log.txtpour voir ce qui se passe.
Il est également utile de noter à quelle vitesse la page d'état répond. Si elle réagit lentement, c'est un indicateur important quiERDDAP™est très occupé.
- MoniteurERDDAP™parRapport quotidienE-mail.
- Surveillez les ensembles de données périmés via le baseUrl /erddap/outOfDateDatasets.htmlpage Web qui est basée sur le optionneltestOutOfDateattribut global.
Moniteurs externes
Les méthodes énumérées ci-dessus sont:ERDDAPles moyens de surveillance. Il est également possible de faire ou d'utiliser des systèmes externes pour surveiller votreERDDAP. Un projet pour ce faire estProjet de mesure erddap d'Axiom. Ces systèmes externes présentent certains avantages:
- Ils peuvent être personnalisés pour fournir les informations que vous voulez, affichées comme vous voulez.
- Ils peuvent inclure des informations surERDDAP™quiERDDAP™ne peut pas accéder facilement ou du tout (par exemple, utilisation du processeur, espace libre de disque,ERDDAP™le temps de réponse vu du point de vue de l'utilisateur,ERDDAP™disponibilité,
- Ils peuvent fournir des alertes (e-mails, appels téléphoniques, SMS) aux administrateurs lorsque les problèmes dépassent un certain seuil.
Plusieurs simultanés Demandes
- Les utilisateurs de la liste noire font plusieurs requêtes simultanées! S'il est clair que certains utilisateurs font plusieurs requêtes simultanées, de façon répétée et continue, alors ajoutez leur adresse IP àERDDAPC'est...<requêteBlacklist>] (/docs/serveur-admin/données#requestblacklist) dans votredatasets.xmlfichier. Parfois, les requêtes proviennent toutes d'une seule adresse IP. Parfois, ils proviennent de plusieurs adresses IP, mais clairement le même utilisateur. Vous pouvez également blacklist personnes faisant des tonnes de demandes invalides ou des tonnes de demandes mentalement inefficaces.
Puis, pour chaque demande,ERDDAP™retourne :
HTTP ERROR 403 - Access Forbidden --
Your IP address is on this ERDDAP's request blacklist.
Did you often submit more than one request at a time?
Did you often submit identical requests in a short period of time?
Did you submit a large number of invalid requests?
If you are ready to avoid these problems, please email \[ERDDAP™ administrator's email address\] to request to be taken off of the blacklist.
Espérons que l'utilisateur verra ce message et vous contactera pour savoir comment résoudre le problème et sortir de la liste noire. Parfois, ils changent d'adresses IP et réessayent.
C'est comme l'équilibre du pouvoir entre les armes offensives et défensives en guerre. Ici, les armes défensives (ERDDAP) ont une capacité fixe, limitée par le nombre de cœurs dans le processeur, la bande passante d'accès au disque et la bande passante du réseau. Mais les armes offensives (utilisateurs, notamment les scripts) ont une capacité illimitée:
- Une seule demande de données à partir de beaucoup de temps peut causerERDDAPpour ouvrir un grand nombre de fichiers (en séquence ou en partie multifilés) . Dans les cas extrêmes, une requête "simple" peut facilement relier le RAIDERDDAP™pendant une minute, bloquer efficacement le traitement d'autres demandes.
- Une seule demande peut consommer un gros morceau de mémoire (même siERDDAP™est codé pour minimiser la mémoire nécessaire pour traiter les grandes requêtes) .
- Parallélisation - Oui. Il est facile pour un utilisateur intelligent de paralléliser une grande tâche en générant beaucoup de threads, chacun d'eux présentant une demande séparée (qui peuvent être grandes ou petites) . Ce comportement est encouragé par la communauté informatique comme un moyen efficace de faire face à un problème important (et parallélisation est efficace dans d'autres circonstances) . Revenir à l'analogie de guerre: les utilisateurs peuvent faire un nombre essentiellement illimité de demandes simultanées avec le coût de chacune étant essentiellement zéro, mais le coût de chaque demande entrant dansERDDAP™peut être grand etERDDAPLa capacité de réponse est limitée. Clairement,ERDDAP™perdra cette bataille, à moins que leERDDAP™administrateur listes noires utilisateurs qui font plusieurs requêtes simultanées qui sont injustement évincer les autres utilisateurs.
- Scripts multiples - Maintenant pensez à ce qui se passe quand il y a plusieurs utilisateurs intelligents chacun exécutant des scripts parallélisés. Si un utilisateur peut générer tellement de requêtes que d'autres utilisateurs sont surchargés, alors plusieurs de ces utilisateurs peuvent générer tellement de requêtes queERDDAP™devient submergé et apparemment insensible. Il s'agit d'uneAttaque DDOSEncore une fois, la seule défense pourERDDAP™c'est aux utilisateurs de la liste noire de faire plusieurs requêtes simultanées qui éloignent injustement les autres utilisateurs.
- Attentes gonflées - Dans ce monde d'entreprises technologiques massives (Amazon, Google, Facebook, ...) , les utilisateurs sont venus à s'attendre à des capacités essentiellement illimitées de la part des fournisseurs. Comme ces entreprises font des opérations financières, plus elles ont d'utilisateurs, plus elles ont de revenus pour développer leur infrastructure informatique. Ils peuvent donc se permettre une infrastructure informatique massive pour traiter les demandes. Et ils limitent astucieusement le nombre de demandes et le coût de chaque demande des utilisateurs en limitant le type de demandes que les utilisateurs peuvent faire afin qu'aucune demande ne soit lourde, et il n'y a jamais de raison (ou d'un moyen) pour les utilisateurs de faire plusieurs requêtes simultanées. Donc, ces grandes entreprises technologiques peuvent avoir beaucoup plus d'utilisateurs queERDDAP™, mais ils ont massivement plus de ressources et des moyens intelligents pour limiter les demandes de chaque utilisateur. C'est une situation gérable pour les grandes entreprises informatiques (Et ils deviennent riches !) mais pas pourERDDAP™les installations. Encore une fois, la seule défense pourERDDAP™c'est aux utilisateurs de la liste noire de faire plusieurs requêtes simultanées qui éloignent injustement les autres utilisateurs.
Donc utilisateurs: Ne faites pas de multiples requêtes simultanées ou vous serez sur la liste noire!
De toute évidence, il est préférable que votre serveur ait beaucoup de cœurs, beaucoup de mémoire (pour que vous puissiez allouer beaucoup de mémoire àERDDAP™, plus qu'il n'a jamais besoin) , et une connexion internet haute bande passante. Ensuite, la mémoire est rarement ou jamais un facteur limitatif, mais la bande passante du réseau devient le facteur limitatif le plus courant. Fondamentalement, comme il y a de plus en plus de requêtes simultanées, la vitesse pour un utilisateur donné diminue. Cela ralentit naturellement le nombre de demandes qui arrivent si chaque utilisateur ne présente qu'une seule demande à la fois.
ERDDAP™Obtenir des données de THREDS
Si votreERDDAP™obtient certaines de ses données à partir d'un THREDDS sur votre site, il ya quelques avantages à faire une copie des fichiers de données THREDDS (au moins pour les ensembles de données les plus populaires) sur un autre RAID queERDDAP™a accès à de sorte queERDDAP™peut servir les données des fichiers directement. ÀERD, nous le faisons pour nos ensembles de données les plus populaires.
- ERDDAP™peut obtenir les données directement et ne pas avoir à attendre que THREDDS recharge l'ensemble de données ou ...
- ERDDAP™peut remarquer et intégrer de nouveaux fichiers de données immédiatement, de sorte qu'il n'a pas à piéger THREDDS fréquemment pour voir si l'ensemble de données a changé. Voir [<mise à jour de EveryNMillis>] (/docs/serveur-admin/datasets#updateeverynnmillis) .
- La charge est répartie entre 2 serveurs RAIDS et 2 serveurs, au lieu que la requête soit difficile sur les deuxERDDAP™et des THREDS.
- Vous évitez le problème d'inadéquation causé par THREDS ayant un petit (par défaut) taille maximale de la demande.ERDDAP™a un système pour gérer l'inadéquation, mais éviter le problème est mieux.
- Vous avez une copie de sauvegarde des données qui est toujours une bonne idée.
Dans tous les cas, ne lancez jamais THREDS etERDDAP™dans le même Tomcat. Exécutez-les dans des Tomcats séparés, ou mieux, sur des serveurs séparés.
Nous trouvons que THREDDS arrive périodiquement dans un état où les demandes sont suspendues. Si votreERDDAP™est d'obtenir des données d'un THREDDS et le THREDDS est dans cet état,ERDDAP™a une défense (il dit que l'ensemble de données basé sur THREDS n'est pas disponible) , mais c'est toujours gênant pourERDDAP™parce queERDDAP™doit attendre le timeout chaque fois qu'il essaie de recharger un jeu de données d'un THREDS accroché. Certains groupes (y comprisERD) éviter cela en redémarrant proactifment les THREDS fréquemment (Par exemple, la nuit dans un travail de cron) .
Répondre lentement
- SiERDDAP™Réponse lente ou si seulement certaines demandes répondent lentement, vous pourriez être en mesure de comprendre si la lenteur est raisonnable et temporaire (Par exemple, en raison de nombreuses demandes de scripts ouWMSutilisateurs) , ou si quelque chose est inexplicablement faux et que vous devezarrêter et redémarrer Tomcat etERDDAP™.
SiERDDAP™est de répondre lentement, voir le conseil ci-dessous pour déterminer la cause, qui espérons vous permettra de résoudre le problème. Vous pouvez avoir un point de départ spécifique (Par exemple, une URL de requête spécifique) ou un point de départ vague (Par exemple,ERDDAP™est lent) . Vous connaissez peut-être l'utilisateur concerné (Par exemple, parce qu'ils vous ont envoyé un courriel) Ou pas. Vous pouvez avoir d'autres indices, ou pas. Étant donné que toutes ces situations et toutes les causes possibles des problèmes sont floues, les conseils ci-dessous tentent de traiter tous les points de départ possibles et tous les problèmes possibles liés aux réponses lentes.
- Cherchez des indicesERDDAPLe fichier journal ( BigParent Directory /logs/log.txt) .
\[En de rares occasions, il y a des indices dansLe fichier journal de Tomcat ( Tomcat /logs/catalina.out) .\]
Cherchez les messages d'erreur. Rechercher un grand nombre de demandes provenant d'une (ou quelques-uns) utilisateurs et peut-être hogging beaucoup de ressources de votre serveur (mémoire, temps CPU, accès disque, bande passante internet) .
Si le problème est lié à un utilisateur , vous pouvez souvent obtenir un indice sur qui l'utilisateur est via des services web comme https://whatismyipaddress.com/ip-lookup qui peut vous donner des informations relatives à l'adresse IP de l'utilisateur (que vous pouvez trouver dansERDDAP'sLog.txtfichier) .
- Si l'utilisateur semble être un bot mal se comporter (notamment, un moteur de recherche essayant de remplir leERDDAP™formes avec chaque permutation possible des valeurs d'entrée) , assurez-vous que vous avez correctement configuré le serveurrobots.txtfichier.
- Si l'utilisateur semble être un **script (s) ** qui fait plusieurs requêtes simultanées, contactez l'utilisateur, expliquez que votreERDDAP™dispose de ressources limitées (Par exemple, mémoire, temps du processeur, accès au disque, bande passante Internet) , et leur demander d'être attentionnés des autres utilisateurs et juste faire une demande à la fois. Vous pourriez aussi mentionner que vous allez les blacklist s'ils ne reculent pas.
- Si l'utilisateur semble être un script faire un grand nombre de demandes longues, demander à l'utilisateur d'être attentionné des autres utilisateurs en mettant une petite pause (Deux secondes ?) dans le script entre les requêtes.
- WMSlogiciel client peut être très exigeant. Un client demandera souvent 6 images personnalisées à la fois. Si l'utilisateur semble être unWMSclient qui fait des demandes légitimes, vous pouvez:
- Ignore-le. (recommandé, parce qu'ils vont bientôt avancer)
- Éteignez le serveurWMSservice viaERDDAPLe fichier setup.html. (non recommandé)
- Si les demandes semblent stupide, fou, excessif, ou malveillant, ou si vous ne pouvez pas résoudre le problème autrement, envisager d'ajouter temporairement ou définitivement l'adresse IP de l'utilisateur à la [<requêteBlacklist> dans votredatasets.xmlfichier] (/docs/serveur-admin/données#requestblacklist) .
- Essayez de reproduire le problème vous-même, depuis votre ordinateur.
Déterminez si le problème concerne un ensemble de données ou tous les ensembles de données, pour un utilisateur ou tous les utilisateurs, pour seulement certains types de requêtes, etc. Si vous pouvez reproduire le problème, essayez de le réduire. Si vous ne pouvez pas reproduire le problème, alors le problème peut être lié à l'ordinateur de l'utilisateur, la connexion Internet de l'utilisateur, ou la connexion Internet de votre institution. - Si juste un ensemble de données répond lentement (peut-être seulement pour un type de demande d'un utilisateur) , le problème peut être:
- ERDDAPL'accès aux données sources de l'ensemble de données (notamment à partir de bases de données relationnelles, de Cassandra et de ensembles de données à distance) peut être temporairement ou définitivement lent. Essayez de vérifier la vitesse de la source indépendamment deERDDAP. Si c'est lent, vous pouvez peut-être l'améliorer.
- Le problème est-il lié à la demande spécifique ou au type général de demande? Plus le sous-ensemble de données demandé est grand, plus la demande échouera probablement. Si l'utilisateur fait d'énormes demandes, demandez à l'utilisateur de faire des demandes plus petites qui sont plus susceptibles d'obtenir une réponse rapide et réussie.
Presque tous les ensembles de données sont meilleurs pour traiter certains types de demandes que d'autres types de demandes. Par exemple, lorsqu'un jeu de données stocke différents morceaux de temps dans différents fichiers, les demandes de données à partir d'un grand nombre de points de temps peuvent être très lentes. Si les demandes actuelles sont de type difficile, envisagez d'offrir une variante de l'ensemble de données optimisé pour ces demandes. Ou expliquez simplement à l'utilisateur que ce type de requête est difficile et prend du temps, et demandez leur patience.
-
L'ensemble de données peut ne pas être configuré de manière optimale. Vous pouvez peut-être apporter des modifications à l'ensemble de donnéesdatasets.xmlpour aiderERDDAP™mieux gérer l'ensemble de données. Par exemple,
- EDDGridLes ensembles de données de NcFiles qui accèdent aux données des fichiers nc4/hdf5 compressés sont lents lors de l'obtention des données pour toute la gamme géographique (Par exemple, pour une carte du monde) car le fichier entier doit être décomprimé. Vous pouvez convertir les fichiers en fichiers non compressés, mais alors l'espace disque requis sera beaucoup, beaucoup plus grand. Il est probablement préférable de simplement accepter que ces ensembles de données seront lents dans certaines circonstances.
- La configuration du [<subsetVariables>] (/docs/serveur-admin/datasets#subsetvariables) tag a une énorme influence sur commentERDDAP™gère les ensembles de données EDDTable.
- Vous pourriez être en mesure d'augmenter levitesse d'une EDDTableFromDatabaseensemble de données.
- De nombreux ensembles de données EDDTable peuvent être développés parstockage d'une copie des données dansNetCDFDossiers d'array piégés, quiERDDAP™peut lire très rapidement.
Si vous voulez aider à accélérer un ensemble de données spécifique, inclure une description du problème et le morceau de l'ensemble de donnéesdatasets.xmlet de voir notresection sur l'obtention d'un soutien supplémentaire.
- Si tout enERDDAP™est toujours lent, le problème peut être:
- L'ordinateur qui tourneERDDAP™peut ne pas avoir assez de mémoire ou de puissance de traitement. C'est bon de courirERDDAP™sur un serveur multi-cœur moderne. Pour une utilisation lourde, le serveur devrait avoir un système d'exploitation 64 bits et 8 Go ou plus de mémoire.
- L'ordinateur qui tourneERDDAP™Il se peut aussi que d'autres applications consomment beaucoup de ressources du système. Si oui, pouvez-vous obtenir un serveur dédié pourERDDAP? Par exemple (ce n'est pas une approbation) , vous pouvez obtenir un serveur Mac Mini quad-core avec 8 Go de mémoire pour ~1100 $.
- Si tout enERDDAP™est temporaire Lent, regardez votreERDDAP's /erddap/status.htmlpage dans votre navigateur.
- LesERDDAP™La page d'état ne se charge pas? Si oui,redémarrerERDDAP™.
- Est-ce queERDDAP™charger la page d'état lentement (Par exemple, >5 secondes) ? C'est un signe que tout enERDDAP™est lente, mais ce n'est pas forcément un problème.ERDDAP™C'est peut-être très occupé.
- Pour "La réponse a échoué (depuis les derniers grands ensembles de données de chargement) ", est n= un grand nombre? Cela indique qu'il y a eu récemment beaucoup de demandes rejetées. Ça peut être un problème ou un début de problème. Le temps médian pour les échecs est souvent important (Par exemple, 210000 ms) , ce qui signifie qu'il y avait (Vraiment ?) Beaucoup de fils actifs. qui liaient beaucoup de ressources (Comme la mémoire, les fichiers ouverts, les sockets ouverts, ...) , Ce qui n'est pas bon.
- Pour "Réponse Temps réussi (depuis les derniers grands ensembles de données de chargement) ", est n= un grand nombre? Cela indique qu'il y a eu récemment beaucoup de demandes retenues. Ce n'est pas un problème. Ça veut juste dire que votreERDDAP™Ça devient très utile.
- Le "Nombre de fils d'attente non-Tombat" est-il le double d'une valeur typique? C'est souvent un problème grave qui causeraERDDAP™pour ralentir et finir par geler. Si cela persiste pendant des heures, vous voudrez peut-êtreredémarrerERDDAP™.
- Au bas de la liste "Résumé de l'utilisation de la mémoire", la dernière valeur "Memory: currently using" est-elle très élevée? Cela peut simplement indiquer une utilisation élevée, ou cela peut être un signe de problème.
- Regardez la liste des fils et leur statut. Un nombre inhabituel d'entre eux font quelque chose d'inhabituel ?
- Est la connexion Internet de votre institution actuellement lent ? Rechercher sur Internet "test de vitesse Internet" et utiliser l'un des tests en ligne gratuits, tels que https://www.speakeasy.net/speedtest/ . Si la connexion Internet de votre institution est lente, alors les connexions entreERDDAP™les sources de données à distance seront lentes et les connexions entreERDDAP™et l'utilisateur sera lent. Parfois, vous pouvez résoudre cela en arrêtant l'utilisation inutile d'Internet (Par exemple, les personnes qui regardent des vidéos en streaming ou des conférences téléphoniques vidéo) .
- Est la connexion Internet de l'utilisateur actuellement lent ? Demandez à l'utilisateur de faire une recherche sur Internet pour "test de vitesse Internet" et d'utiliser l'un des tests gratuits en ligne, comme https://www.speakeasy.net/speedtest/ . Si la connexion Internet de l'utilisateur est lente, elle ralentit leur accès àERDDAP. Parfois, ils peuvent résoudre cela en arrêtant l'utilisation inutile d'Internet dans leur institution (Par exemple, les personnes qui regardent des vidéos en streaming ou des conférences téléphoniques vidéo) .
- Cassé ?
Voir notresection sur l'obtention d'un soutien supplémentaire.
Fermez et redémarrez
- Comment fermer et redémarrer Tomcat etERDDAP™
Vous n'avez pas besoin d'arrêter et de redémarrer Tomcat etERDDAPsiERDDAP™est temporairement lent, lent pour une raison connue (comme beaucoup de requêtes de scripts ouWMSutilisateurs) , ou d'appliquer des changementsdatasets.xmlfichier.
Vous devez arrêter et redémarrer Tomcat etERDDAP™si vous devez appliquer des modifications au fichier setup.xml, ou siERDDAP™gele, pend ou verrouille. Dans des circonstances extrêmes,Javapeut geler pendant une minute ou deux pendant qu'il fait une collecte complète des ordures, mais ensuite récupérer. Donc c'est bon d'attendre une minute ou deux pour voir siJava/ERDDAP™est vraiment congelé ou si elle fait juste une longue collecte des ordures. (Si la collecte des ordures est un problème courant,attribuer plus de mémoire à Tomcat.)
Je ne recommande pas d'utiliser le Tomcat Web Application Manager pour démarrer ou arrêter Tomcat. Si vous ne vous arrêtez pas complètement et ne démarrez pas Tomcat, tôt ou tard vous aurez des problèmes de mémoire PermGen.
Pour arrêter et redémarrer Tomcat etERDDAP:
- Si vous utilisez Linux ou un Mac :
(Si vous avez créé un utilisateur spécial pour exécuter Tomcat, par exemple, tomcat, n'oubliez pas de faire les étapes suivantes en tant qu'utilisateur.)
- Utiliser cd Tomcat /bin
- Utiliser ps -ef|tomcat grep pour trouver le processus java/tomcat Numéro (J'espère qu'un seul processus sera énuméré) , que nous appellerons javaProcessID ci-dessous.
- SiERDDAP™est congelé/humide/verrouillé, utiliser tuer -3 javaProcessID à direJava (qui dirige Tomcat) pour faire une sauvegarde de thread dans le fichier journal Tomcat: Tomcat /logs/catalina.out . Après avoir redémarré, vous pouvez diagnostiquer le problème en trouvant l'information de la décharge thread (et toute autre information utile ci-dessus) en Tomcat /logs/catalina.out et aussi en lisant les parties pertinentes de laERDDAP™archive journal. Si vous voulez, vous pouvez inclure cette information et voir notresection sur l'obtention d'un soutien supplémentaire.
- Utilisez ./shutdown. sh
- Utiliser ps -ef|grep tomcat à plusieurs reprises jusqu'à ce que le processus java/tomcat ne soit pas listé.
Parfois, le processus java/tomcat prend jusqu'à deux minutes pour s'arrêter complètement. La raison en est :ERDDAP™envoie un message à ses fils d'arrière-plan pour leur dire de s'arrêter, mais parfois il faut beaucoup de temps à ces fils pour arriver à un bon endroit d'arrêt.
- Si après une minute, java/tomcat ne s'arrête pas seul, vous pouvez utiliser
tuer -9 javaProcessID
forcer le processus java/tomcat à s'arrêter immédiatement. Si possible, n'utilisez ceci qu'en dernier recours. Le commutateur -9 est puissant, mais il peut causer divers problèmes. - Pour redémarrerERDDAP™, utiliser ./startup.sh
- AffichageERDDAP™dans votre navigateur pour vérifier que le redémarrage a réussi. (Parfois, vous devez attendre 30 secondes et essayer de chargerERDDAP™à nouveau dans votre navigateur pour qu'il réussisse.)
- Si vous utilisez Windows:
- Utiliser cd Tomcat /bin
- Utilisationshutdown.bat
- Vous pouvez vouloir/avoir besoin d'utiliser le Gestionnaire des tâches Windows (accessible via Ctrl Alt Del) de veiller à ce queJava/Tomcat/ERDDAP™processus/application a complètement cessé. Parfois, le processus/la demande prend jusqu'à deux minutes pour s'arrêter. La raison en est :ERDDAP™envoie un message à ses fils d'arrière-plan pour leur dire de s'arrêter, mais parfois il faut beaucoup de temps à ces fils pour arriver à un bon endroit d'arrêt.
- Pour redémarrerERDDAP™, utilisez startup.bat
- AffichageERDDAP™dans votre navigateur pour vérifier que le redémarrage a réussi. (Parfois, vous devez attendre 30 secondes et essayer de chargerERDDAP™à nouveau dans votre navigateur pour qu'il réussisse.)
Crashes ou gels fréquents
SiERDDAP™devient lent, s'écrase ou gèle, quelque chose ne va pas. Regardez.ERDDAPLe fichier journalpour essayer de trouver la cause. Si vous ne pouvez pas, veuillez inclure les détails et voir notresection sur l'obtention d'un soutien supplémentaire.
Le problème le plus courant est un utilisateur gênant qui exécute plusieurs scripts à la fois et/ou quelqu'un qui effectue un grand nombre de requêtes non valides. Si cela se produit, vous devriez probablement blacklist cet utilisateur. Lorsqu'un utilisateur sur la liste noire fait une demande, le message d'erreur dans la réponse les encourage à vous envoyer un courriel pour résoudre les problèmes. Ensuite, vous pouvez les encourager à exécuter un seul script à la fois et à résoudre les problèmes dans leur script (Par exemple, demander des données à partir d'un ensemble de données à distance qui ne peuvent pas répondre avant de s'arrêter) . Voir [<requêteBlacklist> dans votredatasets.xmlfichier] (/docs/serveur-admin/données#requestblacklist) .
Dans des circonstances extrêmes,Javapeut geler pendant une minute ou deux pendant qu'il fait une collecte complète des ordures, mais ensuite récupérer. Donc c'est bon d'attendre une minute ou deux pour voir siJava/ERDDAP™est vraiment congelé ou si elle fait juste une longue collecte des ordures. (Si la collecte des ordures est un problème courant,attribuer plus de mémoire à Tomcat.)
SiERDDAP™devient lent ou gèle et le problème n'est pas un utilisateur gênant ou une longue collecte des ordures, vous pouvez généralement résoudre le problème parredémarrageERDDAP™. Mon expérience est queERDDAP™peut courir pendant des mois sans avoir besoin d'un redémarrage.
Moniteur
Vous pouvez surveiller votreERDDAP's statut en regardant/erddap/status.htmlpage, notamment les statistiques dans la section supérieure. SiERDDAP™devient lent ou gele et le problème n'est pas seulement une utilisation extrêmement lourde, vous pouvez généralement résoudre le problème parredémarrageERDDAP™. Il y a d'autres mesures disponibles grâce à l'intégration Prométhée à /erddap/metrics.
Mon expérience est queERDDAP™peut courir pendant des mois sans avoir besoin d'un redémarrage. Vous ne devriez avoir besoin de le redémarrer que si vous voulez appliquer certaines modifications que vous avez faites àERDDAP's setup.xml ou quand vous devez installer de nouvelles versions deERDDAP™,Java, Tomcat, ou le système d'exploitation. Si vous devez redémarrerERDDAP™Souvent, quelque chose ne va pas. Regardez.ERDDAPLe fichier journalpour essayer de trouver la cause. Si vous ne pouvez pas, veuillez inclure les détails et voir notresection sur l'obtention d'un soutien supplémentaire. Comme solution temporaire, vous pourriez essayer d'utiliserMoniteurpour surveiller votreERDDAP™et le redémarrer si nécessaire. Ou, vous pourriez faire un travail de cron pour redémarrerERDDAP™ (proactivement) périodiquement. Il peut être un peu difficile d'écrire un script pour automatiser la surveillance et le redémarrageERDDAP. Quelques conseils qui pourraient aider:
- Vous pouvez simplifier les tests si le processus Tomcat fonctionne toujours en utilisant le commutateur -c avec grep: Autres Tomcat Utilisateur |c java Cela réduira la sortie à "1" si le processus tomcat est toujours en vie, ou "0" si le processus s'est arrêté.
- Si vous êtes bon avec gawk, vous pouvez extraire le processID des résultats de Autres Tomcat Utilisateur |grep java, et utiliser le processID dans d'autres lignes du script.
Si vous mettez en place Monit ou un travail de cron, ce serait super si vous pouviez partager les détails afin que d'autres puissent profiter de notresection sur l'obtention d'un soutien supplémentaireoù vous pouvez partager.
Permgen
Si vous utilisez Tomcat Manager à plusieurs reprises pour recharger (ou Stop et Start) ERDDAP™,ERDDAP™Peut ne pas démarrer et lancer java.lang. De mémoireErreur: PermGen. La solution est de périodiquement (Ou à chaque fois ?) fermer et redémarrer tomcat etERDDAP™, au lieu de simplement rechargerERDDAP.
\[Mise à jour : Ce problème a été grandement minimisé ou corrigéERDDAP™de la version 1.24.\]
Journal
- Log.txt
SiERDDAP™ne démarre pas ou si quelque chose ne fonctionne pas comme prévu, il est très utile de regarder les messages d'erreur et de diagnostic dans leERDDAP™fichier journal. - Le fichier journal est BigParent Directory /logs/log.txt ( BigParent Directory est spécifié dansconfiguration.xml) . S'il n'y a pas de journal. fichier txt ou si le journal. Le fichier txt n'a pas été mis à jour depuis le redémarrageERDDAP™, regardez dans leFichiers de journaux Tomcatpour voir s'il y a un message d'erreur.
- Types de messages de diagnostic dans le fichier journal:
- Le mot "erreur" est utilisé quand quelque chose s'est tellement mal passé que la procédure n'a pas abouti. Bien qu'il soit ennuyeux d'obtenir une erreur, l'erreur vous force à traiter le problème. Nous pensons qu'il est préférable de jeter une erreur, que d'avoirERDDAP™Vous ne vous attendiez pas à travailler.
- Le mot "avertissement" est utilisé quand quelque chose a mal tourné, mais la procédure a pu être achevée. C'est assez rare.
- Tout le reste n'est qu'un message informatif. Vous pouvez contrôler la quantité d'informations enregistrées avec [<niveau de log>] (/docs/serveur-admin/données#loglevel) datasets.xml.
- Le jeu de données recharge et les réponses de l'utilisateur qui prennent >10 secondes pour terminer (succès ou échec) sont marqués par " (Plus de 10 !) ". Ainsi, vous pouvez rechercher le fichier log.txt pour trouver les ensembles de données qui ont été lents à recharger ou le numéro de requête des requêtes qui ont été lents à terminer. Vous pouvez alors regarder plus haut dans le fichier log.txt pour voir quel était le problème de l'ensemble de données ou ce que la demande de l'utilisateur était et de qui il était. Ces charges de données lentes et les demandes des utilisateurs sont parfois taxant surERDDAP. En savoir plus sur ces demandes peut donc vous aider à identifier et à résoudre les problèmes.
- L'information est écrite au fichier journal sur le lecteur de disque dans des morceaux assez grands. L'avantage est que c'est très efficace --ERDDAP™ne bloquera jamais en attendant que l'information soit écrite dans le fichier journal. L'inconvénient est que le journal se termine presque toujours par un message partiel, qui ne sera pas terminé avant que le prochain morceau soit écrit. Vous pouvez le mettre à jour (pour un instant) en regardant votreERDDAPla page Web de l'état à https://your.domain.org/erddap/status.html (ouhttp://sihttpsn'est pas activé) .
- Lorsque les fichiers log.txt atteignent 20 Mo, le fichier est renommé journal. txt.previous et un nouveau fichier log.txt est créé. Donc les fichiers journaux ne s'accumulent pas.
Dans setup.xml, vous pouvez spécifier une taille maximale différente pour le fichier journal, dans MegaBytes. Le minimum autorisé est 1 (Pays) . Le maximum autorisé est de 2000 (Pays) . Par défaut : 20 (Pays) . Par exemple:
<logMaxSizeMB>20</logMaxSizeMB>
- Quand vous redémarrezERDDAP™, ERDDAP™fait une copie d'archive du log.txt et du log. txt.fichiers précédents avec un timbre-temps dans le nom du fichier. S'il y a eu des problèmes avant le redémarrage, il peut être utile d'analyser ces fichiers archivés pour trouver des indices sur le problème. Vous pouvez supprimer les fichiers d'archive s'ils ne sont plus nécessaires.
Parsing log.txt
ERDDAPLe journal de bord. Le fichier txt n'est pas conçu pour l'analyse (bien que vous pourriez être en mesure de créer des expressions régulières qui extraire l'information souhaitée) . Il est conçu pour aider un humain à comprendre ce qui se passe quand quelque chose se passe mal. Lorsque vous soumettez un bogue ou un rapport de problème àERDDAP™les développeurs, si possible, veuillez inclure toutes les informations du fichier log.txt relatives à la requête gênante.
Pour des raisons d'efficacité,ERDDAP™seulement écrit des informations à enregistrer. txt après une grande partie de l'information s'est accumulée. Donc si vous visitez le journal. txt juste après qu'une erreur est survenue, les informations liées à l'erreur peuvent ne pas avoir encore été écrites sur log.txt. Afin d'obtenir des informations parfaitement à jour de log.txt, visitez votreERDDAP'spage status.html. QuandERDDAP™processus qui demande, il chasse toutes les informations en attente à log.txt.
PourERDDAP™statistiques d'utilisation, veuillez utiliser leFichiers journaux Apache et/ou Tomcatau lieu deERDDAPLe log.txt. Notez queERDDAP'spage status.html (certains) etRapport quotidien (plus) avoir un grand nombre de statistiques d'utilisation précalculées pour vous.
Registres de Tomcat
SiERDDAP™ne démarre pas parce qu'une erreur est survenue très tôt dansERDDAP's startup, le message d'erreur apparaîtra dans les fichiers journaux de Tomcat ( Tomcat /logs/catalina. Aujourd'hui .log ou Tomcat /logs/catalina.out) Pas dansERDDAPLe fichier log.txt.
Statistiques d'utilisation : Pour la plupart des informations que les gens veulent recueillir à partir d'un fichier journal (Par exemple, statistiques d'utilisation) , veuillez utiliser les fichiers journaux Apache et/ou Tomcat. Ils sont bien formatés et ont ce type d'information. Il existe de nombreux outils pour les analyser, par exemple,AWStats,Kibana de ElasticSearchetJMeter, mais recherchez le web pour trouver le bon outil pour vos fins.
Notez que les fichiers journaux identifient uniquement les utilisateurs comme adresses IP. Il existe des sites Web pour vous aider à obtenir des informations relatives à une adresse IP donnée, par exemple,Ce qu'estMyIPAdresse, mais vous ne pourrez normalement pas trouver le nom de l'utilisateur.
Aussi, à cause deDHCP, l'adresse IP d'un utilisateur donné peut être différente à des jours différents, ou différents utilisateurs peuvent avoir la même adresse IP à des moments différents.
Sinon, vous pouvez utiliser quelque chose commeGoogle Analytique. Mais attention : lorsque vous utilisez des services externes comme Google Analytics, vous renoncez à la vie privée de vos utilisateurs en donnant à Google un accès complet à leur activité sur votre site que Google (et d'autres ?) peut garder pour toujours et utiliser à n'importe quelle fin (peut-être pas techniquement, mais probablement dans la pratique) . Vos utilisateurs n'ont pas consenti à cela et ne sont probablement pas conscients qu'ils seront suivis sur votre site Web, tout comme ils ne sont probablement pas conscients de la mesure dans laquelle ils sont suivis sur presque tous les sites Web. De nos jours, beaucoup d'utilisateurs sont très inquiets que tout ce qu'ils font sur le web soit surveillé par ces grandes entreprises (Google, Facebook, etc.) et par le gouvernement, et trouver ceci une intrusion injustifiée dans leur vie (comme dans le livre, 1984) . Cela a conduit de nombreux utilisateurs à installer des produits commeInsigne de confidentialitépour minimiser le suivi, utiliser des navigateurs alternatifs commeNavigateur Tor (ou désactiver le suivi dans les navigateurs traditionnels) , et d'utiliser des moteurs de recherche alternatifs commePlongée de canard. Si vous utilisez un service comme Google Analytics, veuillez au moins documenter son utilisation et les conséquences en modifiant le<standardPolitique de confidentialité> balise dansERDDAP's \[Tomcat\]/webapps/erddap/WEB-INF/classes/gov/noaa/pfel/erddap/util/messages.xml fichier.
Registre des courriels
- CourrielLogYEAR-MM-JJ.txt
ERDDAP™écrit toujours le texte de tous les courriels sortants dans le courriel actuel Fichier LogYEAR-MM-DD.txt dans BigParent Directory /logs ( BigParent Directory est spécifié dansconfiguration.xml) . - Si le serveur ne peut pas envoyer des messages électroniques, ou si vous avez configuréERDDAP™ne pas envoyer des messages électroniques, ou si vous êtes simplement curieux, ce fichier est un moyen pratique de voir tous les messages électroniques qui ont été envoyés.
- Vous pouvez supprimer les fichiers de journaux des jours précédents s'ils ne sont plus nécessaires.