[erlang-questions] UDP receive performance

[Сергей Прохоров]

Regarding this suggestion in docs, I had some funny times because I blindly
applied this suggestion on an application with large amount of not very
active sockets.

On my machine default settings for kernel buffers were
[{sndbuf,87040},{recbuf,372480}]

So, I ended up having 360kb userspace buffer per socket and I had like 10s
of thousands of sockets.

And that was very difficult to track down (`erlang:memory()` showed a lots
of `binary` memory, while sum of sizes of binaries referenced by processes
(via `process_info(P, binary)`) was 2 orders of magnitude smaller).
I found the root cause only intuitively and I still don't know if there are
any tool that is able to point me to a right direction. Even
`[erlang:port_info(Port, memory) || Port <- erlang:ports()]` didn't show
this memory.
I also had prometheus BEAM allocators dashboard like this one
https://github.com/deadtrickster/beam-dashboards/blob/master/BEAM-memory_allocators.png
and it showed me 90% allocator utilization. So, nothing looked suspicious
except just extremely high memory usage.

> On Wed, Jun 20, 2018 at 12:07 PM Lukas Larsson <lukas@REDACTED> wrote:
> >
> >> So if anyone is running a performance critical UDP server that has set
> >> the "recbuf" to a high value, I really recommend that you lower the
> >> "buffer" size to something close to the max expected packet size.
> >>
> >
> > That's interesting because the official documentation says:
> >
> > "It is recommended to have val(buffer) >= max(val(sndbuf),val(recbuf)) to
> > avoid performance issues because of unnecessary copying."
> >
> >
> > Maybe the documentation is wrong because that doesn't make much sense;
> > sndbuf and recbuf are sent to the kernel and are supposed to be bigger
> than
> > the user's buffer.
> >
> I think that part of the documentation is mainly written with TCP in mind,
> not UDP. Also, following the docs works fine if it weren't for the bug
> uncovered in this mail thread. I'll see what I can do about making the docs
> better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180621/4438a9ab/attachment.htm>