Jenkins GUI affiche seulement après une attente de 2 minutes

Mon Jenkins version est Jenkins 1.508. Quelques recherches sur google autour semblait indiquer que j'avais besoin d'un petit changement dans mon jenkins.xml (voir, par exemple,http://devophuman.blogspot.nl/2013/04/jenkins-is-going-wild.html), mais que le xml n'a pas aider beaucoup dans mon cas. Aujourd'hui j'ai installé le plug-in de surveillance, et peut voir que jenkins nécessaire 112,978 ms pour répondre à ma demande, où dois-je regarder pour le coupable?

1er, je vous suggère de mettre à jour la dernière Jenkins disponibles. Nous courons 1.550 sans aucun problème. 2e, ne vous exécutez un serveur web comme httpd ou autres? Si oui, vérifiez les journaux.

OriginalL'auteur Erik VV | 2014-06-18

  1. 6

    Je voudrais vous recommandons de vérifier un couple de différentes choses.

    1. Est le jenkins processus lié au 100% de CPU ou supérieur? Cela pourrait indiquer qu'il y a, par exemple, de trop s'appuie être maintenu autour de (Jenkins semble avoir de la difficulté avec cela; j'ai l'habitude de ne pas garder plus de 25 construit par emploi pour aider à prévenir les problèmes de performances de ce). J'ai remarqué que la Performance plugin peut également conduire à une intense utilisation du PROCESSEUR, surtout quand c'est de dessiner les graphes (qui Jenkins ne cache ni les enregistrer sur le disque, de sorte que chaque chargement de la page dont ils ont besoin pour être recréé).

    2. Ce qui ne l' Jenkins journal d'accès de dire? Rapidement enregistrer votre demande, mais alors de s'asseoir il semble ne rien faire? Si c'est le cas et le CPU n'est pas rattachée sur le jenkins processus, il peut être un problème de navigateur.

    J'ai trouvé que les pages n'ont pas été chargé, même après 5 minutes environ, mais il n'y
    a été, apparemment, pas de jenkins-en fonction de la charge sur le serveur, ni aucune charge sérieuse
    sur la boîte d'ailleurs. J'avais été en utilisant Firefox pour accéder à la
    pages, et quand j'ai essayé la même page dans Chrome, chargé
    instantanément. J'ai pu ensuite revenir à la Firefox et de nouveau ne se charge pas.
    Donc il y a quelque chose de mal à ce point dans le temps avec le navigateur à l'égard de Jenkins (je ne sais pas très bien ce qu'il était). Alors maintenant, je l'utilise généralement Chrome d'accès
    Jenkins et n'ai pas vraiment remarqué lent/non-chargement des pages depuis.

    Modifier en réponse au commentaire de l'OP:

    À nettoyer les anciens builds, j'utilise un processus en deux phases:

    1. Accédez à la emplois répertoire de votre Jenkins installer et ensuite dans le construit répertoires de chaque travail que vous souhaitez nettoyer. À partir de là, il suffit de supprimer les répertoires des builds que vous ne voulez plus (à l'aide de quelque shell outils vous préférez -- trouver, etc.) Si trop de construit est le problème, le nettoyage de ceux-ci jusqu'au niveau du système de fichiers devrait alors permettre Jenkins pages et des vues à charger.
    2. Si le nettoyage vous permet de charger les pages, pour les travaux, vous pouvez alors cliquer sur le Configure action pour changer la config et sélectionnez l'option de conserver un nombre limité de constructions, un réglage à une valeur inférieure, par exemple 25.

    Si le jenkins processus n'est pas rattachée à une utilisation élevée du PROCESSEUR nombre, il paraît peu probable que c'est le nombre de builds qui sont le problème, mais c'est probablement la peine d'essayer. Si vous pensez que vous pouvez le construire info revenir plus tard, il suffit de les déplacer d'un endroit à l'extérieur de la emplois hiérarchie de dossiers au lieu de les supprimer et Jenkins ne pas les connaître. Vous pouvez toujours revenir plus tard.

    Il est probablement mieux à faire au niveau des fichiers de déménagement avec Jenkins arrêté, puis le recharger une fois que le nettoyage est effectué. Il y aura beaucoup moins de construit à parcourir.

    Modifier en réponse à un suivi de commentaires de l'OP:

    Re: point 1, qui sonne comme il pourrait y avoir un problème avec l'installation (cross-linked séparé installe, ou quelque chose comme ça).

    Re: point 2: ça va dépendre en partie de la façon dont Jenkins a été installé. est-il en cours d'exécution sur Tomcat, ou avec autonome?

    Re: point 3: Ce vraiment semble que vous pourriez avoir réticulé installe. Si vous avez cessé de Jenkins, l'interface graphique ne devrait vraiment pas plus de travail.

    Re: point 4: 11 secondes est certainement une grande amélioration de plus de 2 minutes. Sans aucun doute, suggère que trop de nombreuses tenues-construit a été un problème, mais les pages ne devrait vraiment être assez accrocheur pour charger sur un relativement inactif du système, de sorte qu'il sonne comme il peut éventuellement être certains d'autres questions, en particulier un réticulé installer de toutes sortes.

    Est-il jamais plus d'un jenkins processus en cours d'exécution? Est Tomcat impliqués?

    Modifier en réponse à l'opération de suivi du commentaire:

    Compte tenu de vos commentaires à propos de ne rappelle pas les détails de l'installation d'origine, je pense que c'est peut-être préférable de simplement installer Jenkins partir de zéro en utilisant l'auto-contenue (c'est à dire non-Tomcat) méthode, puis migrer vos données de l'ancien installer comme je l'ai mentionné précédemment, la copie de l'ensemble des emplois répertoire d'ailleurs en premier, juste au cas où.

    De cette façon, vous pouvez être sûr de les détails de l'installation et de conserver les données.

    Le serveur n'est pas provisionnée à 100%, c'est environ 80% d'inactivité. Notre équipe est toujours à l'aide de Chrome, mais je n'ai pas de nettoyer tous les construit depuis le Jenkins installation a eu lieu. - Je trouver de nombreux journaux dans le Jenkins répertoire d'installation, mais pas de journal d'accès. L'err.le journal est plutôt grand, et montre beaucoup de messages du type " impossible de charger...". Donc je suppose que la première chose à faire est de: nettoyage de versions plus anciennes. Quelle est la méthode recommandée pour ce faire?
    Ajout de quelques infos à propos de la façon dont je vais sur le nettoyage construit lorsque l'INTERFACE Web est coincé. Aussi, ce qui était la raison pour laquelle il a donné dans les journaux d'erreur pour ne pas être en mesure de charger les pages? Toute erreur modèles?
    1) Fichier Journal, raison pour laquelle " ne peut pas charger...": nom de répertoire non Valide. 2) je suis toujours à se demander où est le journal des accès ... 3) Arrêté jenkins, mais gui travaillait encore, tué le processus au lieu de l'arrêt du service. Ne sais pas si cela pourrait être pertinent pour les temps de réponse, mais quelque chose semble avoir un problème avec mon installation de jenkins. 4) Nettoyage: fait exactement ce que vous conseillé: supprimé manuellement toutes les versions avant 1/6/2014, et reconfiguré les emplois. D'abord distant, l'accès à l'ihm a eu 11 secondes. C'est mieux que 2 minutes, mais nous aurons à voir comment cela évolue dans les prochains jours.
    Ajout ajouter l de la réponse à la réponse.
    Un problème est que j'ai installé Jenkins environ un an, et j'ai oublié les détails de l'installation. Un autre problème est que j'ai beaucoup de matous en cours d'exécution sur le serveur, sur des ports différents. Le port 8080 de la jenkins GUI me fait penser qu'il existe une relation de tomcat, mais le jenkins service est démarré en tant que D:\Programs\Jenkins\jenkins.exe et la structure de répertoire n'est PAS un traditionnel tomcat un avec les journaux, webapss (il y a une "guerre" à la place) des sous-répertoires. Je ne vois que le jenkins.exe dans l'explorateur de processus. Il y a trop peu d'informations de journal pour voir ce que le gui est aux prises avec.

    OriginalL'auteur khampson

  2. 1

    Dans mon expérience, de son liés à système de fichiers de Windows étant vraiment mauvais à la gestion de dossiers avec beaucoup de sous-dossiers. Chargement d'un point de Vue pourrait prendre jusqu'à une minute.

    Nous avons fait notre Jenkins Vue rapide nouveau par la réduction de la valeur par défaut s'appuie stockées par emploi et de supprimer les anciens builds comme suggéré par khampson.

    Je m'attends à une Jenkins en cours d'exécution sur Linux à être beaucoup mieux à gérer grand nombre de builds

    OriginalL'auteur David Lilljegren

  3. 0

    Après la mise à niveau Jenkins à la version 1.568, et le nettoyage du poste de répertoires, le temps de réponse typique sur un premier appel de la journée est en baisse d'environ 20 secondes. Je pense que le "premier appel de la journée" est important ici, parce que quand j'irai ensuite à une autre machine, l'interface graphique rend immédiatement. Cela pourrait être lié à la compagnie de proxy, les mécanismes de mise en cache ici et là, ou à l'intérieur jenkins mise en œuvre, mais je peux vivre avec la situation actuelle.

    Salut Erik, nous avons le même problème avec le chargement dans la matinée. Nous n'utilisons pas de proxy. C'est donc un jenkins question autant que je sache.

    OriginalL'auteur Erik VV

  4. 0

    Nous avons mis en place un moyen rapide et sale contourner. Il suffit de créer un emploi dans Jenkins, qui appelle régulièrement le script suivant:

    wget http://localhost:8080/view/All/-O /dev/null

    Cela réduit le temps de charge pour tous les points de vue (depuis Jenkins a prendre le coup lui-même) pour nos utilisateurs.

    Comme indiqué dans le commentaire de l'wget ne charge que la vue du travail. Afin de interate tous les emplois que nous à l'aide de la suite curl script (basé sur Linux host):

    Jenkins 1.x;

    for x in ` curl 'http://localhost:8080/api/xml?tree=jobs\[url\]' | sed 's/<url>/\n/g' |  sed 's/<\/url>//g' | sed 's/<job>//g'| sed 's/<job>//g' | sed 's/<\/job>//g' | grep http | sed 's/your.jenkins.host.domain/localhost:8080/' ` ; do curl "$x" -o /dev/null ;done

    Jenkins 2.x;

    for x in `  curl 'http://localhost:8080/api/xml?tree=jobs\[url\]' | sed 's/<url>/\n/g' |  sed 's/<\/url.*//g' | grep http | sed 's/your.jenkins.host.domain/localhost:8080/' ` ; do curl "$x" -o /dev/null ;done

    Vous pouvez bien sûr la même chose pour les vues (http://localhost:8080/api/xml?tree=views%5Burl%5D)

    malheureusement, ce n'est pas de travail pour le dossier plugin dans jenkins. Étant donné que les projets sont en dessous de la dossiers et, par conséquent, pas encore chargé
    J'ai mis à jour mon post avec une boucle de script utilisé pour extraire tous les emplois au lieu. La même méthode peut être appliquée pour l'emploi, la vue et tous les autres types accessible via l'API.
    merci pour la mise à jour, testé la boucle. Mon jenkins est interdire l'accès. Authentification requise <!-- Vous êtes authentifié en tant que: anonyme Groupes que vous êtes dans:
    Vous pouvez fournir un accès pour l'utilisateur non authentifié de différentes ressources en vertu de configurer la sécurité mondiale. Qui plug-in d'authentification utilisez-vous?
    à l'aide: "Jenkins" propre de l'utilisateur de la base de données" avec le Rôle de "Stratégie", Mais anonyme permettant un accès à une zone protégée n'a pas de sens pour moi?!? Peut-être puisque je ne pouvais pas trouver l'endroit approprié pour vérifier les autorisations

    OriginalL'auteur Andreas Sandberg

  5. 0

    Cela peut ne pas être le problème pour l'affiche originale, mais j'espère que ça peut aider d'autres personnes qui débarquent ici par une recherche sur le web. Dans notre Jenkins cas, le massif de l'INTERFACE utilisateur ralentissement s'est avéré être un problème de réseau. J'avais déplacé le serveur vers un emplacement temporaire lors d'un déménagement de bureau, où la mise en Jenkins Emplacement/Jenkins URL serait un échec. Réglage temporairement pour nom d'hôte.local renvoyé de chargement d'une page à la normale.

    OriginalL'auteur Flash Sheridan

  6. 0

    J'ai eu le même problème avec plusieurs LTS Jenkins versions, de fonctionner comme un service Windows. Curieusement, le lancement de google Chrome en mode navigation privée, puis en accédant à la Jenkins URL a Jenkins chargement beaucoup plus rapide. Elle prend environ 1 minute pour que la peinture pour plusieurs utilisateurs, mais en mode navigation privée, il faut moins de 5 secondes. Je ne suis pas sûr pourquoi, la mémoire cache est une question. Effacement du cache résout le problème pour un court laps de temps, mais il commence à nouveau dans un délai de quelques heures, de sorte que le mode navigation privée est le chemin à parcourir.

    OriginalL'auteur Heather