Hi Hilton,

I tried psi-probe and other profiling tools but psi-probe didn't work and it seems that the headless OpenJDK is missing some tools like jstat which would help. We increased the memory of our JVM to 4 Gigabyte and will observe how DSpace behaves.

Thanks for your help
Christian

Am 01.04.2015 um 13:35 schrieb Hilton Gibson:
Hi Christian

Perhaps somebody could do Java profiling on some big production systems to see where the RAM goes.
See: http://wiki.lib.sun.ac.za/index.php/SUNScholar/Optimisations/Java

Cheers

hg

*Hilton Gibson*
Ubuntu Linux Systems Administrator
JS Gericke Library
Room 1025C
Stellenbosch University
Private Bag X5036
Stellenbosch
7599
South Africa

Tel: +27 21 808 4100 | Cell: +27 84 646 4758

On 1 April 2015 at 12:49, Christian Scheible <christian.schei...@uni-konstanz.de <mailto:christian.schei...@uni-konstanz.de>> wrote:

    Thanks for your quick reply. We will increase the heap size.
    The question just is if there is a known issue causing more memory
    to be used?
    Because it was fine before the upgrade.

    Best Regards
    Christian

    Am 01.04.2015 um 11:39 schrieb Hilton Gibson:
    Perhaps this will help:
    
http://wiki.lib.sun.ac.za/index.php/SUNScholar/Prepare_Ubuntu/S05/Ubuntu-14.04#Java_environment_settings_used_for_SUNScholar

    Cheers

    hg

    *Hilton Gibson*
    Ubuntu Linux Systems Administrator
    JS Gericke Library
    Room 1025C
    Stellenbosch University
    Private Bag X5036
    Stellenbosch
    7599
    South Africa

    Tel: +27 21 808 4100 <tel:%2B27%2021%20808%204100> | Cell: +27 84
    646 4758 <tel:%2B27%2084%20646%204758>

    On 1 April 2015 at 11:01, Christian Scheible
    <christian.schei...@uni-konstanz.de
    <mailto:christian.schei...@uni-konstanz.de>> wrote:

        Hi guys,

        We are running a DSpace 5.1 instance with about 25000 items
        on Ubuntu
        Server 14.04 with OpenJDK 1.7.0_75. We set Xmx to 2g so the
        JVM has 2
        Gigabyte of RAM.
        If I inspect the memory usage I see that there are about 1900
        MiB in
        use. So most of the memory is used.
        This leads to OutOfMemoryErrors during nightly cron jobs like
        optimizing
        Solr and sometimes during the day.

        Has anyone seen a similar behaviour and solved the problem?

        Additional facts:
        - Was working fine on 4.1
        - After tomcat restart about 500 MiB memory of the JVM used
        - 5 Minutes later 1074 MiB used
        - 10 Minutes later 1702 Mib used
        - About 14000 publication with full text (indexed every night
        with the
        PDF Extractor)
        - About 11000 publications without full text
        - xmlui, oai and solr activated
        - Ubuntu Server 14.04.2
        - Tomcat 7.0.52.0
        - OpenJDK headless 1.7.0_75
        - Solr: authority core=empty, oai core=114,47 MB, search
        core=3.57 GB,
        statistics core=387.82
        - JVM 2GB
        - System 4GB

        Any ideas? Help would be very appreciated

        --
        Christian Scheible
        Softwareentwickler / Abt. Content-basierte Dienste
        Kommunikations-, Informations- und Medienzentrum (KIM)
        Universität Konstanz
        78457 Konstanz
        +49 (0)7531 / 88-2857 <tel:%2B49%20%280%297531%20%2F%2088-2857>
        Raum B 703


        
------------------------------------------------------------------------------
        Dive into the World of Parallel Programming The Go Parallel
        Website, sponsored
        by Intel and developed in partnership with Slashdot Media, is
        your hub for all
        things parallel software development, from weekly thought
        leadership blogs to
        news, videos, case studies, tutorials and more. Take a look
        and join the
        conversation now. http://goparallel.sourceforge.net/
        _______________________________________________
        DSpace-tech mailing list
        DSpace-tech@lists.sourceforge.net
        <mailto:DSpace-tech@lists.sourceforge.net>
        https://lists.sourceforge.net/lists/listinfo/dspace-tech
        List Etiquette:
        https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette




-- Christian Scheible
    Softwareentwickler / Abt. Content-basierte Dienste
    Kommunikations-, Informations- und Medienzentrum (KIM)
    Universität Konstanz
    78457 Konstanz
    +49 (0)7531 / 88-2857  <tel:%2B49%20%280%297531%20%2F%2088-2857>
    Raum B 703




--
Christian Scheible
Softwareentwickler / Abt. Content-basierte Dienste
Kommunikations-, Informations- und Medienzentrum (KIM)
Universität Konstanz
78457 Konstanz
+49 (0)7531 / 88-2857
Raum B 703

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Reply via email to