Port locks with high time under LCNT

[Frank Muller]

Hi John

Thanks for clarifying the fact that sendfile call being synchronous (maybe
this info should be be added to the doc).

Switching from prim_file:sendfile to file:pread + gen_tcp:send (per @Max
Lapshin suggestion) gave me a different landscape in term of locks:
https://gist.github.com/frankmullerl/d9e8379b8250d84c5b170577c2ad3b89

Tail latency (+99%ile) is still high and the throughput more a less the
same.

How can I interpret these new LCNT info to improve things?

Best
/Frank


Tue 7 janv. 2020 at 13:05, John Högberg <john@REDACTED> wrote :

> What you're seeing is caused by how we're using the `sendfile(2)` system
> call. Like all other file operations it's impossible to make it
> non-blocking on Linux, and since it's used from the output callback in the
> inet driver it will block the scheduler until completion (while the port
> lock is held, hence its visibility with `lcnt`). Fixing this is non-trivial
> so we might force it to use the read/send fallback in a patch.
>
> /John
>
> On Sat, 2020-01-04 at 11:39 +0100, Frank Muller wrote:
>
> Gonna update my design, test and report back
>
> /Frank
>
> Sat. 4 janv. 2020 at 09:30, Max Lapshin <max.lapshin@REDACTED> wrote :
>
> Yes.
> And we repack from mp4 to mpegts on fly.  We cannot do sendfile due to
> this requirement and it happened that we do not need to do it.
>
> So 10 gbps is an absolutely normal load for E5.
>
> But of course you need to be not green =)  Disable all powersave.
>
> On Sat, Jan 4, 2020 at 10:59 AM Frank Muller <frank.muller.erl@REDACTED>
> wrote:
>
> Hi Max
>
> Those numbers are amazing. Can you please elaborate more?
>
> So, you read data from disk with file:pread/3 and send it out using
> gen_tcp:send/2. Am I right?
>
> /Frank
>
> Sat. 4 janv. 2020 at 08:32, Max Lapshin <max.lapshin@REDACTED> wrote :
>
> I advise to try to refuse from sendfile and use pread/write
>
> Our Flussonic can serve 10-20 gigabits per second. We have removed all
> "optimisations"  like mmap and so on and left with
> old plain read/write.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200107/be6bc3ea/attachment.htm>