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.
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. –
Sie haben also versucht, die Anwendung mit Java 1.7 oder 1.8 zu starten, und es ist fehlgeschlagen? –
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. –