web-dev-qa-db-fra.com

Jvm prend beaucoup de temps pour résoudre l'adresse IP pour localhost

Je semble avoir un problème avec les performances de "sbt test" après la mise à niveau vers macOS Sierra. Sur une version précédente d’OS X, cela prenait environ 40 à 50 secondes. Les temps de macOS Sierra sont beaucoup plus élevés que cela. La dernière course était d'environ 15 minutes. Les temps de compilation sont à peu près les mêmes que sur "El Capitan".

Je suis le seul de mon équipe à avoir essayé ce nouveau macOS, je ne peux donc pas dire si cela se produit uniquement sur mon Mac ou si c'est un problème universel.

Mon collègue avait un problème similaire sur Ubuntu et était lié à la génération de nombres aléatoires ralentissant les tests - Temps de réponse du service lents: Java SecureRandom &/dev/random

Malheureusement, cela n'a pas fonctionné pour moi. Au départ, j’ai essayé cela sur JDK 8u54 puis j’ai essayé de mettre à jour JDK 8u102 et cela n’a pas aidé.

P.S. J'utilise Macbook Pro Mid-2015 2.8GHz i7, 16 Go de RAM, 1 To de SSD.

100
Tomasz Mikuś

J'ai eu le même problème. Tomcat est passé de 15 secondes à 6 minutes pour initialiser le contexte printanier après la mise à niveau ... la désactivation de csrutils n'a pas résolu le problème pour moi.

J'ai résolu le problème en ajoutant mon nom d'hôte Mac (c'est-à-dire Macbook.local ou le nom de votre Mac) sur le fichier /etc/hosts mappé sur l'adresse 127.0.0.1 ainsi que ::1 comme ceci:

127.0.0.1   localhost mbpro.local
::1         localhost mbpro.local

Si vous êtes intéressé, vous pouvez trouver quelques détails sur le problème et la solution ici: https://thoeni.io/post/macos-sierra-Java/

Sur le post, je fais également un lien vers un projet github pour aider à résoudre le problème et à valider la solution.

Le problème est lié (je crois) au fonctionnement de la résolution du nom de l'hôte local et à la manière dont la classe Java.net.InetAddr récupère les adresses. J'ai vérifié auprès de quelques collègues et, apparemment, cela n'arrive pas à tous ceux qui ont migré vers Sierra, mais je suis toujours en train d'analyser les racines de ce changement.

La solution était de toute façon la même que antid0te implémentée et fonctionnait immédiatement.

291
thoeni

Bonne réponse: Jvm met longtemps à résoudre l'adresse IP de l'hôte local

Pour les paresseux:

Sudo sed -i bak "s^127\.0\.0\.1.*^127.0.0.1 localhost $(hostname)^g" /etc/hosts
Sudo sed -i bak "s^::1.*^::1 localhost $(hostname)^g" /etc/hosts
Sudo ifconfig en0 down
Sudo ifconfig en0 up
36
camikiller

J'ai le même problème. Mon application printanière prend 60 secondes pour démarrer sur Sierra contre 25 secondes sur Yosemite.

Lors du débogage, j'ai réalisé que le problème venait de InetAddress.getLocalHost (). J'ai changé mon fichier hôte pour ajouter mon nom d'hôte pour 127.0.0.1 et :: 1 et l'application démarre aussi vite qu'avant.

6
Antid0te

Activer par exemple Préférences Système> Partage> Connexion à distance, une adresse IP est automatiquement attribuée au nom d'hôte.

Lorsque les utilisateurs constatent des problèmes après la mise à niveau, il est logique de supposer que la résolution du nom d’hôte a été modifiée en 10.12; c’est-à-dire qu'au moins avec 10.11, le nom d’hôte est toujours résolu, tandis qu’avec 10.12, il n’est résolu que si un service est activé dans Préférences Système>. Partage (quelqu'un avec 10.11 pourrait le confirmer).

2
jurajw

C’était un problème étrange après l’installation de la mise à jour de Mac Sierra 10.12 (16A323). Dans le fichier hosts avec ci-dessous, trié le problème.

::1         localhost <myhostname>.local   <--- Was already present
127.0.0.1   localhost <myhostname>.local   <--- Solved the Tomcat loading issue

Vous pouvez obtenir le myhostname à l'aide de la commande $hostname n'importe où dans le terminal.

1
Sidd Gautama

Je pense que c'est un problème général avec le nouveau système d'exploitation. J'ai un problème similaire: j'ai une application Web déployée sur Tomcat. Sur El Capitan, cela a commencé en 10 secondes, maintenant cela prend 95 secondes et le client (une application de bureau basée sur Swing) ne peut pas s'y connecter (ou au moins cela a pris beaucoup de temps). Je pense que cela concerne les communications réseau, car une simple application de console de test fonctionne bien.

1
Andras Gyetvan

La réponse acceptée m'a aidé! Ajoutons simplement ceci en expliquant ce que je pense que le problème pour moi était:

Mon nom d'hôte était quelque chose comme "Mon Mac" qui n'a pas pu être résolu. Dans les paramètres, il m'a montré que l'ordinateur pouvait être adressé avec mymac.local

Je pensais que c'était l'espace et renommé mon mac en "my.mac" mais même cela n'a pas aidé puisque le DNS ajouté automatiquement était toujours mymac.local

L'ajout de my.mac au fichier/etc/hosts a ensuite aidé.

Donc, je suppose que le problème réel est: Cela ne se produit que lorsque le nom de votre ordinateur contient tout ce qui n'est pas une lettre. Ceci est automatiquement supprimé par l'OS, puis le nom d'hôte et l'entrée DNS ne correspondent pas. (qui peut être corrigé en l'ajoutant manuellement)

0
Arne

J'ai rencontré le même problème sur mon Mac.

Lorsque j'ai modifié les noms d'hôte principal et Bonjour pour qu'ils ne contiennent que des caractères alphanumériques, le problème a été résolu. L'idée est venue d'un collègue qui avait lu le conseil quelque part alors qu'il était confronté à un problème similaire (il ne se souvenait plus où).

S'inspirant de ce guide , voici les étapes que j'ai suivies:

Tout d'abord, changez le nom d'hôte principal

Sudo scutil --set HostName <new Host name>

par exemple.:

Sudo scutil --set HostName eggsandwich

Ensuite, changez le nom d’hôte de Bonjour (par souci d’exhaustivité, je n’ai jamais essayé sans cette étape, ce qui pourrait bien être inutile).

Sudo scutil --set LocalHostName <new Host name>

par exemple.:

Sudo scutil --set LocalHostName eggsandwich

Relancez maintenant les processus Java avec lesquels vous rencontriez des problèmes et espérons qu'ils ne puissent plus être bloqués.

Sur une note de côté, cela a également résolu un autre problème que j'ai eu où un nouvel onglet dans Terminal ne commencerait pas bash dans le même répertoire malgré mes préférences. Je n'ai aucune explication sur la raison pour laquelle cela s'est passé, mais j'en suis très heureux.

0
Erik Madsen