Announcement

Collapse
No announcement yet.

listuser: java.lang.OutOfMemoryError

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • listuser: java.lang.OutOfMemoryError

    Hallo,

    ich habe das Problem, dass ich über den Konsolenbefehl '/opt/open-xchange/sbin/listuser' keine Benutzer anzeigen lassen kann. Es erscheint die Fehlermeldung:

    Code:
    users in context 1 could not be listed: 
    Server response:
     Error occurred in server thread; nested exception is: 
            java.lang.OutOfMemoryError
    Das System ist SLES 11 und besitzt 4 GB RAM, wovon aber derzeit nur 2 GB benutzt werden.

    Ich habe bereits erfolglos in den Konfigurationsdateien nachgesehen, aber nichts gefunden, was mich weiterbringt. Wie auch bei den beiden letzten Posts bin ich über die Hilfe ankbar.

    looper

  • #2
    Increase memory usage in /opt/open-xchange/etc/admindaemon/ox-admin-scriptconf.sh

    Code:
    JAVA_OXCMD_OPTS="-Xmx50m -XX:+UseConcMarkSweepGC -Djava.net.preferIPv4Stack=true"
    e.g. "-Xmx100m", depending on the amount of users you have.

    Comment


    • #3
      Hi,

      "listuser" ruft ein Java-Prozess auf, der dann die Daten ausliest. Java nimmt sich nur soviel Speicher, wie man ihm erlaubt. Offenbar ist dieser Wert hier zu gering. Schau dir mal bitte die ox-admin-scriptconf.sh Datei im admindaemon Verzeichnis an. Dort kannst du die Maximalwerte definieren. Bei der Groupware gibt es die gleiche Datei die man auf sein System anpassen sollte.

      Code:
      /opt/open-xchange/etc/admindaemon/ox-admin-scriptconf.sh
      JAVA_XTRAOPTS="-Xmx100m -XX:+UseConcMarkSweepGC -Djava.net.preferIPv4Stack=true"
      JAVA_OXCMD_OPTS="-Xmx50m -XX:+UseConcMarkSweepGC -Djava.net.preferIPv4Stack=true
      Der Parameter Xmx gibt den jeweiligen Maximalwertfür den Admindaemon und die Konsolentools an. In deinem Fall würde ich einfach mal -Xmx100m versuchen und weiter hoch gehen falls es nicht ausreicht. Allerdings solltest du nie mehr Speicher erlauben als physikalisch(+Swap) zur Verfügung steht da sonst die JVM recht unsanft beendet werden könnte.

      Gruß

      Comment


      • #4
        Hallo Martin,

        danke für deine schnelle Antwort. Dein Lösungsvorschlag brachte bisher keinen Erfolg. Ich habe den Wert auf 3200 gesetzt (also -Xmx3200m), nachdem ich ihn sukzessiv erhöht hatte (100, 200, 400, 800, 1600, ...). Das System besitzt wie bereits oben gesagt 4 GB RAM, wenn ich es richtig verstehe, bedeutet '3200m', dass er 3,2 GB RAM für sein 'listuser' verwenden soll.
        In der Datenbank befinden sich rund 24000 Benutzer, die ich durchsuche. Das können doch nicht zu viel sein, oder?

        P.S. Habe den Wert trotz deiner Ermahnung zwischenzeitlich auf 12800 gesetzt ... leider immer noch 'OutOfMemoryError'.

        looper

        Comment


        • #5
          Hallo,

          wurde bisher nur der Wert in JAVA_OXCMD_OPTS erhöht oder auch der JAVA_XTRAOPTS? Evtl. hat nämlich nicht das Command line tool zu wenig Speicher, sondern der Admin selbst, das sollte allerdings auch im Admin log auftauchen. Werte jenseits des physikalischen Speicher machen übrigens keinen Sinn.

          Gruß,

          Dennis

          Comment


          • #6
            Hi,

            da hat Dennis recht. In der Regel reichen 256m selbst für sehr große Umgebungen.
            Falls das auch nichts hilft, poste mal bitte den Stacktrace aus dem Admin log.

            Gruß
            Martin

            Comment


            • #7
              Hallo,

              ich glaube, ich habe einen Fehler gemacht und ihn gerade bemerkt. Bisher habe ich einen Benutzer mit 'listuser' wie folgt gesucht:

              Code:
              /opt/open-xchange/sbin/listuser -c 1 -A oxadmin -P geheim | grep <Username>
              Das hat anfangs auch immer funktioniert, seit dem aber ca. 24000 Nutzer in der Datenbank sind, nicht mehr.

              Wer lesen kann ...
              Ich habe gerade gelesen, dass es den 'searchpattern' gibt ... und siehe da, so funktioniert es auch mit 24000 Benutzern.

              Ich habe trotzdem nochmal die Fehlermeldungen von '/var/log/open-xchange/open-xchange-admin.log.0' angezeigt, falls der 'grep'-Befehl auch gehen müsste ... der funktioniert nicht.

              Code:
              Feb 7, 2011 6:06:52 AM com.openexchange.pooling.ReentrantLockPool run
              SEVERE: Object was not returned. Fetched: 1297058748585, UseTime: 64208, ID: 4, Object: com.mysql.jdbc.JDBC4Connection@35ec35ec
              Throwable occurred: com.openexchange.pooling.PoolingException: Object was not returned. Fetched: 1297058748585, UseTime: 64208, ID: 4, Object: com.mysql.jdbc.JDBC4Connection@35ec35ec
                      at com.openexchange.pooling.ReentrantLockPool.run(ReentrantLockPool.java:549)
                      at com.openexchange.pooling.ReentrantLockPool$1.run(ReentrantLockPool.java:448)
                      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:453)
                      at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:329)
                      at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:162)
                      at com.openexchange.threadpool.internal.CustomThreadPoolExecutor$ScheduledFutureTask.runPeriodic(CustomThreadPoolExecutor.java:857)
                      at com.openexchange.threadpool.internal.CustomThreadPoolExecutor$ScheduledFutureTask.run(CustomThreadPoolExecutor.java:882)
                      at com.openexchange.threadpool.internal.CustomThreadPoolExecutor$Worker.runTask(CustomThreadPoolExecutor.java:738)
                      at com.openexchange.threadpool.internal.CustomThreadPoolExecutor$Worker.run(CustomThreadPoolExecutor.java:764)
                      at java.lang.Thread.run(Thread.java:736)
              Feb 7, 2011 6:07:22 AM com.openexchange.database.internal.ReplicationMonitor backAndIncrementTransaction
              SEVERE: DBP-0009 Category=8 Message=Cannot return connection to pool 4. exceptionID=2103414407-1
              Throwable occurred: DBP-0009 Category=8 Message=Cannot return connection to pool 4. exceptionID=2103414407-1
                      at com.openexchange.database.internal.DBPoolingExceptionFactory.createException(DBPoolingExceptionFactory.java:76)
                      at com.openexchange.database.internal.DBPoolingExceptionFactory.createException(DBPoolingExceptionFactory.java:62)
                      at com.openexchange.exceptions.Exceptions.create(Exceptions.java:144)
                      at com.openexchange.exceptions.Exceptions.create(Exceptions.java:164)
                      at com.openexchange.database.DBPoolingExceptionCodes.create(DBPoolingExceptionCodes.java:215)
                      at com.openexchange.database.internal.ReplicationMonitor.backAndIncrementTransaction(ReplicationMonitor.java:218)
                      at com.openexchange.database.internal.wrapping.JDBC3ConnectionReturner.close(JDBC3ConnectionReturner.java:99)
                      at com.openexchange.database.internal.DatabaseServiceImpl.back(DatabaseServiceImpl.java:99)
                      at com.openexchange.database.internal.DatabaseServiceImpl.backWritable(DatabaseServiceImpl.java:190)
                      at com.openexchange.databaseold.Database.back(Database.java:194)
                      at com.openexchange.admin.storage.sqlStorage.OXAdminPoolDBPool.pushConnectionForContext(OXAdminPoolDBPool.java:118)
                      at com.openexchange.admin.tools.AdminCache.pushConnectionForContext(AdminCache.java:352)
                      at com.openexchange.admin.storage.mysqlStorage.OXUserMySQLStorage.getData(OXUserMySQLStorage.java:1786)
                      at com.openexchange.admin.rmi.impl.OXUser.getData(OXUser.java:851)
                      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
                      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
                      at java.lang.reflect.Method.invoke(Method.java:600)
                      at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:310)
                      at sun.rmi.transport.Transport$1.run(Transport.java:171)
                      at java.security.AccessController.doPrivileged(AccessController.java:284)
                      at sun.rmi.transport.Transport.serviceCall(Transport.java:167)
                      at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:547)
                      at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:802)
                      at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:661)
                      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
                      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
                      at java.lang.Thread.run(Thread.java:736)
              Caused by: com.openexchange.pooling.PoolingException: Object "com.mysql.jdbc.JDBC4Connection@35ec35ec" does not belong to this pool.
                      at com.openexchange.pooling.ReentrantLockPool.back(ReentrantLockPool.java:171)
                      at com.openexchange.pooling.ReentrantLockPool.back(ReentrantLockPool.java:145)
                      at com.openexchange.database.internal.ReplicationMonitor.backAndIncrementTransaction(ReplicationMonitor.java:216)
                      ... 22 more
              Leider bin ich nicht so der Java-Experte, um aus den Meldungen schlau zu werden.

              looper

              Comment


              • #8
                Hallo,

                ich verzweifle gerade an der selben stelle und weiss nicht weiter.
                Ich habe einen vserver von Server4you mit 3GhZ und 3GB FlexRam, der kleinste halt weil nur der Ox da rauf soll.

                ich habe wie in dem thread beschrieben auch mal mit der ox-admin-scriptconf.sh gespielt und versucht was zu verändern.
                Momentan sieht sie so aus:
                Code:
                JAVA_XTRAOPTS="-Xms50m -Xmx150m -XX:+UseConcMarkSweepGC -XX:NewSize=50m -XX:MaxNewSize=150m -XX:SurvivorRatio=6 -Djava.net.preferIPv4Stack=true"
                JAVA_OXCMD_OPTS="-Xms50m -Xmx150m -XX:+UseConcMarkSweepGC -XX:NewSize=50m -XX:MaxNewSize=150m -XX:SurvivorRatio=6 -Djava.net.preferIPv4Stack=true"
                das hat zwar gebracht das die java.lang.OutOfMemoryError nicht mehr kommt, aber nun kommt ein neues problem.
                Ich habe zur zeit Debian 5 32-bit minimal installation drauf.

                Code:
                root@euve20922:~# /opt/open-xchange/sbin/createcontext -A oxadminmaster -P xxxx -c 1 -u oxadmin -d "Context Admin" -g Admin -s User -p xxxx -L defaultcontext -e bla@bla.com -q 1024 --access-combination-name=all
                Error occurred during initialization of VM
                Too small initial heap for new size specified

                Comment

                Working...
                X