diff options
author | Jean Boussier <jean.boussier@gmail.com> | 2023-09-26 21:40:00 +0000 |
---|---|---|
committer | Eric Wong <bofh@yhbt.net> | 2023-12-29 17:46:58 +0000 |
commit | e2dfea8b2c74d94b66efc00c2ccab3df7af750a5 (patch) | |
tree | 3bf30114684d7d33661e1eb761b21ae11286b7d3 /lib | |
parent | d08f1f34c0e80f36eebe2be04a8a2483be41d14a (diff) | |
download | raindrops-e2dfea8b2c74d94b66efc00c2ccab3df7af750a5.tar.gz |
I just debugged an issue with our system, I was witnessing the number of file descriptor in our process grow at an alarming rate which I mapped to our use of raindrops to report utilisation. For various reasons we don’t call raindrops from a Rack middleware but have one process that monitor the socket continuously, and share that data with the workers. Since we call tcp_listener_stats every seconds in a process that doesn't do much else, GC very rarely triggers if at all which cause `InetDiagSocket` instances to accumulate very quickly. Each of those instances holds a file descriptor. Looking at the raindrops implementation it seems to assume the GC will take care of regularly closing these sockets, but I think it’s a bit too bold of an assumption. [ew: don't close user-passed sockets on exception] Acked-by: Eric Wong <e@80x24.org>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions