Jvm prend beaucoup de temps pour résoudre l'adresse IP de l'hôte local

Je semble avoir un problème avec les performances du "test sbt" (qui comprend la recherche de noms d'hôte local / adresses IP) 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 que j'ai faite a duré 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 à essayer ce nouveau macOS, donc je ne peux pas dire si cela ne se produit que sur mon mac ou s'il s'agit d'un problème universel.

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

Malheureusement, cela n'a pas fonctionné pour moi. À l'origine, j'ai essayé cela sur JDK 8u54, puis j'ai essayé de mettre à jour vers JDK 8u102 et cela n'a pas non plus aidé.

PS J'utilise Macbook Pro mi-2015 2,8 GHz i7, 16 Go de RAM, 1 To SSD.

J'ai eu le même problème. Tomcat est passé de 15 secondes à 6 minutes pour initialiser le contexte de printemps 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 quel que soit le nom de votre Mac) sur le /etc/hostsfichier mappé à l' 127.0.0.1adresse, ainsi que ::1ceci:

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 la publication, je crée é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 de nom localhost et à la manière dont la classe java.net.InetAddr récupère les adresses. J'ai vérifié avec quelques collègues et apparemment cela n'arrive pas à tous ceux qui sont passés à Sierra, mais j'étudie toujours les racines de ce changement.

La solution de toute façon était la même qu'antid0te mise en œuvre et fonctionnait immédiatement.

Bonne réponse: Jvm prend beaucoup de temps pour 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

J'ai le même problème. Mon application spring-boot 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 d'InetAddress.getLocalHost (). J'ai changé mon fichier hôte pour ajouter mon nom d'hôte pour 127.0.0.1 et :: 1 et maintenant l'application démarre aussi vite qu'avant.

En activant, par exemple, Préférences système> Partage> Connexion à distance, le nom d'hôte se voit attribuer automatiquement une adresse IP.

Comme les gens voient des problèmes après la mise à niveau, il est logique de supposer que 10.12 a changé la façon dont le nom d'hôte est résolu, 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).

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 qui est déployée sur tomcat. Sur El Capitan, il a démarré 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 du moins cela a pris beaucoup de temps). Je pense que c'est quelque chose autour de la communication réseau, car une simple application de console de test fonctionne bien.

C'était un problème étrange après l'installation de la mise à jour Mac Sierra 10.12 (16A323). Dans le fichier d'hôtes avec le 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 par commande $hostnamen'importe où dans le terminal.

La réponse acceptée m'a aidé! Il suffit d'ajouter ceci pour expliquer 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, cela m'a montré que l'ordinateur pouvait être adressé avec mymac.local

J'ai pensé que c'était l'espace et j'ai 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 à / etc / hosts a alors aidé.

Donc, je suppose quel est le problème réel: 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 le système d'exploitation, puis le nom d'hôte et l'entrée dns ne correspondent pas. (qui peut être corrigé en l'ajoutant manuellement)

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

Lorsque j'ai changé mes noms d'hôtes principaux et Bonjour pour ne contenir que des caractères alphanumériques, cela a résolu le problème. L'idée est venue d'un collègue qui avait lu les conseils quelque part alors qu'il faisait face à un problème similaire (il ne se souvenait plus où).

S'inspirer 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 Bonjour (par souci d'exhaustivité, je n'ai jamais essayé sans cette étape, donc cela pourrait ne pas être nécessaire).

sudo scutil --set LocalHostName <new host name>

par exemple:

sudo scutil --set LocalHostName eggsandwich

Maintenant, redémarrez les processus java avec lesquels vous aviez des problèmes, et j'espère qu'ils ne devraient plus se bloquer.

Sur une note latérale, cela a également résolu un autre problème que j'avais où un nouvel onglet dans Terminal ne démarrerait pas bash dans le même répertoire malgré mes préférences. Je n'ai aucune explication sur pourquoi cela s'est produit, mais je suis très heureux.