Affects Version/s: 1.1.1, 1.2.0
Linux dn11.chi.shopify.com 3.2.0-57-generic #87-Ubuntu SMP 3 x86_64 x86_64 x86_64 GNU/Linux Standalone Spark built from apache/spark#c6e0c2ab1c29c184a9302d23ad75e4ccd8060242 Python 2.7.3 java version "1.7.0_71" Java(TM) SE Runtime Environment (build 1.7.0_71-b14) Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) 1 Spark master, 40 Spark workers with 32 cores a piece and 60-90 GB of memory a piece All client code is PySpark
- Linux dn11.chi.shopify.com 3.2.0-57-generic #87-Ubuntu SMP 3 x86_64 x86_64 x86_64 GNU/Linux
- Standalone Spark built from apache/spark#c6e0c2ab1c29c184a9302d23ad75e4ccd8060242
- Python 2.7.3
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
- 1 Spark master, 40 Spark workers with 32 cores a piece and 60-90 GB of memory a piece
- All client code is PySpark
We observe the spark standalone master not detecting that a driver application has completed after the driver process has shut down indefinitely, leaving that driver's resources consumed indefinitely. The master reports applications as Running, but the driver process has long since terminated. The master continually spawns one executor for the application. It boots, times out trying to connect to the driver application, and then dies with the exception below. The master then spawns another executor on a different worker, which does the same thing. The application lives until the master (and workers) are restarted.
This happens to many jobs at once, all right around the same time, two or three times a day, where they all get suck. Before and after this "blip" applications start, get resources, finish, and are marked as finished properly. The "blip" is mostly conjecture on my part, I have no hard evidence that it exists other than my identification of the pattern in the Running Applications table. See http://cl.ly/image/2L383s0e2b3t/Screen%20Shot%202014-11-19%20at%203.43.09%20PM.png : the applications started before the blip at 1.9 hours ago still have active drivers. All the applications started 1.9 hours ago do not, and the applications started less than 1.9 hours ago (at the top of the table) do in fact have active drivers.
- PySpark drivers running on one node outside the cluster, scheduled by a cron-like application, not master supervised
- In most places, we call sc.stop() explicitly before shutting down our driver process
- Here's the sum total of spark configuration options we don't set to the default:
- The exception the executors die with is this:
- We run spark versions built from apache/spark#master snapshots. We did not observe this behaviour on 7eb9cbc273d758522e787fcb2ef68ef65911475f (sorry its so old), but now observe it on c6e0c2ab1c29c184a9302d23ad75e4ccd8060242. We can try new versions to assist debugging.