Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prewarm eviction variance #4916

Merged

Conversation

tysonnorris
Copy link
Contributor

When enabling reactive prewarm configs, if batches of prewarms are removed at the same time across invokers, we end up with a herd of container deletion and creation at the same time, especially if invokers startup at the same time. This can cause scheduling challenges particularly in mesos or kubernetes. Given that these prewarm containers are not in use, we should try to alleviate any extra issues the prewarm state changes may cause, and allow them to linger slightly longer, if there is a benefit to the scheduling system.

Description

Related issue and scope

  • I opened an issue to propose and discuss this change (#????)

My changes affect the following components

  • API
  • Controller
  • Message Bus (e.g., Kafka)
  • Loadbalancer
  • Invoker
  • Intrinsic actions (e.g., sequences, conductors)
  • Data stores (e.g., CouchDB)
  • Tests
  • Deployment
  • CLI
  • General tooling
  • Documentation

Types of changes

  • Bug fix (generally a non-breaking change which closes an issue).
  • Enhancement or new feature (adds new functionality).
  • Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

This PR adds some configs and sensible defaults to allow the reactive prewarm config affects to be varied across invokers to smooth out deletion and rescheduling of prewarm containers:

    prewarm-expiration-check-interval: 1 minute # period to check for prewarm expiration
    prewarm-expiration-check-interval-variance: 10 seconds # varies expiration across invokers to avoid many concurrent expirations
    prewarm-expiration-limit: 100 # number of prewarms to expire in one expiration cycle (remaining expired will be considered for expiration in next cycle)
  • I signed an Apache CLA.
  • I reviewed the style guides and followed the recommendations (Travis CI will check :).
  • I added tests to cover my changes.
  • My changes require further changes to the documentation.
  • I updated the documentation where necessary.

@@ -1195,4 +1199,24 @@ class ContainerPoolObjectTests extends FlatSpec with Matchers with MockFactory {
pool = pool - 'first
ContainerPool.remove(pool, MemoryLimit.STD_MEMORY) shouldBe List('second)
}

it should "remove expired in order of expiration" in {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add one more test case to make sure no more than prewarmExpirationLimit containers are removed?

Copy link
Member

@style95 style95 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change looks good to me with one minor nit.

Copy link
Contributor

@jiangpengcheng jiangpengcheng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@style95 style95 closed this Jul 7, 2020
@style95 style95 reopened this Jul 7, 2020
@tysonnorris tysonnorris merged commit 470eaf5 into apache:master Aug 9, 2020
@tysonnorris tysonnorris deleted the prewarm-eviction-variance branch August 9, 2020 16:19
Sign up for free to 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.

None yet

5 participants