about summary refs log tree commit homepage
path: root/lib
diff options
context:
space:
mode:
authorJean Boussier <jean.boussier@gmail.com>2023-09-26 21:40:00 +0000
committerEric Wong <bofh@yhbt.net>2023-12-29 17:46:58 +0000
commite2dfea8b2c74d94b66efc00c2ccab3df7af750a5 (patch)
tree3bf30114684d7d33661e1eb761b21ae11286b7d3 /lib
parentd08f1f34c0e80f36eebe2be04a8a2483be41d14a (diff)
downloadraindrops-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