gen_server locked for some time

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Mon Dec 2 15:56:53 CET 2019


Another path is to cooperate the bulk write in the process. Write in small
chunks and go back into the gen_server loop in between those chunks being
written. You now have progress, but no separate process.

Another useful variant is to have two processes, but having the split
skewed. You prepare iodata() in the main process, and then send that to the
other process as a message. This message will be fairly small since large
binaries will be transferred by reference. The queue in the other process
acts as a linearizing write buffer so ordering doesn't get messed up. You
have now moved the bulk write call out of the main process, so it is free
to do other processing in between. You might even want a protocol between
the two processes to exert some kind of flow control on the system.
However, you don't have an even balance between the processes. One is the
intelligent orchestrator. The other is the worker, taking the block on the
bulk operation.

Another thing is to improve the observability of the system. Start doing
measurements on the lag time of the gen_server and plot this in a
histogram. Measure the amount of data written in the bulk message. This
gives you some real data to work with. The thing is: if you experience
blocking in some part of your system, it is likely there is some kind of
traffic/request pattern which triggers it. Understand that pattern. It is
often covering for some important behavior among users you didn't think
about. Anticipation of future uses of the system allows you to be proactive
about latency problems.

It is some times better to gate the problem by limiting what a
user/caller/request is allowed to do. As an example, you can reject large
requests to the system and demand they happen cooperatively between a
client and a server. This slows down the client because they have to wait
for a server response until they can issue the next request. If the
internet is in between, you just injected an artificial RTT + server
processing in between calls, implicitly slowing the client down.


On Fri, Nov 29, 2019 at 11:47 PM Roberto Ostinelli <ostinelli@REDACTED>
wrote:

> All,
> I have a gen_server that in periodic intervals becomes busy, eventually
> over 10 seconds, while writing bulk incoming data. This gen_server also
> receives smaller individual data updates.
>
> I could offload the bulk writing routine to separate processes but the
> smaller individual data updates would then be processed before the bulk
> processing is over, hence generating an incorrect scenario where smaller
> more recent data gets overwritten by the bulk processing.
>
> I'm trying to see how to solve the fact that all the gen_server calls
> during the bulk update would timeout.
>
> Any ideas of best practices?
>
> Thank you,
> r.
>


-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20191202/c486a4aa/attachment.htm>


More information about the erlang-questions mailing list