Esta mañana, como todas las demás, me he puesto a picar código y me he dado cuenta de que, cada vez que hacía algo en Visual Studio, éste comenzaba a usar un 30% de CPU y se quedaba ahí un buen rato aunque no estuviera haciendo nada.
Algo muy sospechoso ocurre con Visual Studio 2015, y aquí os voy a contar hasta donde han llegado mis investigaciones.
ACTUALIZACIÓN: El uso de la CPU se debe a ReSharper. Desinstalándolo (ojo si lo deshabilitas sigue pasando) deja de usar esa tremenda cantidad de CPU). Y de hecho, la cantidad de conexiones en el proceso descrito aquí baja sensiblemente, así como el tráfico de datos, al razonable nivel que puede significar la actualización de la configuración y la sincronización entre equipos.
Todo comenzó con la drástica subida de revoluciones del ventilador de mi portátil cada vez que pulsaba un simple “enter” o me desplazaba por el código fuente de mi proyecto. Eso hizo que me diera una vuelta por el Administrador de Tareas y viera cómo Visual Studio disparaba el uso de CPU.
Pero como el Administrador de Tareas es una herramienta muy básica, decidí emplear la increíblemente buena Process Explorer. Ahí vi que dentro del árbol de procesos de Visual Studio, había uno que era el causante de todo el consumo de CPU. Se llama “VsHub.exe” y lo firma Microsoft. Ved la captura.
Veréis cómo la devenv.exe consume el 85% de CPU y el único causante de ello es el programa que os digo. A la derecha os muestro que la aplicación tiene su firma correcta, por lo que no he sufrido ningún tipo de pirateo.
De ahí pasé a buscar por internet, aunque la pestaña de TCP/IP resulta un tanto curiosa. Ved las dos siguientes capturas:
Aparte de conexiones locales, hay algunas que salen al exterior. ¿Al exterior? Sí. Hagamos una colecta de esas IP:
- 68.232.34.200
- 168.62.105.45
- 65.52.55.39
- 65.52.0.51
- 191.232.139.254
- 23.102.160.172 (esta no está en la captura, la pillé antes)
Vemos como la mayoría se conectan por HTTPS, que es el protocolo encriptado de HTTP para que nadie pueda ver qué se envía y como. En principio no se trata de nada extraordinario ya que en la actualidad la mayoría de funcionalidad Web se hace así.
Luego hice un tracert rápido para ver por dónde pasaban esas IP:
Suficiente con tres. Todas pasan a servidores de Microsoft. Como la captura principal, llegan a un punto en el que dejan de responder a los ping y, cosa curiosa, el servidor en cuestión corta toda comunicación con mi Visual Studio.
Tampoco es raro ya que también suele ser lo habitual. Cuando un servidor detecta que le están intentando meter mano, corta y que te den. Solo sospechoso.
Visto lo visto, el siguiente paso es hacer un WHOIS IP, aunque ya tengo claro a quién pertenecen esas IP. En lugar de poner capturas, os dejo que lo miréis vosotros:
La mayoría están registradas a Microsoft. La primera de ellas lo está a una empresa que se llama EdgeCast Networks, que es una CDN. Quizás la primera sí que sea válida y pertenezca a una consulta para determinar si tengo actualizaciones o no. Claro, las otras podrían serlo tembién, pero ¿se tiene que comprobar cada vez que hago alguna tarea en Visual Studio?
—
Finalmente una última comprobación, aunque sirva de poco ya que al ser la comunicación por HTTPS, no se puede ver nada de lo que se envía y recibe a través de esas IP:
En fin, que me pregunto qué cojones hace Microsoft enviando cosas y usando mi tiempo de CPU…
(NOTA: todo el problema también podría venir de las últimas dos actualizaciones de Windows 10, las de ayer, porque antes al menos el consumo de CPU no se disparaba -e ignoro si enviaba algo o no-. Ya sabéis, gato escaldado del agua fría huye. Si una reparación de Visual Studio 2015 no resuelve el problema del uso de CPU, otra razón más para volver a Windows 8.1).
21 Comentarios
Casi seguro que sea cosa de Win10, acabo de hacer la prueba sobre Win7 y, aunque si que ese proceso tiene una sola conexión abierta, no he visto ninguna actividad especial.
Pero la tiene hacia afuera, o solo en localhost.
Es que esa es la pregunta.
Si es hacia afuera, ponte a hacer ping desde una consola a ver si la cierra cuando detecta que lo estás mirando.
Hacia afuera …
Mirando mejor … una de cada. La externa a 65.52.0.51, pero ésta mañana era otra. y no, no se cierra al hacer ping contínuo
Esa está en el rango de la reserva de MS.
Parece ser que ese módulo es para la sincronización en la nube de tus configuraciones. Si lees los demás comentarios y la entrada actualizada verás que el culpable es Resharper, que vuelve loco a Visual Studio. De hecho una de cada dos, carga una cosa que se llama DrWatson2 que si no me equivoco es un analizador en tiempo real de rendimiento y de “ñapas”…
Les he contactado. A ver qué me dicen.
Hombre teniendo en cuenta que Visual studio Hub , es la herramienta que soporta la comunicación a través de Visual Studio y sincronización es normal la conexión. Otra cosa es lo de cpu.
Al igual tienes un problema en una máquina y automáticamente se sincronizan con el resto visual studio de otras maquinas , si utilizas la misma cuenta microsoft y esto puede que genere el problema de cpu. No suelo usar visual studio para uso profesional, pero seguramente existe alguna manera de restablecer / eliminar esta configuración de itinerancia.
¿Y cómo sabes que es eso? ¿Dónde está documentado? Yo no lo veo por ningún lado, y no soy el único que protesta.
http://stackoverflow.com/questions/31452435/how-do-i-disable-vshub-exe-in-the-system-tray
Pq leo mucho jajaja , hablando en serio lo escuche por algun video relacionado con sincronización con visual studio, tambien creo que esta relacionado con el visual studio online.
por aqui tienes algo, auqnue ya te digo Visual studio no me lo conozco.
http://blogs.msdn.com/b/visualstudio/archive/2014/08/18/visual-studio-14-ctp-3-released.aspx?PageIndex=2&wa=wsignin1.0#10551844
Al final econtré al culpable. Se llama ReSharper y me costó cerca de 200 lauros. SI no lo arreglan, que me devuelvan el dinero.
Ya me he puesto en contacto con ellos.
¿Y resharper se conecta a los servidores de microsoft?
Para ver el trafico https, ¿has probado a echar un vistazo con el fiddler?
Pues no sé si se conecta o no, o si es un efecto latetal, pero el hecho es que con resharper, hay más flujo de datos. Se me podría ocurrir que Visual Studio detectara algún problema y enviara datos a MS para informar de qué está pasando. Es lo habitual en la recoelcción de errores y bugs.
El trático lo he monitorizado con WireShark (viene a ser lo mismo que fiddler), que lo tengo instalado por otros motivos. Me da la negociación de HTTPS, envío de varios paquetes encriptados, nueva negociación.
(A ver, que no me estoy quejando de que VS envíe datos a MS, me quejo de que eso tumbe el ordenador).
A ver qué me dicen los de Resharper, pero si no se arregla pediré que me devuelvan la pasta de la suscripción.
Algunas veces no me dejáis de sorprender. Resharper no funciona bien desde la versión 2012 en adelante, para la 2012 todavía se hace tolerable, pero para la 2013, ya tenías que desinstalarlo. Y por lo que cuentas para la 2015, ya es exagerado. pensé que con la última versión (que evidentemente no he podido comprarme, por los cambios de precios) lo habrían arreglado, pero veo que no.
Yo lo probé en demo y como vi que iba bien, compré una actualización que me caducaba en julio (así no es tan cara), pero a los dos días de comprada, empezó a dar por culo.
De momento no me han respondido, y como tarden pido la devolución del dinero.
Visual Assist (de Whole Tomato) es un poco peor, pero es muchísimo más ligera (y barata).
Por fin, el problema lo VS or W10?
Ni uno ni el otro. Se llama ReSharper y es una extensión de Visual Studio. Son increíbles analizando código en tiempo real pero una mierda haciendo la utilidad en sí
Deberías ponerlo en primera línea del artículo. Vaya para ser justos
En primera línea
Lo puse en cuanto encontré al culpable, en la entradilla.
Con el fiddler puedes descifrar el trafico https y ya salimos del todo de dudas….
Mañana miro cómo se hace.
Rafa, como dice Citanic mas en primera línea que me lo he papao todo. Jajaja