[
https://issues.apache.org/jira/browse/SPARK-21176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ingo Schuster updated SPARK-21176:
----------------------------------
Description:
In reverse proxy mode, Sparks exhausts the Jetty thread pool if the master node
has too many cpus or the cluster has too many executers:
For each connector, Jetty creates Selector threads: minimum 4, maximum half the
number of available CPUs:
{{ this(Math.max(1, Runtime.getRuntime().availableProcessors() / 2));}}
(see
https://github.com/eclipse/jetty.project/blob/0c8273f2ca1f9bf2064cd9c4c939d2546443f759/jetty-client/src/main/java/org/eclipse/jetty/client/http/HttpClientTransportOverHTTP.java)
In reverse proxy mode, a connector is set up for each executor and one for the
master UI.
I have a system with 88 CPUs on the master node and 7 executors. Jetty tries to
instantiate 8*44 = 352 selector threads, but since the QueuedThreadPool is
initialized with 200 threads by default, the UI gets stuck.
I have patched JettyUtils.scala to extend the thread pool ( {{val pool = new
QueuedThreadPool*(400)* }}). With this hack, the UI works.
Obviously, the Jetty defaults are meant for a real web server. If that has 88
CPUs, you do certainly expect a lot of traffic.
For the Spark admin UI however, there will rarely be concurrent accesses for
the same application or the same executor.
I therefore propose to dramatically reduce the number of selector threads that
get instantiated - at least by default.
I will propose a fix in a pull request.
was:
In reverse proxy mode, Sparks exhausts the Jetty thread pool if the master node
has too many cpus or the cluster has too many executers:
For each connector, Jetty creates Selector threads: minimum 4, maximum half the
number of available CPUs:
{{selectors>0?selectors:Math.max(1,Math.min(4,Runtime.getRuntime().availableProcessors()/2)));}}
(see
https://github.com/eclipse/jetty.project/blob/jetty-9.3.x/jetty-server/src/main/java/org/eclipse/jetty/server/ServerConnector.java)
In reverse proxy mode, a connector is set up for each executor and one for the
master UI.
I have a system with 88 CPUs on the master node and 7 executors. Jetty tries to
instantiate 8*44 = 352 selector threads, but since the QueuedThreadPool is
initialized with 200 threads by default, the UI gets stuck.
I have patched JettyUtils.scala to extend the thread pool ( {{val pool = new
QueuedThreadPool*(400)* }}). With this hack, the UI works.
Obviously, the Jetty defaults are meant for a real web server. If that has 88
CPUs, you do certainly expect a lot of traffic.
For the Spark admin UI however, there will rarely be concurrent accesses for
the same application or the same executor.
I therefore propose to dramatically reduce the number of selector threads that
get instantiated - at least by default.
I will propose a fix in a pull request.
> Master UI hangs with spark.ui.reverseProxy=true if the master node has many
> CPUs
> --------------------------------------------------------------------------------
>
> Key: SPARK-21176
> URL: https://issues.apache.org/jira/browse/SPARK-21176
> Project: Spark
> Issue Type: Bug
> Components: Web UI
> Affects Versions: 2.1.0, 2.1.1, 2.2.0, 2.2.1
> Environment: ppc64le GNU/Linux, POWER8, only master node is reachable
> externally other nodes are in an internal network
> Reporter: Ingo Schuster
> Labels: network, web-ui
>
> In reverse proxy mode, Sparks exhausts the Jetty thread pool if the master
> node has too many cpus or the cluster has too many executers:
> For each connector, Jetty creates Selector threads: minimum 4, maximum half
> the number of available CPUs:
> {{ this(Math.max(1, Runtime.getRuntime().availableProcessors() / 2));}}
> (see
> https://github.com/eclipse/jetty.project/blob/0c8273f2ca1f9bf2064cd9c4c939d2546443f759/jetty-client/src/main/java/org/eclipse/jetty/client/http/HttpClientTransportOverHTTP.java)
> In reverse proxy mode, a connector is set up for each executor and one for
> the master UI.
> I have a system with 88 CPUs on the master node and 7 executors. Jetty tries
> to instantiate 8*44 = 352 selector threads, but since the QueuedThreadPool is
> initialized with 200 threads by default, the UI gets stuck.
> I have patched JettyUtils.scala to extend the thread pool ( {{val pool = new
> QueuedThreadPool*(400)* }}). With this hack, the UI works.
> Obviously, the Jetty defaults are meant for a real web server. If that has 88
> CPUs, you do certainly expect a lot of traffic.
> For the Spark admin UI however, there will rarely be concurrent accesses for
> the same application or the same executor.
> I therefore propose to dramatically reduce the number of selector threads
> that get instantiated - at least by default.
> I will propose a fix in a pull request.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
