On Fri, 2018-09-07 at 13:38 -0600, David Boreham wrote:
On 9/6/2018 6:37 PM, William Brown wrote:
>
> I have seen this behaviour due to an issue in the design of access
> log
> buffer flushing. During a buffer flush all other threads are
> delayed,
> which can cause this spike.
>
> You can confirm this by changing your access log buffer size up or
> down.
>
> Sadly this problem is not simply fixed without a complete rewrite
> of
> the logging subsystem - which I would love to do, but I am not
> employed
> to work on 389 at this time so I lack the time.
>
>
Interesting to see this because when I first ran performance tests
on
the DS, around 20 years ago, I quickly discovered that the logging
code
was a bottleneck. So I re-wrote it with in-memory ping-pong
buffering
for the operation threads' log output, and removed any synchronous
filesystem writes. I expect that in the years since perhaps
concurrency
bugs led to that that code being removed, or it could be that it no
longer performs well with modern hardware.
Could be both. Modern hardware is especially bad at handling any
situation where locking get's involved due to the highly async nature
of modern CPU's and their cache layers.
There is a lot on my "todo list" to rearchitect to make the code
scalable on modern systems today. A lot of what I want to do is
directly inspired by erlang's actor model and concurrent readability.
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to
389-users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje... --
Sincerely,
William