2016-06-15 13 views
0

Wir haben eine Anwendung, die einmal täglich den gesamten zugewiesenen Heap-Speicher verwendet. Ich habe einen Speicherauszug von Heap-Speicherplatz erstellt, um mir zu helfen, die Ursache dieses Problems zu finden, dass es auf diesem Link https://drive.google.com/file/d/0BwMd9KDnQRfQT3dzRTZfUWdjMU0/view?usp=sharing verfügbar ist. Ich glaube, dass die Anwendung schlecht implementiert ist, oder etwas mit der DB4O-Technologie verbunden ist und ihre Objekte zwischen Client und Server gesendet werden, oder Verbindungen, die für den Server geöffnet sind, nachdem Benutzer Daten zwischen ihren Systemen und Servern synchronisieren. Der Dienst hat keinen Fehler: Nicht genügend Arbeitsspeicher: Heapspeicher, aber ich befolge Ihre Ressourcenzuweisung, um das zu sagen.Heap-Speicherplatz - Speicherverwaltung

ich die Anwendung mit diesem Shell-Skript ...

set +x 

export BRANCHOFFICE_HOME=/bat/orquestra/branchoffice/live18 
cd ${BRANCHOFFICE_HOME} 
echo BRANCHOFFICE_HOME = ${BRANCHOFFICE_HOME} 

# classpath 
OQT_CLASSPATH=${BRANCHOFFICE_HOME}/classes/:${BRANCHOFFICE_HOME}/classes/branchoffice.jar 

for libFile in ${BRANCHOFFICE_HOME}/lib/*.jar 
do 
    OQT_CLASSPATH=${OQT_CLASSPATH}:${libFile} 
done 

export OQT_CLASSPATH 
echo OQT_CLASSPATH = ${OQT_CLASSPATH} 

# JVM arguments 
JAVA_ARGS=-server 
JAVA_ARGS=${JAVA_ARGS}" -Xms2048m" 
JAVA_ARGS=${JAVA_ARGS}" -Xmx2048m" 
JAVA_ARGS=${JAVA_ARGS}" -XX:+UseLargePages" 
JAVA_ARGS=${JAVA_ARGS}" -Duser.timezone=America/Sao_Paulo" 
JAVA_ARGS=${JAVA_ARGS}" -Duser.country=BR" 
JAVA_ARGS=${JAVA_ARGS}" -Duser.language=pt" 
JAVA_ARGS=${JAVA_ARGS}" -cp "${OQT_CLASSPATH} 
JAVA_ARGS=${JAVA_ARGS}" -Dcom.sun.management.jmxremote=synchengine.SynchEngine" 
JAVA_ARGS=${JAVA_ARGS}" -Dcom.sun.management.jmxremote.port=1207" 
JAVA_ARGS=${JAVA_ARGS}" -Dcom.sun.management.jmxremote.password.file="${BRANCHOFFICE_HOME}"/config/passwordFile" 
JAVA_ARGS=${JAVA_ARGS}" -Dcom.sun.management.jmxremote.access.file="${BRANCHOFFICE_HOME}"/config/accessFile" 
JAVA_ARGS=${JAVA_ARGS}" -Dcom.sun.management.snmp.acl.file="${BRANCHOFFICE_HOME}"/config/acl" 
JAVA_ARGS=${JAVA_ARGS}" -Dcom.sun.management.jmxremote.ssl=false" 
export JAVA_ARGS 
echo JAVA_ARGS = ${JAVA_ARGS} 

# APP arguments 
export APP_ARGS=${BRANCHOFFICE_HOME}/config/SynchEngine.xml 
echo APP_ARGS = ${APP_ARGS} 

echo Starting Synchronization Engine 

fange ich irgendwelche Tipps oder Unterstützung haben möchte, da die Anwendung sehr groß ist.

Server ...

  • Architektur: x86_64
  • CPU op-Modus (s): 32-Bit, 64-Bit-
  • Byte-Reihenfolge: Little Endian
  • CPU (s) : 4
  • Online-CPU (en): 0-3
  • Thread (s) pro Kern: 1
  • Core (e) pro Sockel: 1
  • Socket (s): 4
  • NUMA-Knoten (s): 1
  • Vendor ID: Genuine
  • CPU Familie: 6
  • Modell: 42
  • Stepping: 2
  • CPU MHz : 2294.472
  • BogoMIPS: 4588,94
  • Hypervisor-Anbieter: VMware
  • Virtualisierungstyp:
  • L1d cache: 32K
  • L1i cache: 32K
  • L2-Cache: 256K
  • L3-Cache: 15360K
  • NUMA Node0 CPU (s): 0-3

  • Linux-Version 3.0.101-0.21-Standard (geeko @ buildhost) (gcc Version 4.3.4 [gcc-4_3-Zweig Revision 152973] (SUSE Linux)) # 1 SMP Mo Apr 7 12:32:42 UTC 2014 (172cdff)

  • Java Version: 1.5.0_22 x64
  • DB4O Version: 6,1

Benötigen Sie mehr Informationen Ich bin verfügbar, dankbar für jeden, der helfen kann.

Antwort

0

Verwenden Sie JVisualVM (im Java-Verzeichnis), um die Anwendung während der Ausführung zu profilieren. Dann können Sie die Gesamtspeicherbelegung sehen und auch den Speicherbedarf verschiedener Objekte beobachten.

+0

Die Anwendung verwendet die Java-Version 1.5, und leider können wir die Version von Java aus diesem Grund nicht ändern, weil ein anderer Lieferant der Serveradministrator ist. –

+0

Sie haben also versucht, die Anwendung mit Java 1.7 oder 1.8 zu starten, und es ist fehlgeschlagen? –

+0

Nein, lokal mit diesen Versionen von Java funktioniert es, aber nicht zu wenig Speicher. Wir haben nicht verstanden, was auf dem Server in unserer Umgebung vorkommt. –