Fuite de mémoire dans dolserver.exe ?

[Eudes]

Bonjour,

Je poste ici car techniquement mon anglais est insuffisant pour bien exprimer le sujet de ma recherche.

Sur un VPS dédié de test (1 à 2 personnes de log et peu souvent), avec 4Go de RAM, et quelques applications d'installées (une grosse poignée, rien d'inhabituel, antivirus, MySql, etc.) j'ai eu progressivement, en quelques mois, une saturation de la RAM avec échec de lancement de dolserver.exe, refus de connexion entrante avec VMware ou TeamViewer, plus rien qui veut s'exécuter...

J'ai discuté avec la société qui assure l'hébergement et la maintenance du VPS et ils pointent du doigt une fuite de mémoire de dolserver.exe. Je vais surveiller la consommation de ressources de l'application pour voir si elle vidange parfois ou si elle ne fait que grossir.

Avez-vous des informations à ce sujet ? Je n'ai pas trouvé quels mots-clés employer pour fouiller dans la partie internationale du forum...

Merci !

[Graveen]

Il y a des memory leak dans DOL, mais rien qu'un restart de l'application dolserver.exe ne puisse régler (pour info, sur storm on a un restart tous les 3 jours).

Sur Brittania ca devait être + ou - identique

[Eudes]

Je n'ai jamais regardé à ça mais c'est probable, par contre le serveur redémarre tous les jours sur Britannia il me semble.

Je vais regarder à comment gérer ce redémarrage !

Merci

[HunabKu]

Je n'es jamais eu de plantage de Dol en rapport avec la mémoire que lorsque je testait mes scripts.
Log bien tout dans tes scripts pour détecter les problèmes et vérifie.

[Graveen]

Ne passe pas trop de temps, on a des scripts (windows) qui font déjà le job.

[Eudes]

Ne passe pas trop de temps, on a des scripts (windows) qui font déjà le job.

Avec le planificateur Windows on peut déclencher une action chaque jour, donc un .bat avec quelques lignes de commande qui ferme et relance le serveur ?

On trouve ça dans les Users scripts ? J'ai cherché mais pas trouvé.

[Leodagan]

Il pourrait facilement y avoir des fuites mémoires dans DOL.

La plupart des mécanismes de "cache" sont assez peu efficaces et peu testés cela a tendance a dérailler quand on fait beaucoup de rechargement de données ou que le serveur tourne très longtemps sans interruptions...

Dernièrement j'ai rien repéré de "grossier" dans le Core, du moins avec les paramètres courants...

Il faut peut être en effet faire attention à certain "GameServerScripts" certains pourrait être très mal écrit, peut être même certaines quêtes inclues dans le SVN, mais en tout cas rien qui devrait empêcher un serveur avec quelques dizaines de joueurs de tourner pendant quelques semaines sans reboot...

[HunabKu]

Personnellement je fait très attention à ce genre de choses et je le répète je n'es jamais eu de fuite mémoire avec le code de dol mais souvent avec les script récupérés.

[Eudes]

Re

Mon dédié plante toutes les 36 heures +/-...

J'ai ce message dans le log des erreurs :

08:59:01,894 - [2276] - FATAL - DOL.GS.GameServer - Unhandled exception!
System.Net.Sockets.SocketException (0x80004005): Une opération sur un socket n’a pas pu être effectuée car le système ne disposait pas de suffisamment d’espace dans la mémoire tampon ou parce que la file d’attente était saturée
à System.Net.Sockets.Socket.DoBeginAccept(Socket acceptSocket, Int32 receiveSize, AcceptOverlappedAsyncResult asyncResult)
à System.Net.Sockets.Socket.BeginAccept(Socket acceptSocket, Int32 receiveSize, AsyncCallback callback, Object state)
à System.Net.Sockets.Socket.BeginAccept(AsyncCallback callback, Object state)
à DOL.Network.BaseServer.AcceptCallback(IAsyncResult ar) dans c:\Users\Philippe\Desktop\Copy\dol\DOLBase\Network\BaseServer.cs:ligne 280
à System.Net.LazyAsyncResult.Complete(IntPtr userToken)
à System.Net.ContextAwareResult.CompleteCallback(Object state)
à System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
à System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
à System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
à System.Net.ContextAwareResult.Complete(IntPtr userToken)
à System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
à System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
à System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)

Je n'ai pas de scripts non DOL sauf trois utilisés sur d'autres dédiés et qui ne plantent pas (des scripts Amtenael). A l'issue du plantage, la mémoire physique du dédié reste bloquée à 90% d'utilisation... même une fois toutes les applis (sauf antivirus) éteintes.

Pour info, aucune ligne rouge dans DOLServer.exe.

J'ai écrit à l’hébergeur, j'attends sa réponse, mais de base il pense que cela vient d'une fuite côté serveur de jeu.

Si vous avez des pistes, je suis preneur

[Leodagan]

Bug Driver Carte Réseau peut être :p

Je vois que ça, j'ai jamais vu ce message que ce soit sur mes serveurs Linux ou Windows...

Si DOL ne libérait pas les ressources réseau depuis le temps ça se serait vu :p

Vu l'emplacement de l'erreur sur le "BeginAccept" qui est une fonction VITALE de la connexion Réseau de DOL ça m'étonnerais que ça viennent d'un problème du Code, de plus j'ai déjà vérifié le code réseau quelques fois, il est pas toujours lisible mais il s'appuie sur l'état de l'art en matière de socket Asynchrone (même si c'est pas "dernier cri" comme méthode, il s'agit déjà d'une méthode avancée pour gérer de multiple connexions efficacement !)

La dernière fois que j'ai expérimenté des erreurs réseau incompréhensibles ça venait de l'hébergeur (Attaque DDOS, Contentions) ou du pilote de la carte réseau...

[Eudes]

Merci Leo.

Je suis la montée en charge du VPS. Après 45 minutes de fonctionnement (j'ai reboot) il est passé de 23 à 33% de charge en mémoire physique alors que je n'ai rien qui tourne de pas vital et que DOLServer bouge à peine (de 42600k à 42900k).

Je vais transmettre ta remarque à l'hébergeur. Merci

[HunabKu]

+1 pour une ancienne carte réseaux qui flanche. Avis d'Administrateur réseaux

[Graveen]

De toutes façons, quand tu est à 70%, si tu fais un exit dans la console, tu retombes à 10% utilisé ?

Ensuite, peut-être que c'est une install foireuse du framework .NET (en tous cas tu peux le réinstaller directement pour t'en assurer).

Mais je penche plutot pour un bug des drivers de la NIC virtualisée.

[HunabKu]

Oui ca ressemble à un problème de compatibilité entre ta carte réseau et DoL

[Eudes]

De toutes façons, quand tu est à 70%, si tu fais un exit dans la console, tu retombes à 10% utilisé ?

J'ai laissé tourner plusieurs jours. C'est monté à 88% de charge de la mémoire physique, le serveur n'a pas planté mais je n'accèdais plus à la BD...

Une fois DOLServer.exe coupé, la charge ne baisse pas, ça reste à 88%. Il faut que je redémarre la VM pour libérer les ressources.

Sur exactement la même configuration de VM, Britannia ne bouge pas et pourtant, c'est blindé de scripts customs.

Je vais réinstaller .NET et j'attends de nouveaux retours de l'hébergeurs.

Merci.