Memory leak problem

[dsnipe]

Hey!
Thanks for a great library.
We use it in production under high load, but after one month or so we experienced out of memory on the server. We found that the reason is this library.
Our usage example (it's a plug):

# SKIP
  defp check_rate(conn, options) do
    interval_milliseconds = options[:interval_seconds] * 1000
    max_requests = options[:max_requests]
    ExRated.check_rate(bucket_name(conn), interval_milliseconds, max_requests)
  end

  # Bucket name should be a combination of ip address and request path, like so:
  #
  # "127.0.0.1:/api/v1/authorizations"
  defp bucket_name(conn) do
    path = Enum.join(conn.path_info, "/")
    ip   = conn.remote_ip |> Tuple.to_list |> Enum.join(".")
    "#{ip}:#{path}"
  end
# SKIP

And configurations: config :ex_rated, :timeout, 600_000
In my controller: plug MyApp.Plug.RateLimit, max_requests: 5, interval_seconds: 60

Maybe you have any ideas what might be a problem? Of course I'll try to investigate it and if I find a solution, will create a PR.

[grempe]

Interesting. No I don't have any idea why, and I have not been actively using or maintaining this lib to be honest so if you do find a reason a pull request would be greatly appreciated!

[sergiotapia]

@dsnipe This uses ETS for saving bucket information - could it be you're never purging stale bucket data?

[ryanwinchester]

@dsnipe did you ever solve this? I wanted to use this in a production application as well, but now I'm scared to.

[grempe]

I'll mark this as help wanted as I don't currently have the time to investigate. I suspect there is an edge case at play here though as this lib has been used by others in production for a couple of years now with no similar reports.

@dsnipe Can you provide more information as to how you determined that it was this lib that was seemingly at fault for your server memory issue?

There is an automatic pruning process for old ETS records which should limit the growth of the ETS tables with old buckets.

[sergiotapia]

@grempe There's also the issue where adding ex_rated to a Phoenix project essentially turns the application single-threaded since every request goes through the exrated genserver. It becomes a bottleneck.

[jaimeiniesta]

@sergiotapia can you please elaborate further in a separate issue? If if makes every request pass through the exrated bottleneck, then that's serious.

[ryanwinchester]

https://dockyard.com/blog/2017/05/19/optimizing-elixir-and-phoenix-with-ets

[sergiotapia]

@jaimeiniesta It makes every single request go through the single genserver process. It is really bad. I didn't notice this issue but Chris McCord mentioned it to me and said it was a major problem; turning Phoenix apps into a single-threaded app.

He then pointed me to this article: https://dockyard.com/blog/2017/05/19/optimizing-elixir-and-phoenix-with-ets

[jaimeiniesta]

But, you mean every single request that uses ExRated, right? Or every single request? It's bad in both cases, but not as bad in the first case.

[dsnipe]

It turned out that ex_rated wasn't a problem. I can close the issue.

[dsnipe]

Thank you everyone and sorry for a false alarm.

[sergiotapia]

@jaimeiniesta Yes, every single request that uses exrated.