Signalr: Fuite de mémoire

Deuxième à cela. Il semble qu'il remplisse la mémoire avec des chaînes comme hc-Realtime.20e13545-e77c-4873-9d55-fe9c14e3a058
(le guid varie selon l'instance bien sûr), mais après quelques minutes de profilage, j'ai quelques centaines d'instances de chaîne identique à celle en mémoire

semble cependant que cette mémoire est conservée lorsque le client est déconnecté (au moins partiellement). Mais comme dans notre scénario les clients sont connectés assez longtemps (en général, on pourrait dire 24h/24 et 7j/7), le stress de la mémoire augmente constamment.

Quelle est la taille des messages ?

nous essayons de les garder petits - lors de la dernière exécution, en moyenne 300 caractères (charge utile), avec un maximum de 1742 caractères (nous n'envoyons que des chaînes simples, pas de json du côté du signaleur), parfois il regarde jusqu'à dire 5k

J'ai le même problème (v2.2.0). Fonctionne maintenant depuis trois jours et les instances DefaultSubscription augmentent régulièrement.

Nous rencontrons ici le même problème. Comment régler ce genre de problème ? (Fuite de mémoire)

Ce profil de trace de points d'origine semble suspect. Pourquoi y a-t-il tant d'instances de bus de messages. Il devrait y en avoir un.

Nous voyons la même chose ici. (v2.2.0)

Mes tests montrent que cela semble être lié à la mémoire épinglée que le GC ne peut pas collecter. Lorsque notre application est exposée à 1 à 2 000 clients se connectant dans un court laps de temps, la mémoire semble être épinglée très rapidement. J'ai même reçu des OutOfMemoryExceptions aux heures de pointe.

Le profileur Ants montre que la mémoire inutilisée allouée à .NET augmente régulièrement. Il pointe vers le tableau d'octets utilisé dans Microsoft.AspNet.SignalR.Messaging.Message

Comment peut-on contourner cela ? Est-il possible de modifier les tailles de tampon initiales ou la taille des fragments de message via l'API ou quelque chose comme ça ?

Ce problème a été fermé dans le cadre du nettoyage du problème, comme décrit dans https://blogs.msdn.microsoft.com/webdev/2018/09/17/the-future-of-asp-net-signalr/. Si vous rencontrez toujours ce problème, n'hésitez pas à rouvrir et à commenter pour nous le faire savoir ! Nous sommes toujours intéressés d'avoir de vos nouvelles, l'arriéré est devenu un peu important et nous avons dû faire un gros nettoyage pour reprendre le dessus. Merci pour vos commentaires continus !