Nachdem Dominik ein paar Benchmarks zu verschiedenen opcode Caches für PHP veröffentlich hat, möchte ich auch ein paar Erfahrungen von mir beisteuern.
Ich habe auf verschiedenen (Linux) Servern schon seit langer Zeit (code) Caches für PHP eingesetzt, doch keiner hat bisher so funktioniert, dass ich gut zufrieden war. Die Geschwindigkeit ist dabei weniger das Problem, als die Stabilität.
Bereits seit Wochen Monaten gibt es nun das Problem, dass Java 6 ab Update 4 nicht mehr stabil auf AMD64 Plattformen läuft.
Die JVM crasht – und zieht natürlich die laufende Anwendung, wie z.B. Eclipse unter Java, mit in den Tod. Ein funktionierender Workaround ist tatsächlich den Hotspot Java Optimizer/Compiler zu deaktivieren, dazu ist das Programm/Java mit „-Xint“ zu starten. (Bei Eclipse geht das dann so: eclipse -vmargs -Xint)
Wirklich behoben zu sein scheint das Problem mit Java 6 Update 10 – derzeit ist diese Version im beta Stadium. Java 6 U10 wird auch die erste Version mit dem neuen modularen Java Kernel Konzept sein.
Wer das ganze testen möchte, findet auf der Homepage des Java Early Access program den entsprechenden Download von Java 6 Update 10 beta.
Für Ubuntu ist der Austausch folgendermaßen zu bewerkstelligen:
Fertig. Viel Erfolg beim beta testen.
Update:
Sun ist wohl hinter die Ursache gekommen, auch wenn sich der entsprechende Bugreport so ließt als müsse man erstmal Compilerbau gehört haben. Wie so oft gibt es auch nicht nur den einen Bugreport, sondern z.B. auch diesen – aber immerhin es sieht so aus, als sei eine Lösung in Sicht. Und der Bug schon lange – schlummernd – in der Java Codebasis.
Update 2:
Eine weitere Lösung stellt die Verwendung der IBM Java VM dar. Die gibt es inzwischen – endlich – auch als Java 6 Version und für 64 Bit Windows/Linux Rechner. Bei IBM ist für den Java Download eine Registrierung erforderlich. Die Nutzungsbedingungen sind u.U. andere als bei Sun. IBM Java Download.
Die Java Virtual Machine (JVM) crasht mit dem aktuellen Java 6 noch immer unter Ubuntu Hardy Heron.
Der (geringen) Menge an Bugreports und Blogeinträgen nach scheint es sich um ein eher esoterisches Problem mit der JVM zu handeln. Die betroffenen Applikationen wie Eclipse, Azureus sind SWT Applikationen. Vielleicht ist es also doch ein Problem das nicht der Java JVM angelastet werden sollte.
Jedenfalls berichten einige User, dass die JVM Option „-Xint“ geholfen hat – wenn auch alles „etwas“ langsamer wird.
Kein Wunder, -Xint schaltet nämlich die HotSpot Optimierungen der JVM aus. Aber immerhin wäre es ein passbler workaround gegen die permanenten jvm crashes.
Das aktuelle Java JRE (und JDK) scheinen gehörig überarbeitet worden zu sein – leider nicht unbedingt zum Positiven. Wie auch hier oder in den Bug Reports zu lesen ist, gibt es allerlei Abstürze.
Besonders ärgerlich, wenn man mit Eclipse (Europa) arbeiten möchte, und dies beim Projekt bauen oder Mylin initialisieren einfach die Java Virtual Machine tötet. Auch der Wechsel zum OpenJDK, das für Ubuntu verfügbar ist, hat leider keine Abhilfe schaffen können. Auch RSSowl funktioniert nicht richtig – stürzt aber wenigstens nicht ab – es werden einfach keine Feedeinträge angezeigt.
Als workaround empfehlen einige ein Downgrade auf eine ältere Java Version (vorsicht, hier können sich Sicherheitslücken einschleichen!) – oder eine 32bit Version zu verwenden. (Der Bug scheint sich lediglich bei AMD64 bzw. 64bit Intel Architektur auszuwirken.)
Ich versuche es mit dem Angriff nach vorne – Eclipse ganymed, dessen Startlogo fast suggeriert, dass bei „Ganymed“ ein Buchstabe vergessen wurde.
Update:
Also alle guten Vorsätzen und Versuchen haben nicht gefruchtet – allein ein Downgrade der Java Installation auf Ubuntu Gutsy 1.6.0_03 half ein stabiles Java zu erhalten. Da der Bug schon eine Weile bekannt ist, mache ich mir keine großen Hoffnungen, dass bis zum Erscheinen von Hardy Heron das Problem behoben ist.
Neue Kommentare