Skip to content

[SPARK-14289][WIP] Support multiple eviction strategies for cached RDD partitions - #12162

Closed
Earne wants to merge 8 commits into
apache:masterfrom
SCTS:SPARK-14289
Closed

[SPARK-14289][WIP] Support multiple eviction strategies for cached RDD partitions#12162
Earne wants to merge 8 commits into
apache:masterfrom
SCTS:SPARK-14289

Conversation

@Earne

@EarneEarne commented Apr 5, 2016

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

Currently, LRU is the only eviction strategy for cached RDD partitions in Spark.
This pull request will refactor and add support to multiple eviction strategies, such as FIFO, LFU(WIP), LCS(WIP).

How was this patch tested?

Manual test by set "spark.memory.entryEvictionPolicy" to LRU(default), FIFO or LCS.

@EarneEarne changed the title [SPARK-14289][WIP] Add support to multiple eviction strategies for cached RDD partitions[SPARK-14289][WIP] Support multiple eviction strategies for cached RDD partitionsApr 5, 2016
@AmplabJenkins

Copy link
Copy Markdown

Can one of the admins verify this patch?

@rxin

rxin commented Apr 5, 2016

Copy link
Copy Markdown
Contributor

Thanks for the pull request. Is this actually motivated by a real use case, or just doing it because it might be good to support more than one policy?

@Earne

Earne commented Apr 6, 2016

Copy link
Copy Markdown
ContributorAuthor

@rxin The use case that motivate this is about below.

  • Java objects consume a factor of 2-5x more space than the “raw” data inside their fields.

  • Running graphx.LiveJournalPageRank example on a 8 nodes cluster (1 work as Master, each configured with 45GB memory for Spark running in legacy memory management mode). The dataset (about 30GB) is generated by HiBench, while running 5 iterations, time of each iteration is getting worse and worse.

  • By analyzing the log file, I realize that it is because memory space for cached RDD is not sufficient, and lots of partition with high recomputing cost is dropped. Recomputing these partitions brought in lots of time.

  • FIFO can be implemented by initialize entries with LinkedHashMap[BlockId, MemoryEntry[_]](32, 0.75f, false). And even FIFO can get much better performance than LRU.

  • Storage level such as MEMORY_AND_DISK may partial solve the problem, but the effect is not very good.

    An eviction strategy taken the computing cost into consideration may work well (even in unified memory mode or use the MEMORY_AND_DISK level). Some cost-aware replacement policy already exists in K-V stores, such as GD-Wheel(EuroSys’15).

This PR can be separated to below sub-task.

  • Refactor to support more than one policy (LRU, FIFO, LFU).
  • Add a policy that taken the computing cost into consideration.
  • Taken serialize and deserialize cost into consideration.

@mozinrat

Copy link
Copy Markdown

@Earne is something relevant merged in spark 2.0.1, do we have FIFO eviction policy?.
If yes how can I leverage it?

@michaelmior

michaelmior commented May 5, 2017

Copy link
Copy Markdown
Member

This branch appears to be incomplete. The configuration parameter entryEvictionPolicy does not exist and there is a good chunk of the code that is never called.

@HyukjinKwon

Copy link
Copy Markdown
Member

@Earne, is it still active and any opinion on the comments above? Otherwise, I will propose to close this.

@HyukjinKwonHyukjinKwon mentioned this pull request May 17, 2017
@mmakdessii

Copy link
Copy Markdown

I'm working on my thesis to improve cache management systems. But i don't know anything about Spark! I found this program and I don't know how to even run it. If possible, can someone refer to me a video or steps in order to run this file? If i can see a sample implementation of LRU and know how it's made step by step then I'll be able to implement my own algorithm. I would be very grateful if someone can offer their help!

@michaelmior

Copy link
Copy Markdown
Member

As best I can tell, the code that was pushed here is incomplete. However, Spark's default cache eviction policy is LRU. You can find the code which performs eviction here. It basically just works by storing all the data in a LinkedHashMap configured to track which elements were accessed most recently.

@Earne
Earne deleted the SPARK-14289 branch December 21, 2017 13:14
zifeif2 pushed a commit to zifeif2/spark that referenced this pull request Nov 22, 2025
## What changes were proposed in this pull request?
This PR proposes to close PRs ...
- inactive to the review comments more than a month
- WIP and inactive more than a month
- with Jenkins build failure but inactive more than a month
- suggested to be closed and no comment against that
- obviously looking inappropriate (e.g., Branch 0.5)
To make sure, I left a comment for each PR about a week ago and I could not have a response back from the author in these PRs below:
Closesapache#11129Closesapache#12085Closesapache#12162Closesapache#12419Closesapache#12420Closesapache#12491Closesapache#13762Closesapache#13837Closesapache#13851Closesapache#13881Closesapache#13891Closesapache#13959Closesapache#14091Closesapache#14481Closesapache#14547Closesapache#14557Closesapache#14686Closesapache#15594Closesapache#15652Closesapache#15850Closesapache#15914Closesapache#15918Closesapache#16285Closesapache#16389Closesapache#16652Closesapache#16743Closesapache#16893Closesapache#16975Closesapache#17001Closesapache#17088Closesapache#17119Closesapache#17272Closesapache#17971
Added:
Closesapache#17778Closesapache#17303Closesapache#17872
## How was this patch tested?
N/A
Author: hyukjinkwon <gurwls223@gmail.com>
Closesapache#18017 from HyukjinKwon/close-inactive-prs.
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@Earne@AmplabJenkins@rxin@mozinrat@michaelmior@HyukjinKwon@mmakdessii