Home

News: Increasing heap size – beware of the Cobra Effect

  1. The term ‘Cobra effect’ stems from an anecdote set at the time of British rule of colonial India. The British government was concerned about the number of venomous cobra snakes. The Government therefore offered a reward for every dead snake. Initially this was a successful strategy as large numbers of snakes were killed for the reward. Eventually however Indians began to breed cobras for the income.

    When this was realized the reward was canceled, but the cobra breeders set the snakes free and the wild cobras consequently multiplied. The apparent solution for the problem made the situation even worse.

    So how is Java heap size related with Colonial India and poisonous snakes? Bear with me and I’ll guide you through the analogy in this blog post.

    Threaded Messages (4)

  2. You seem to ignore one of the most important techniques used network the underlies all of these web applications...call traffic management...you control the rate of allocation by control the degree of concurrent execution and the rate of method invocation

    for (adaptive) concurrency control: http://www.jinspired.com/research/adaptive-control-in-execution

    for (call) rate limiting: http://www.jinspired.com/research/quality-of-service-for-apps

  3. I am not quite sure I have understood your point. Do you mean to limit the throughput by artificially limiting the amount of concurrent users thus decreasing the allocation rate? First of all this only shifts your multi seconds pauses to the future, not eliminate them (well, doesn't guarantee to eliminate them). And secondly limiting number of concurrent users is a straght way to limiting your revenue.

  4. I can limit call throughput in various ways - concurrency or delay (via adaptive resource management). 

    Sorry but I am not shifting time I am managing congestion, contention and/or consumption at a rate that the GC can keep up with...you do understand that behavior of any software changes drastically when overloaded leading to different code paths and longer times...so in fact I can slow things down to go faster...pretty common in rapid/network traffic management...the trick is to slow down to the optimal level which is what adaptive control is all about...please look at the results on the article to see the net effect of this before making such mis-informed statements.

    limiting revenue?...seriously...please read up on quality of service (QoS) and how networks are managed before making such a flippant remark...adaptive traffic management in this case is strking the correct balance between response time and throughput...making the experience must better (at least much more stable and consistent).

     

  5. Ok, now I got it. Yes, in highly congested situations, especially in optimistic locking "fail-and-retry" algorithms, reducing concurrency can actually improve throughput.

    And yes, in some cases, reducing allocation rate can let GC to catch up without hurting customer perception too much. In some cases. But as Gil Tene said, "you cannot eliminate GC pauses, you can only delay them". Which brings us back to the problem of eminent multi second pauses. Because alternative - keeping concurrency low enough - means underutilization.