Hi all. I rceived a question offline regarding GeoServer's/Java's utilization of multiprocessors and multicore processors, and I figured this would be the place to pose it. Does / how does GeoServer do parallel processing?
Thanks,
Mike Pumphrey
Outreach Engineer
The Open Planning Project
Hi Mike,
I am by no means an expert on this subject but GeoServer should utilize multiple cores / processors effectively. The java servlet container model allows servlets to be multi threaded.
That being said, there have been no major benchmarks measuring how adding more processors effects performance. It would be an interesting analysis.
Mike Pumphrey wrote:
Hi all. I rceived a question offline regarding GeoServer's/Java's utilization of multiprocessors and multicore processors, and I figured this would be the place to pose it. Does / how does GeoServer do parallel processing?
Thanks,
Mike Pumphrey
Outreach Engineer
The Open Planning Project-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4007,48078fe67193362379201!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
There are two types of scalability,
1) How many requests can you complete on average. I.e. if you double the number of CPU cores, does the number of requests you can respond to per minute double?
2) Given X number of CPU cores, how much quicker does a single request return compared to running it on Y CPU cores?
My experience, just from looking at CPU utilization on a 8 core machine, is that we do well on 1) and poorly on 2). But for a webservice the first one is much more crucial than the second, so that's probably fine.
As Justin pointed out, GeoServer is a Java Servlet [1], so we expect to do quite well on the first one. But we depend on at least two things:
A) You could have a limiting backend. Say Postgresql limited to a certain number of threads, thereby stalling GeoServer.
B) The servlet container needs to be configured correctly. For Tomcat that means enabling the thread pools in the configuration.
So we do support multiple computational cores, but how well they utilized depends on a lot of variables. If the number of simultaneous requests exceeds the number of cores it's quite likely that you will be able to make full use of your hardware, but it may require some tweaking.
-Arne
1: http://java.sun.com/products/servlet/
Mike Pumphrey wrote:
Hi all. I rceived a question offline regarding GeoServer's/Java's utilization of multiprocessors and multicore processors, and I figured this would be the place to pose it. Does / how does GeoServer do parallel processing?
Thanks,
Mike Pumphrey
Outreach Engineer
The Open Planning Project-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4038,48078fe87115219720167!
Arne, right to the point, nice summary.
And yeah, we still have a lot of room where optimization could take place for
both 1) and 2).
I'll be hopefully doing some testing and may be even a proposal about this in
the short term.
Cheers,
Gabriel
On Friday 18 April 2008 05:24:52 pm Arne Kepp wrote:
There are two types of scalability,
1) How many requests can you complete on average. I.e. if you double the
number of CPU cores, does the number of requests you can respond to per
minute double?
2) Given X number of CPU cores, how much quicker does a single request
return compared to running it on Y CPU cores?My experience, just from looking at CPU utilization on a 8 core machine,
is that we do well on 1) and poorly on 2). But for a webservice the
first one is much more crucial than the second, so that's probably fine.As Justin pointed out, GeoServer is a Java Servlet [1], so we expect to
do quite well on the first one. But we depend on at least two things:
A) You could have a limiting backend. Say Postgresql limited to a
certain number of threads, thereby stalling GeoServer.
B) The servlet container needs to be configured correctly. For Tomcat
that means enabling the thread pools in the configuration.So we do support multiple computational cores, but how well they
utilized depends on a lot of variables. If the number of simultaneous
requests exceeds the number of cores it's quite likely that you will be
able to make full use of your hardware, but it may require some tweaking.-Arne
1: http://java.sun.com/products/servlet/
Mike Pumphrey wrote:
> Hi all. I rceived a question offline regarding GeoServer's/Java's
> utilization of multiprocessors and multicore processors, and I figured
> this would be the place to pose it. Does / how does GeoServer do
> parallel processing?
>
> Thanks,
> Mike Pumphrey
> Outreach Engineer
> The Open Planning Project
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
>vaone _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java
one _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4045,4808c0c1197022092453641!
In my expirience a saw that multiple core/cpu machine doesn’t scale well with java.
In unix/linux case, java is only one thread for the SO, so this really doesn’t explote all the cpu power…
I see two options for multiple core/cpu. Working with cpu affinity for java and postgres you could improve something the performance.
Another option is, start multiple instance of geoserver all with cpu affinity in diferent cpu for each java process and one cpu for postges…
One things you should have in mind memory… analyze how GC affect you and how much ram you give per java process and how much ram/process you give to postgres. Avoid memory swapping of java or postgres process at any cost.
Then, if you have intensive disk IO, you should use as many disk as posible to avoid wait for IO.
all of this is IMHO…
hope this help.
cheers,
facundo.-
On Fri, Apr 18, 2008 at 3:46 PM, Gabriel Roldán <groldan@anonymised.com> wrote:
Arne, right to the point, nice summary.
And yeah, we still have a lot of room where optimization could take place for
both 1) and 2).I’ll be hopefully doing some testing and may be even a proposal about this in
the short term.Cheers,
Gabriel
On Friday 18 April 2008 05:24:52 pm Arne Kepp wrote:
There are two types of scalability,
- How many requests can you complete on average. I.e. if you double the
number of CPU cores, does the number of requests you can respond to per
minute double?- Given X number of CPU cores, how much quicker does a single request
return compared to running it on Y CPU cores?My experience, just from looking at CPU utilization on a 8 core machine,
is that we do well on 1) and poorly on 2). But for a webservice the
first one is much more crucial than the second, so that’s probably fine.As Justin pointed out, GeoServer is a Java Servlet [1], so we expect to
do quite well on the first one. But we depend on at least two things:
A) You could have a limiting backend. Say Postgresql limited to a
certain number of threads, thereby stalling GeoServer.
B) The servlet container needs to be configured correctly. For Tomcat
that means enabling the thread pools in the configuration.So we do support multiple computational cores, but how well they
utilized depends on a lot of variables. If the number of simultaneous
requests exceeds the number of cores it’s quite likely that you will be
able to make full use of your hardware, but it may require some tweaking.-Arne
1: http://java.sun.com/products/servlet/
Mike Pumphrey wrote:
Hi all. I rceived a question offline regarding GeoServer’s/Java’s
utilization of multiprocessors and multicore processors, and I figured
this would be the place to pose it. Does / how does GeoServer do
parallel processing?Thanks,
Mike Pumphrey
Outreach Engineer
The Open Planning Project
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
vaone _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java
one _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4045,4808c0c1197022092453641!
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Facundo Garat Mayer
facundo@anonymised.com
In my expirience a saw that multiple core/cpu machine doesn’t scale well with java.
In unix/linux case, java is only one thread for the SO, so this really doesn’t explote all the cpu power…
I see two options for multiple core/cpu. Working with cpu affinity for java and postgres you could improve something the performance.
Another option is, start multiple instance of geoserver all with cpu affinity in diferent cpu for each java process and one cpu for postges…
One things you should have in mind memory… analyze how GC affect you and how much ram you give per java process and how much ram/process you give to postgres. Avoid memory swapping of java or postgres process at any cost.
Then, if you have intensive disk IO, you should use as many disk as posible to avoid wait for IO.
all of this is IMHO…
hope this help.
cheers,
facundo.-
On Fri, Apr 18, 2008 at 3:46 PM, Gabriel Roldán <groldan@anonymised.com> wrote:
Arne, right to the point, nice summary.
And yeah, we still have a lot of room where optimization could take place for
both 1) and 2).I’ll be hopefully doing some testing and may be even a proposal about this in
the short term.Cheers,
Gabriel
On Friday 18 April 2008 05:24:52 pm Arne Kepp wrote:
There are two types of scalability,
- How many requests can you complete on average. I.e. if you double the
number of CPU cores, does the number of requests you can respond to per
minute double?- Given X number of CPU cores, how much quicker does a single request
return compared to running it on Y CPU cores?My experience, just from looking at CPU utilization on a 8 core machine,
is that we do well on 1) and poorly on 2). But for a webservice the
first one is much more crucial than the second, so that’s probably fine.As Justin pointed out, GeoServer is a Java Servlet [1], so we expect to
do quite well on the first one. But we depend on at least two things:
A) You could have a limiting backend. Say Postgresql limited to a
certain number of threads, thereby stalling GeoServer.
B) The servlet container needs to be configured correctly. For Tomcat
that means enabling the thread pools in the configuration.So we do support multiple computational cores, but how well they
utilized depends on a lot of variables. If the number of simultaneous
requests exceeds the number of cores it’s quite likely that you will be
able to make full use of your hardware, but it may require some tweaking.-Arne
1: http://java.sun.com/products/servlet/
Mike Pumphrey wrote:
Hi all. I rceived a question offline regarding GeoServer’s/Java’s
utilization of multiprocessors and multicore processors, and I figured
this would be the place to pose it. Does / how does GeoServer do
parallel processing?Thanks,
Mike Pumphrey
Outreach Engineer
The Open Planning Project
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
vaone _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java
one _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:4045,4808c0c1197022092453641!
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Facundo Garat Mayer
facundo@anonymised.com
On Friday 18 April 2008 09:26:27 pm Facundo Garat wrote:
In my expirience a saw that multiple core/cpu machine doesn't scale well
with java.
As always, it is not just a matter of having the horsepower, but of using it.
Modern servlet engines do use thread pooling and modern JVM threads spawn
native OS threads.
Problem is most programs are not programmed taking IO blocking issues and
multi core/multi processor into account. If your process is serially
programmed, it'll always use a single thread (ie, a single core) to
accomplish its task. The challenge is in identifying more granular "execution
units" that can be done in parallel for the same result.
Same for IO. For example, if we were using non blocking io to write responses
down to client, a single thread may be able to cope up with the taks of many
responses, thus increasing scalability.
In unix/linux case, java is only one thread for the SO, so this really
doesn't explote all the cpu power...
Actually I'm quite sure that's not true.
A JVM instance will be seen as a single process in Linux, which is right to
the point of being multithreaded: one OS process, many threads. This wasn't
always like this, but since Linux introduced the nptl library (Native POSIX
Thread Library) its able to spawn multiple threads for a single process.
Before that, multi threading was emulated by forking a process, you you were
able to see multiple pids/java processes for a single running JVM.
I see two options for multiple core/cpu. Working with cpu affinity for java
and postgres you could improve something the performance.Another option is, start multiple instance of geoserver all with cpu
affinity in diferent cpu for each java process and one cpu for postges...One things you should have in mind memory..... analyze how GC affect you
and how much ram you give per java process and how much ram/process you
give to postgres. Avoid memory swapping of java or postgres process at any
cost.
That's funny I was just going to write my findings at fighting with GC issues
and performance. Keep tuned.
Then, if you have intensive disk IO, you should use as many disk as posible
to avoid wait for IO.
yup, those are all good advice, except I don't agree with the need to have
multiple geoserver instances to take advantage of multiple cores.
Just run a geoserver 1.6.3 on linux and send some concurrent requests while
you have some CPU monitor open, will see a single request perhaps only uses a
single core, and more concurrent requests do use more cores.
You can also notice it by the fact that WMS and WFS requests response times
are not affected by the number of concurrent requests up to the number of
cores (despiting some little IO overhead maybe).
Cheers,
Gabriel
all of this is IMHO...
hope this help.
cheers,
facundo.-On Fri, Apr 18, 2008 at 3:46 PM, Gabriel Roldán <groldan@anonymised.com>
wrote:
> Arne, right to the point, nice summary.
>
> And yeah, we still have a lot of room where optimization could take place
> for
> both 1) and 2).
>
> I'll be hopefully doing some testing and may be even a proposal about
> this in
> the short term.
>
> Cheers,
>
> Gabriel
>
> On Friday 18 April 2008 05:24:52 pm Arne Kepp wrote:
> > There are two types of scalability,
> > 1) How many requests can you complete on average. I.e. if you double
> > the number of CPU cores, does the number of requests you can respond to
> > per minute double?
> > 2) Given X number of CPU cores, how much quicker does a single request
> > return compared to running it on Y CPU cores?
> >
> > My experience, just from looking at CPU utilization on a 8 core
> > machine, is that we do well on 1) and poorly on 2). But for a
> > webservice the first one is much more crucial than the second, so
> > that's probably fine..
> >
> > As Justin pointed out, GeoServer is a Java Servlet [1], so we expect to
> > do quite well on the first one. But we depend on at least two things:
> > A) You could have a limiting backend. Say Postgresql limited to a
> > certain number of threads, thereby stalling GeoServer.
> > B) The servlet container needs to be configured correctly. For Tomcat
> > that means enabling the thread pools in the configuration.
> >
> > So we do support multiple computational cores, but how well they
> > utilized depends on a lot of variables. If the number of simultaneous
> > requests exceeds the number of cores it's quite likely that you will be
> > able to make full use of your hardware, but it may require some
>
> tweaking.
>
> > -Arne
> >
> > 1: http://java.sun.com/products/servlet/
> >
> > Mike Pumphrey wrote:
> > > Hi all. I rceived a question offline regarding GeoServer's/Java's
> > > utilization of multiprocessors and multicore processors, and I
> > > figured this would be the place to pose it. Does / how does
> > > GeoServer do parallel processing?
> > >
> > > Thanks,
> > > Mike Pumphrey
> > > Outreach Engineer
> > > The Open Planning Project
>
> -------------------------------------------------------------------------
>
> > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > > Don't miss this year's exciting event. There's still time to save
>
> $100.
>
> > > Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
>
> > >vaone _______________________________________________
> > > Geoserver-devel mailing list
> > > Geoserver-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> -------------------------------------------------------------------------
>
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save $100.
> > Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
>va
>
> >one _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
>vaone _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Gabriel,
you are rigth on ntpl… my mistake on this… anyway, i haven’t had good expirience with java and multicores… and of course depends on how the application was programmed…
In the case of starting more than one instance of geoserver with cpu affinity, my test showme better results than leave OS/Java resolve the problem in a multicore/multicpu environment…
Here is more info (a little bit old but useful): http://www.amitysolutions.com.au/documents/NPTL_Java_threads.pdf
cheers,
facundo.-
On Fri, Apr 18, 2008 at 4:52 PM, Gabriel Roldán <groldan@anonymised.com> wrote:
On Friday 18 April 2008 09:26:27 pm Facundo Garat wrote:
In my expirience a saw that multiple core/cpu machine doesn’t scale well
with java.As always, it is not just a matter of having the horsepower, but of using it.
Modern servlet engines do use thread pooling and modern JVM threads spawn
native OS threads.Problem is most programs are not programmed taking IO blocking issues and
multi core/multi processor into account. If your process is serially
programmed, it’ll always use a single thread (ie, a single core) to
accomplish its task. The challenge is in identifying more granular “execution
units” that can be done in parallel for the same result.
Same for IO. For example, if we were using non blocking io to write responses
down to client, a single thread may be able to cope up with the taks of many
responses, thus increasing scalability.In unix/linux case, java is only one thread for the SO, so this really
doesn’t explote all the cpu power…Actually I’m quite sure that’s not true.
A JVM instance will be seen as a single process in Linux, which is right to
the point of being multithreaded: one OS process, many threads. This wasn’t
always like this, but since Linux introduced the nptl library (Native POSIX
Thread Library) its able to spawn multiple threads for a single process.
Before that, multi threading was emulated by forking a process, you you were
able to see multiple pids/java processes for a single running JVM.I see two options for multiple core/cpu. Working with cpu affinity for java
and postgres you could improve something the performance.Another option is, start multiple instance of geoserver all with cpu
affinity in diferent cpu for each java process and one cpu for postges…One things you should have in mind memory… analyze how GC affect you
and how much ram you give per java process and how much ram/process you
give to postgres. Avoid memory swapping of java or postgres process at any
cost.That’s funny I was just going to write my findings at fighting with GC issues
and performance. Keep tuned.Then, if you have intensive disk IO, you should use as many disk as posible
to avoid wait for IO.yup, those are all good advice, except I don’t agree with the need to have
multiple geoserver instances to take advantage of multiple cores.
Just run a geoserver 1.6.3 on linux and send some concurrent requests while
you have some CPU monitor open, will see a single request perhaps only uses a
single core, and more concurrent requests do use more cores.
You can also notice it by the fact that WMS and WFS requests response times
are not affected by the number of concurrent requests up to the number of
cores (despiting some little IO overhead maybe).Cheers,
Gabriel
all of this is IMHO…
hope this help.
cheers,
facundo.-On Fri, Apr 18, 2008 at 3:46 PM, Gabriel Roldán <groldan@anonymised.com>
wrote:
Arne, right to the point, nice summary.
And yeah, we still have a lot of room where optimization could take place
for
both 1) and 2).I’ll be hopefully doing some testing and may be even a proposal about
this in
the short term.Cheers,
Gabriel
On Friday 18 April 2008 05:24:52 pm Arne Kepp wrote:
There are two types of scalability,
- How many requests can you complete on average. I.e. if you double
the number of CPU cores, does the number of requests you can respond to
per minute double?- Given X number of CPU cores, how much quicker does a single request
return compared to running it on Y CPU cores?My experience, just from looking at CPU utilization on a 8 core
machine, is that we do well on 1) and poorly on 2). But for a
webservice the first one is much more crucial than the second, so
that’s probably fine…As Justin pointed out, GeoServer is a Java Servlet [1], so we expect to
do quite well on the first one. But we depend on at least two things:
A) You could have a limiting backend. Say Postgresql limited to a
certain number of threads, thereby stalling GeoServer.
B) The servlet container needs to be configured correctly. For Tomcat
that means enabling the thread pools in the configuration.So we do support multiple computational cores, but how well they
utilized depends on a lot of variables. If the number of simultaneous
requests exceeds the number of cores it’s quite likely that you will be
able to make full use of your hardware, but it may require sometweaking.
-Arne
1: http://java.sun.com/products/servlet/
Mike Pumphrey wrote:
Hi all. I rceived a question offline regarding GeoServer’s/Java’s
utilization of multiprocessors and multicore processors, and I
figured this would be the place to pose it. Does / how does
GeoServer do parallel processing?Thanks,
Mike Pumphrey
Outreach Engineer
The Open Planning Project
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save$100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
vaone _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save $100.
Use priority code J8TL2D2.http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
vaone _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save $100.
Use priority code J8TL2D2.http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
vaone _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Facundo Garat Mayer
facundo@anonymised.com
Hey Facundo, thanks for the document, it'll take me some time to ingest, but
definitely seems worth to be read.
Yet, it'll be hard to convince me that with a JRE 1.5 or 1.6
threading/performance concern is the VM fault and not ours 
Though yeah, a quick look at the document actually makes sense as it evaluates
JDK 1.4.
Cheers,
Gabriel
On Friday 18 April 2008 10:09:14 pm Facundo Garat wrote:
Gabriel,
you are rigth on ntpl.. my mistake on this.. anyway, i haven't had good
expirience with java and multicores... and of course depends on how the
application was programmed...In the case of starting more than one instance of geoserver with cpu
affinity, my test showme better results than leave OS/Java resolve the
problem in a multicore/multicpu environment..Here is more info (a little bit old but useful):
http://www.amitysolutions.com.au/documents/NPTL_Java_threads.pdfcheers,
facundo.-On Fri, Apr 18, 2008 at 4:52 PM, Gabriel Roldán <groldan@anonymised.com>
wrote:
> On Friday 18 April 2008 09:26:27 pm Facundo Garat wrote:
> > In my expirience a saw that multiple core/cpu machine doesn't scale
>
> well
>
> > with java.
>
> As always, it is not just a matter of having the horsepower, but of using
> it.
> Modern servlet engines do use thread pooling and modern JVM threads spawn
> native OS threads.
>
> Problem is most programs are not programmed taking IO blocking issues and
> multi core/multi processor into account. If your process is serially
> programmed, it'll always use a single thread (ie, a single core) to
> accomplish its task. The challenge is in identifying more granular
> "execution
> units" that can be done in parallel for the same result.
> Same for IO. For example, if we were using non blocking io to write
> responses
> down to client, a single thread may be able to cope up with the taks of
> many
> responses, thus increasing scalability.
>
> > In unix/linux case, java is only one thread for the SO, so this really
> > doesn't explote all the cpu power...
>
> Actually I'm quite sure that's not true.
> A JVM instance will be seen as a single process in Linux, which is right
> to
> the point of being multithreaded: one OS process, many threads. This
> wasn't
> always like this, but since Linux introduced the nptl library (Native
> POSIX
> Thread Library) its able to spawn multiple threads for a single process.
> Before that, multi threading was emulated by forking a process, you you
> were
> able to see multiple pids/java processes for a single running JVM.
>
> > I see two options for multiple core/cpu. Working with cpu affinity for
>
> java
>
> > and postgres you could improve something the performance.
> >
> > Another option is, start multiple instance of geoserver all with cpu
> > affinity in diferent cpu for each java process and one cpu for
>
> postges...
>
> > One things you should have in mind memory..... analyze how GC affect
> > you and how much ram you give per java process and how much ram/process
> > you give to postgres. Avoid memory swapping of java or postgres process
> > at
>
> any
>
> > cost.
>
> That's funny I was just going to write my findings at fighting with GC
> issues
> and performance. Keep tuned.
>
> > Then, if you have intensive disk IO, you should use as many disk as
>
> posible
>
> > to avoid wait for IO.
>
> yup, those are all good advice, except I don't agree with the need to
> have multiple geoserver instances to take advantage of multiple cores.
> Just run a geoserver 1.6.3 on linux and send some concurrent requests
> while
> you have some CPU monitor open, will see a single request perhaps only
> uses a
> single core, and more concurrent requests do use more cores.
> You can also notice it by the fact that WMS and WFS requests response
> times
> are not affected by the number of concurrent requests up to the number of
> cores (despiting some little IO overhead maybe).
>
> Cheers,
>
> Gabriel
>
> > all of this is IMHO...
> >
> > hope this help.
> >
> >
> > cheers,
> > facundo.-
> >
> >
> > On Fri, Apr 18, 2008 at 3:46 PM, Gabriel Roldán <groldan@anonymised.com.>
> >
> > wrote:
> > > Arne, right to the point, nice summary.
> > >
> > > And yeah, we still have a lot of room where optimization could take
>
> place
>
> > > for
> > > both 1) and 2).
> > >
> > > I'll be hopefully doing some testing and may be even a proposal about
> > > this in
> > > the short term.
> > >
> > > Cheers,
> > >
> > > Gabriel
> > >
> > > On Friday 18 April 2008 05:24:52 pm Arne Kepp wrote:
> > > > There are two types of scalability,
> > > > 1) How many requests can you complete on average. I.e. if you
> > > > double the number of CPU cores, does the number of requests you can
> > > > respond
>
> to
>
> > > > per minute double?
> > > > 2) Given X number of CPU cores, how much quicker does a single
>
> request
>
> > > > return compared to running it on Y CPU cores?
> > > >
> > > > My experience, just from looking at CPU utilization on a 8 core
> > > > machine, is that we do well on 1) and poorly on 2). But for a
> > > > webservice the first one is much more crucial than the second, so
> > > > that's probably fine..
> > > >
> > > > As Justin pointed out, GeoServer is a Java Servlet [1], so we
> > > > expect
>
> to
>
> > > > do quite well on the first one. But we depend on at least two
>
> things:
> > > > A) You could have a limiting backend. Say Postgresql limited to a
> > > > certain number of threads, thereby stalling GeoServer.
> > > > B) The servlet container needs to be configured correctly. For
>
> Tomcat
>
> > > > that means enabling the thread pools in the configuration.
> > > >
> > > > So we do support multiple computational cores, but how well they
> > > > utilized depends on a lot of variables. If the number of
>
> simultaneous
>
> > > > requests exceeds the number of cores it's quite likely that you
> > > > will
>
> be
>
> > > > able to make full use of your hardware, but it may require some
> > >
> > > tweaking.
> > >
> > > > -Arne
> > > >
> > > > 1: http://java.sun.com/products/servlet/
> > > >
> > > > Mike Pumphrey wrote:
> > > > > Hi all. I rceived a question offline regarding
> > > > > GeoServer's/Java's utilization of multiprocessors and multicore
> > > > > processors, and I figured this would be the place to pose it.
> > > > > Does / how does GeoServer do parallel processing?
> > > > >
> > > > > Thanks,
> > > > > Mike Pumphrey
> > > > > Outreach Engineer
> > > > > The Open Planning Project
>
> -------------------------------------------------------------------------
>
> > > > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > > > > Don't miss this year's exciting event. There's still time to save
> > >
> > > $100.
> > >
> > > > > Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
>
> > > > >vaone _______________________________________________
> > > > > Geoserver-devel mailing list
> > > > > Geoserver-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> -------------------------------------------------------------------------
>
> > > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > > > Don't miss this year's exciting event. There's still time to save
>
> $100.
>
> > > > Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
>
> > >va
> > >
> > > >one _______________________________________________
> > > > Geoserver-devel mailing list
> > > > Geoserver-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> -------------------------------------------------------------------------
>
> > > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > > Don't miss this year's exciting event. There's still time to save
>
> $100.
>
> > > Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
>
> > >vaone _______________________________________________
> > > Geoserver-devel mailing list
> > > Geoserver-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Yes, is a little bit old…
Performance factors goes beyond VM in all this cases… I don’t say that is VM fault…
I think is almost 100% our concer and every application or situation has is issues. In the VM case there is a lot to tune and so is on the SO and the infraestructure…
And I still think that Java doesn’t scale well in this scenarios… and for now, as just said, i had better results with more than one instance of geoserver with cpu affinity on multicore/cpus.
Still, I will have present all you have said because i’m very new to Geoserver and I think you and another people on this list really know what they talk about so i could always learn…
cheers,
facundo.-
On Fri, Apr 18, 2008 at 5:20 PM, Gabriel Roldán <groldan@anonymised.com> wrote:
Hey Facundo, thanks for the document, it’ll take me some time to ingest, but
definitely seems worth to be read.Yet, it’ll be hard to convince me that with a JRE 1.5 or 1.6
threading/performance concern is the VM fault and not oursThough yeah, a quick look at the document actually makes sense as it evaluates
JDK 1.4.Cheers,
Gabriel
On Friday 18 April 2008 10:09:14 pm Facundo Garat wrote:
Gabriel,
you are rigth on ntpl… my mistake on this… anyway, i haven’t had good
expirience with java and multicores… and of course depends on how the
application was programmed…In the case of starting more than one instance of geoserver with cpu
affinity, my test showme better results than leave OS/Java resolve the
problem in a multicore/multicpu environment…Here is more info (a little bit old but useful):
http://www.amitysolutions.com.au/documents/NPTL_Java_threads.pdfcheers,
facundo.-On Fri, Apr 18, 2008 at 4:52 PM, Gabriel Roldán <groldan@anonymised.com>
wrote:
On Friday 18 April 2008 09:26:27 pm Facundo Garat wrote:
In my expirience a saw that multiple core/cpu machine doesn’t scale
well
with java.
As always, it is not just a matter of having the horsepower, but of using
it.
Modern servlet engines do use thread pooling and modern JVM threads spawn
native OS threads.Problem is most programs are not programmed taking IO blocking issues and
multi core/multi processor into account. If your process is serially
programmed, it’ll always use a single thread (ie, a single core) to
accomplish its task. The challenge is in identifying more granular
“execution
units” that can be done in parallel for the same result.
Same for IO. For example, if we were using non blocking io to write
responses
down to client, a single thread may be able to cope up with the taks of
many
responses, thus increasing scalability.In unix/linux case, java is only one thread for the SO, so this really
doesn’t explote all the cpu power…Actually I’m quite sure that’s not true.
A JVM instance will be seen as a single process in Linux, which is right
to
the point of being multithreaded: one OS process, many threads. This
wasn’t
always like this, but since Linux introduced the nptl library (Native
POSIX
Thread Library) its able to spawn multiple threads for a single process.
Before that, multi threading was emulated by forking a process, you you
were
able to see multiple pids/java processes for a single running JVM.I see two options for multiple core/cpu. Working with cpu affinity for
java
and postgres you could improve something the performance.
Another option is, start multiple instance of geoserver all with cpu
affinity in diferent cpu for each java process and one cpu forpostges…
One things you should have in mind memory… analyze how GC affect
you and how much ram you give per java process and how much ram/process
you give to postgres. Avoid memory swapping of java or postgres process
atany
cost.
That’s funny I was just going to write my findings at fighting with GC
issues
and performance. Keep tuned.Then, if you have intensive disk IO, you should use as many disk as
posible
to avoid wait for IO.
yup, those are all good advice, except I don’t agree with the need to
have multiple geoserver instances to take advantage of multiple cores.
Just run a geoserver 1.6.3 on linux and send some concurrent requests
while
you have some CPU monitor open, will see a single request perhaps only
uses a
single core, and more concurrent requests do use more cores.
You can also notice it by the fact that WMS and WFS requests response
times
are not affected by the number of concurrent requests up to the number of
cores (despiting some little IO overhead maybe).Cheers,
Gabriel
all of this is IMHO…
hope this help.
cheers,
facundo.-On Fri, Apr 18, 2008 at 3:46 PM, Gabriel Roldán <groldan@anonymised.com>
wrote:
Arne, right to the point, nice summary.
And yeah, we still have a lot of room where optimization could take
place
for
both 1) and 2).I’ll be hopefully doing some testing and may be even a proposal about
this in
the short term.Cheers,
Gabriel
On Friday 18 April 2008 05:24:52 pm Arne Kepp wrote:
There are two types of scalability,
- How many requests can you complete on average. I.e. if you
double the number of CPU cores, does the number of requests you can
respondto
per minute double?
2) Given X number of CPU cores, how much quicker does a singlerequest
return compared to running it on Y CPU cores?
My experience, just from looking at CPU utilization on a 8 core
machine, is that we do well on 1) and poorly on 2). But for a
webservice the first one is much more crucial than the second, so
that’s probably fine…As Justin pointed out, GeoServer is a Java Servlet [1], so we
expectto
do quite well on the first one. But we depend on at least two
things:
A) You could have a limiting backend. Say Postgresql limited to a
certain number of threads, thereby stalling GeoServer.
B) The servlet container needs to be configured correctly. ForTomcat
that means enabling the thread pools in the configuration.
So we do support multiple computational cores, but how well they
utilized depends on a lot of variables. If the number ofsimultaneous
requests exceeds the number of cores it’s quite likely that you
willbe
able to make full use of your hardware, but it may require some
tweaking.
-Arne
1: http://java.sun.com/products/servlet/
Mike Pumphrey wrote:
Hi all. I rceived a question offline regarding
GeoServer’s/Java’s utilization of multiprocessors and multicore
processors, and I figured this would be the place to pose it.
Does / how does GeoServer do parallel processing?Thanks,
Mike Pumphrey
Outreach Engineer
The Open Planning Project
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save$100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
vaone _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save$100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
va
one _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save$100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/ja
vaone _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Facundo Garat Mayer
facundo@anonymised.com