Java heap espace et la perte de messages

Question

Je cours un programme Java sur de nombreux ordinateurs qui interagissent entre eux. Après plusieurs heures (2 à 5 heures), les ordinateurs commencent à défaillir (les threads commencent à tomber dans des impasses, les messages commencent à se perdre - des choses particulières si vous tenez compte du fait que les choses marchaient bien la première heure).

Je soupçonne que c'est parce que j'utilise trop de mémoire. Je suis en cours d'exécution sur linux donc et c'est la sortie correspondante de top:

PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 
30376 username 18 0 976m 132m 6804 S 0 4.0 0:05.60 java 

1. que cela semble élevé?
2. autres idées devraient pourquoi ces bugs se passerait-il .. seraient accueillis

Answer 1

Une autre chose qui peut se passer est que vous êtes à court de connexions. C'est arrivé à un de mes collègues hier.

ulimit -n vous indiquera le nombre de handles de fichiers que vous pouvez ouvrir; netstat -at vous dira combien de prises sont ouvertes. Lorsque le second nombre approche le premier, les tentatives d'ouverture des connexions échoueront.

Dans ce cas particulier, lorsque les connexions étaient encore dans OPEN_WAIT après avoir été utilisé, un nettoyage forcé (Runtime.gc()) a aidé.

Answer 2

Vous pouvez obtenir un aperçu de la tendance de l'utilisation de la mémoire en regardant l'état de la heapsize JVM et en vous connectant régulièrement. À partir de ces journaux, vous pouvez tracer un graphique et voir s'il y a des anomalies. (BTW, un motif de puzzle est les ordures ménagères recueillir le comportement.)

// Memory status 
    Runtime  runtime = Runtime.getRuntime(); 
    final long totalMem = runtime.totalMemory(); 
    final long freeMem = runtime.freeMemory(); 
    if (log.isDebugEnabled()) { 
     log.debug("Memory free=" + freeMem + 
       " used=" + (totalMem - freeMem) + 
       " total=" + totalMem); 
    } 

Answer 3

Problèmes possibles:

1. Ressources (sockets, base de données, etc.) ne sont pas correctement fermé
2. fuites de mémoire (références détenus dans une collection, non fermé Ressources)
3. bugs accès concurrentiel Subtil que apparaît très rarement (qui apparaît après les heures)
4. La perte de message du tampon sur le socket est écrasée avant que vous ayez une chance de le lire ou d'obtenir un message plus grand que le tampon, généralement corrigé en ayant un thread lire socket dès que d ata continue et le met dans une file d'attente de travail que le thread de traitement principal peut gérer