On Sat, Mar 28, 2015 at 12:17 PM, gavin.montgomery <
[email protected]> wrote:
> We found that, if we started up geoserver with the GWC disabled, memory on
> the server would sit comfortably at the level we allocated to the JVM.
> However, if the GWC layers were enabled we would find that the after
> startup
> memory would continue to rise beyond the allocation. A member of my team
> who
> is more technical on Linux/Unix systems was explaining that this could be
> down to fact that the Kernel is not releasing the memory? When we shut down
> geoserver, the memory would not be released (at first we feared this was a
> memory leak!).
>
Hum... wondering if this is related to GWC usage of file channels (as
opposed
to simple streams) to transfer data from disk to response.
The javadoc of the method is not so explict about how this can be
implemented:
http://docs.oracle.com/javase/7/docs/api/java/nio/channels/FileChannel.html#transferTo(long,%20long,%20java.nio.channels.WritableByteChannel)
However, it states "Many operating systems can transfer bytes directly from
the filesystem cache to the target channel without actually copying them."
Wondering if this might involve some sort of memory mapping... that said,
having
the memory "used" by the filesystem cache under Linux is normal, the
opposite
would be actually pathological (see http://www.linuxatemyram.com/ )
It would be different if the memory is instead used by the application...
but
in this case closing the application would release it all.
>
> What this meant was, as load increased on the geoserver, memory would rise
> due to the GWC which then would not allow enough resources for GeoServer to
> handle other requests to various other map layers.
>
So GeoServer was throwing out of memory errors? Or you were experiencing
slowdowns?
When we wrote that blog we actually though of a different
explanation/reasoning
for keeping GWC separate: we gave Tomcat a "reasonable" 200 threads to
respond requests (that's the default afaik) and the embedded GWC was getting
so many requests that all 200 thread were normally all busy dealing with
tiles,
making it hard for wms/wfs requests to go through (sort of denial of service
caused by excess tile traffic), and that also made the control-flow
extension less useful,
because the excess requests were queued at the Tomcat level.
Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
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
*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
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/
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
