Forum EUserv
VPS/vServer - virtual private server => vServer allgemein => Thema gestartet von: _Daniel_ am 14.März 2012, 11:58:06
-
Ich habe seit kurzem einen V-Server Winterspezial 2012 mit garantierten 4GB Arbeitsspeicher.
Meine Idee darunter einen Minecraft-Server zu betreiben für 2-3 Spieler scheitert jedoch kläglich.
Java stürzt immer mit der gleichen Fehlermeldung ab:
# Internal Error (synchronizer.cpp:1401), pid=7360, tid=140375766447872
# guarantee(mid->header()->is_neutral()) failed: invariant
Ich habe es bereits mit der Sun Java 1.6.0 sowie mit der Java von OpenJDK getestet.
Google verweist auf Fehler in virtuzzo bzw. OpenVZ hin, z.B. das ermitteln der verfügbaren CPU nicht korrekt, maximaler Arbeitsspeicher kann nicht ermittelt werden, usw.
Ich vermute das dieser Javafehler auch mit der fehlerhaften Anzeigeproblematik des maximalen Arbeitsspeicher zusammenhängt.
Was kann man dort noch tun?
Unter meinem Betaserver lief minecraft ohne Probleme, bis auf das zu wenig RAM verfügbar war.
-
Relevant innerhalb eine VE sind die user_beancounter . Wenn Sie hier einen Wert reissen, kann es zu Fehlern kommen. Wenn nicht, ist seitens der VE alles i.O.
-
Nein, ein Absturz mit dieser Fehlermeldung erreicht keinen Wert.
Allerdings ein einfaches:
java -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
bricht mit einer Fehlermeldung ab und erhöht diesen Wert:
privvmpages 169000 773798 1048576 1061376 192
Auch ein Aufruf mit -Xmx und -Xms beschränkt auf 512MB:
java -version -Xmx512M -Xms512M
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
funktioniert nicht.
Der Wert für den garantierten Speicher ist korrekt.
vmguarpages 0 0 1048576 1061376 0
-
Hallo,
ich habe derzeit einen V-Server Winterspezial mit 4GB garantiertem Arbeitsspeicher. Leider schaffe ich es nicht die zugesicherten 4GB Arbeitsspeicher zu nutzen.
Ein Test hat ergeben das ich maximal 2,7 GB Arbeitsspeicher belegen kann.
free -m
total used free shared buffers cached
Mem: 8388607 2635 8385972 0 0 13
-/+ buffers/cache: 2622 8385985
Swap: 512 512 0
cat /proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt
20058: kmemsize 21571964 25772032 31875611 35028144 0
lockedpages 0 1 2059 2059 0
privvmpages 960311 996896 1048576 1061376 0
shmpages 1938 1954 50000 50000 0
dummy 0 0 0 0 0
numproc 88 102 300 300 0
physpages 651784 707974 0 2147483647 0
vmguarpages 0 0 1048576 1061376 0
oomguarpages 807073 836346 131072 2147483647 0
numtcpsock 15 27 400 500 0
numflock 6 10 100 100 0
numpty 3 3 128 128 0
numsiginfo 3 9 1024 1024 0
tcpsndbuf 296744 506024 6584420 6594420 0
tcprcvbuf 286976 675424 6584420 6594420 0
othersockbuf 190592 320808 4923119 4933119 0
dgramrcvbuf 1288 2576 4923119 4933119 0
numothersock 154 175 400 500 0
dcachesize 3565141 4805083 6155930 6340608 0
numfile 838 970 4096 4096 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 24 24 2147483647 2147483647 0
top - 20:59:04 up 31 min, 3 users, load average: 3.50, 7.11, 7.61
Tasks: 40 total, 1 running, 39 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.7%us, 1.2%sy, 0.0%ni, 0.0%id, 98.1%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8589934588k total, 2575696k used, 8587358892k free, 0k buffers
Swap: 524288k total, 524288k used, 0k free, 10460k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
901 tss 20 0 131m 2208 1168 S 0.7 0.0 0:16.17 ts3server_linux
1045 root 20 0 18944 852 572 R 0.3 0.0 0:01.17 top
1 root 20 0 8360 68 44 S 0.0 0.0 0:00.07 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd/20058
3 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khelper/20058
314 root 20 0 60312 416 188 S 0.0 0.0 0:00.02 rsyslogd
330 root 20 0 181m 336 200 S 0.0 0.0 0:00.14 apache2
351 root 20 0 20912 324 224 S 0.0 0.0 0:00.04 cron
356 messageb 20 0 23272 8 4 S 0.0 0.0 0:00.00 dbus-daemon
363 www-data 20 0 183m 5308 1808 S 0.0 0.0 0:00.49 apache2
364 www-data 20 0 194m 9280 1804 S 0.0 0.0 0:00.74 apache2
368 avahi 20 0 33768 8 4 S 0.0 0.0 0:00.00 avahi-daemon
369 avahi 20 0 33768 4 0 S 0.0 0.0 0:00.00 avahi-daemon
394 root 20 0 3960 8 4 S 0.0 0.0 0:00.00 mysqld_safe
505 mysql 20 0 316m 7196 1968 S 0.0 0.0 0:01.75 mysqld
506 root 20 0 3860 8 4 S 0.0 0.0 0:00.00 logger
570 proftpd 20 0 94852 248 148 S 0.0 0.0 0:00.13 proftpd
Privvmpages schaffe ich nicht ans Limit.
Hintergrund der Aktion ist, ich schaffe es nicht einen MineCraft-Server für 2 Benutzer stabil zu betreiben.
Entweder schläft der Prozess ein, oder er stürzt mit kryptischen Java-Fehlermeldungen ab.
Ich habe Sun Java 1.6.0, 1.7.0 sowie OpenJDK 1.6.0 getestet.
/proc/user_beancounters haben keinen failcnt
-
Ich habe den selben vServer Tarif. Und bei mir läuft ebenfalls ein MC Server - ohne Probleme. Ich denke eher, du hast dich bei irgendeiner Einstellung vertan.
Das mit den 2.7GB könnte noch der Anzeigefehler sein.
Im übrigen sind 2.7GB Ram mehr als genug für einen MC Server!
-
Die Einstellung habe ich alles im Standard belassen, gestartet wird mit
java -Xmx1024M -Xms1024M -jar minecraft.jar
Der Start verläuft normal, während dem Spiel stürzt er ab. Läuft er länger ohne das ich eingeloggt bin friert der Prozess ein.
Bei einem Absturz äußert sich das durch:
# Internal Error (synchronizer.cpp:1401), pid=7360, tid=140375766447872
# guarantee(mid->header()->is_neutral()) failed: invariant
Einen failcnt user_beancounters habe ich danach keinen.
Habe bereits mehrmals eine neue "World" erstellt um dort Fehler auszuschließen.
Als Image nutze ich Debian 6 64bit.
Ich würde gern den Hostnode wechseln. Der aktuelle Hostnode hat eine Intel-CPU, in der Beta hatte ich eine AMD-CPU. In der Beta lief der Test-Minecraft-Server (-Xms und Xmx mit 384M) für einen Spieler ohne Probleme. Allerdings war dort natürlich zu wenig RAM vorhanden.
-
Hallo,
auf dem vServer ist folgendes installiert:
Fedora 14
tomcat 5.5.28
java: jre1.6.0_31
Seit ca. einem halben Jahr läuft das System in der genannten Konfiguration problemlos. Letzte Woche habe ich tomcat "runtergefahren" ('./catalina.sh stop') und wieder gestartet ('./catalina.sh start'). Tomcat läßt sich jedoch nicht mehr korrekt "hochfahren". Salop gesagt: tomcat hängt sich während des Startprozesses fast jedesmal auf. Die Log-Dateien geben keinen konkreten Hinweis, da tomcat unvermittelt den Startprozess abbricht und keine Exceptions auswirft. Teileweise sind die Log-Dateien von tomcat auch komplett leer - jenachdem in welcher Phase des Startes tomcat abbricht - oder die Einträge in den Logdateien enden plötzlich. In seltenen Fällen gelingt es tomcat zu starten.
Im Anhang befindet sich die Log-Datei 'catalina.out'. Der Startprozess wurde hier ausnahmsweise nicht aprupt gestopt, sonder es wurde noch eine Exception ausgeworfen. Die Fehlermeldung läßt den Schluss zu, dass mit der Speicherverwaltung von Java etwas nicht stimmt. Ich habe auch schon mit der Java-Option 'Xmx..' experimentiert: 'CATALINA_OPTS="-Xmx64m"' (auch mit verschiedenen Speichergrößen: 64, 128, 512, 1024).
Das merkwürde für mich ist: das komplette System lief ein halbes Jahr problemlos, der Fehler kam völlig unvermittelt, und tritt scheinbar zufällig auf (in seltenen Fällen - ca. 2%, kann ich tomcat sogar komplett starten).
Wer kann helfen?
Beste Grüße
Mekron
-
Das Problem kann ich mit einem anderem Tool bestaetigen. Der Startvorgang bricht immer an unterschiedlichen Stellen ab. Selten (1-2%) kommt man bis zum kompletten Programmstart. Spaetestens nach 30 Sekunden faellt das Programm dann zusammen.
Auf den Beta-V-Servern hat es seinerzeit funktioniert.
Aus meiner Sicht haengt das mit der Speicherverwaltung zusammen.
Ueber eine Loesung wuerde ich mich SEHR freuen!!
-
Wie an andere Stelle schon geschrieben haengt das wohl mit dem Speichermanagement zusammen. Die Parameterorgien kann man vergessen.
Interessante Infos habe ich hier (http://forums.vpslink.com/linux/1327-java-could-not-reserve-enough-space-object-heap.html) gefunden:
Sadly, this isn't a problem with available memory. I have gotten Java to run fine on a VM at home that only has 128MB of RAM. The problem appears to be that OpenVZ by default shows the entire available ram on the hardware to the VM, and Java gets terribly, horribly confused about this. No amount of heap-space and garbage-collection related command line arguments will resolve this issue. I've seen some forum postings about changing the way OpenVZ reports system memory to the virtual machines, but of course that requires root access to the host OS.
Diesem Hinweis sollte das Serverteam mal nachgehen.
Vielleicht kann jemand der Admins einfach mal Java auf so einem vServer installieren und dann "java -version" versuchen zu starten.
-
Das Thema muss ich nochmals aufwaermen.
Ich habe wieder mal versucht Java zu starten. Wie beschrieben bricht es immer ab oder kommt noch hoch.
Da sollte wirklich mal jemand was unternehmen. Ich muss immer auf einen anderen Server ausweichen, da stellt sich irgendwann die Frage ob es hier noch Sinn macht.
Viele Gruesse