Den ersten der zwei Zusatzparameter hast du OHNE den Schreibfehler/Smiley eingesetzt, ja? Denn "-XXermSize" ist nicht vollständig. Wobei du den (also -XX, Doppelpunkt, PermSize) im Prinzip auch weglassen kannst und einfach nur -XX:MaxPermSize auf einen genügend hohen Wert stellst. Der PermGen-bezogene OOM kommt im Normalfall, wenn selbst im Full Collect darin nichts mehr freigeräumt werden kann. Also kurz davor dürfte es vermutlich zu recht heftigen Lags für die Spieler gekommen sein, da die Full Collects vermutlich immer häufiger wurden. Die Ursache ist also aller Voraussicht nach schlicht darin, dass diese Generation zu klein ausfällt. Für den unwahrscheinlichen Fall, dass es sich um ein MemoryLeak handeln könnte, stellst du erstmal nur den einen Parameter ein, nämlich -XX:MaxPermSize=1G, was ein voraussichtlich viel zu hoher Wert ist, den du erstmal testest. Sollte es da immernoch zum OOM kommen, kriegen wir schon noch raus, an welchem Plugin oder an welchem Plugin-Mix es liegt. Aber vermutlich kannst du die permanente Generation ohne Probleme auf die bereits empfohlenen 512M oder noch weniger senken. Dennoch lieber erstmal den von mir empfohlenen Extremwert testen.
Zudem solltest du auch mal GC-Logs anfertigen, damit nachvollzogen werden kann, was über die Laufzeit hinweg passiert. Bitte folgende Parameter anfügen und das so entstehende gc.log (wird mit jedem MC-Serverneustart neu angelegt) im Thread zeigen, bzw. die Textdatei im Thread verlinken:
-Xloggc:gc.log -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintAdaptiveSizePolicy -XX:+PrintPromotionFailure
Unter Umständen wäre es auch ratsam, mal ein paar GC-Parameter einzufügen, um nicht auf die für MC unpassenden Standardeinstellungen zu vertrauen - etwa den CMS (ruhig im inkrementellen Modus), um den, wenn er bei gewisser Heap-Auslastung regulär triggert, direkt auch die PermGen in Concurrent Collects aufräumen zu lassen, und um etwaige System.gc()s, wie sie unsinnigerweise von diversen Plugins ausgelöst werden und bei Non-Concurrent-GCs für Full Collects sorgen, zu selbigem Zweck auszunutzen. Wobei wir die Trigger-Schwelle bei DEM Heap ziemlich weit nach hinten verschieben können. Allerdings denke ich, es wäre auch ´ne Idee, den G1 mal zu testen - sowohl auf meinem als auch auf einem Partnerserver arbeitet der G1 seit Java7 Update60 in meiner Erfahrung generell deutlich besser als der CMS, zumal der G1 wenigstens nicht bei Mark-Phasen den kompletten MC-Hauptthread anhält - und die Mark-Phasen können bei dem Heap potentiell recht lang ausfallen.
Wir können das ganze dann mit der Zeit noch finetunen (GC-Logs analysieren, übernehme ich gern), aber erstmal das grundlegende Problem lösen.
Viele Grüße,
cea