Just looking to jmap this now and Geoserver is using over 4GB or RAM but
jmap reports the following: "Unable to attach to 32-bit process running
under WOW64" which suggests it's a 64bit jmap looking at a 32bit java
instance but Geoserver is running out of the same install as far as I can
tell allbeit jmap is in the JDK and Geoserver appears to be running from
the JVM. The only way I can think of getting round this is to restart
Geoserver and force it to run in the JDK version but that would lose the
4GB memory footprint I was hoping to analyse. Anything I can do without
having to restart?
Jonathan, one question: do all your Oracle connections use the same login?
My understanding of this is limited and there are other possible
explanations but a theory I have is that Oracle will not share a client
connection between two different logins and it allocates all its RAM via
the client program. If that's correct and you use a single login that
would explain why your memory usage is manageable and ours isn't. We use a
separate login for each of our clients to help ensure data separation and
we've got 14 configured in there. I also suspect that Oracle memory
configuration has more to do with how much memory the client application
uses but I've never found anything that explains how this actually works
particularly well!
On Mon, Dec 23, 2013 at 2:32 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Mon, Dec 23, 2013 at 2:55 PM, Tom (JDi Solutions) <
> tom.d...@jdi-solutions.co.uk> wrote:
>
>> Hi all,
>>
>> Thanks all for your responses. I will get jmap running and see what that
>> reports. We restart Apache nightly because it uses huge amounts of memory
>> because of Oracle client connections and I wonder if this is similar.
>> Either way Apache doesn't actually crash (it just keeps growing its memory
>> footprint) whereas Geoserver does and it sometimes does it more than once
>> per day which suggests that restarting it nightly isn't going to resolve
>> the problem.
>>
>> The Java startup params we're using are:
>>
>> # Initial Java Heap Size (in MB)
>> wrapper.java.initmemory=512
>>
>> # Maximum Java Heap Size (in MB)
>> wrapper.java.maxmemory=4096
>>
>> which I only recently upped. They were set to half that before. That to
>> me seems like a lot of RAM to grant something that serves a very small
>> number of requests (probably no more than a few thousand tiles per day)
>>
>
> And it is... normally we suggest not to go beyond 2GB of heap unless you
> have the CPUs and bandwidth to serve
> many concurrent requests, or have to serve very large output maps (for
> printing purposes).
>
> Cheers
> Andrea
>
>
> --
> *== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to
> 06/01/2014 ==*
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
