Github user pwendell commented on a diff in the pull request:
https://github.com/apache/spark/pull/880#discussion_r13159214
--- Diff: docs/configuration.md ---
@@ -260,59 +328,44 @@ Apart from these, the following properties are also
available, and may be useful
<td><code>spark.rdd.compress</code></td>
<td>false</td>
<td>
- Whether to compress serialized RDD partitions (e.g. for
<code>StorageLevel.MEMORY_ONLY_SER</code>).
- Can save substantial space at the cost of some extra CPU time.
+ Whether to compress serialized RDD partitions (e.g. for
+ <code>StorageLevel.MEMORY_ONLY_SER</code>). Can save substantial space
at the cost of some
+ extra CPU time.
</td>
</tr>
<tr>
<td><code>spark.io.compression.codec</code></td>
<td>org.apache.spark.io.<br />LZFCompressionCodec</td>
<td>
- The codec used to compress internal data such as RDD partitions and
shuffle outputs. By default,
- Spark provides two codecs:
<code>org.apache.spark.io.LZFCompressionCodec</code> and
- <code>org.apache.spark.io.SnappyCompressionCodec</code>.
+ The codec used to compress internal data such as RDD partitions and
shuffle outputs.
+ By default, Spark provides two codecs:
<code>org.apache.spark.io.LZFCompressionCodec</code>
+ and <code>org.apache.spark.io.SnappyCompressionCodec</code>.
</td>
</tr>
<tr>
<td><code>spark.io.compression.snappy.block.size</code></td>
<td>32768</td>
<td>
- Block size (in bytes) used in Snappy compression, in the case when
Snappy compression codec is
- used.
+ Block size (in bytes) used in Snappy compression, in the case when
Snappy compression codec
+ is used.
</td>
</tr>
<tr>
- <td><code>spark.scheduler.mode</code></td>
- <td>FIFO</td>
- <td>
- The <a
href="job-scheduling.html#scheduling-within-an-application">scheduling mode</a>
between
- jobs submitted to the same SparkContext. Can be set to
<code>FAIR</code>
- to use fair sharing instead of queueing jobs one after another. Useful
for
- multi-user services.
- </td>
-</tr>
-<tr>
- <td><code>spark.scheduler.revive.interval</code></td>
- <td>1000</td>
- <td>
- The interval length for the scheduler to revive the worker resource
offers to run tasks. (in
- milliseconds)
- </td>
-</tr>
-<tr>
- <td><code>spark.reducer.maxMbInFlight</code></td>
- <td>48</td>
+ <td><code>spark.closure.serializer</code></td>
+ <td>org.apache.spark.serializer.<br />JavaSerializer</td>
<td>
- Maximum size (in megabytes) of map outputs to fetch simultaneously
from each reduce task. Since
- each output requires us to create a buffer to receive it, this
represents a fixed memory
- overhead per reduce task, so keep it small unless you have a large
amount of memory.
+ Serializer class to use for closures. Currently only the Java
serializer is supported.
--- End diff --
That's a good question :P I think this used to be change-able but it was
reverted. I'm not totally sure about the genealogy of this so I'm going to
leave it, but it's worth seeing if we should just remove it.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---