Realtime: 大插入物扼流圈微实例

创建于 2020-11-25 · 6评论 · 资料来源: supabase/realtime

同时插入一百万行会在以后延长CPU使用率，并增加约50％的RAM：

在此处测试代码： https :

排除COPY是问题所在，因为以下代码段也会导致相同的行为：

do $$
begin
for r in 1..1000000 loop
insert into public.read(id, slug) values(r, r);
end loop;
end;
$$;

重新启动服务（过程）不能解决问题

bug released

资料来源

awalias

最有用的评论

我想目前明智的解决方案是暂时针对此类大型转储暂时禁用supabase_realtime发布

awalias 于 2020-11-25

👍4

🤔会生锈吗？

让我考虑一下如何解决此问题-该计划是将工作流添加到该服务器，这只会使其变慢。目前，我们正在解析每个事件，然后遍历每列，因此要完成很多工作。实际上，用户不需要所有这些通知，而应该添加事件过滤器以仅解析他们真正需要的内容

kiwicopple 于 2020-11-25

😄2

我想目前明智的解决方案是暂时针对此类大型转储暂时禁用supabase_realtime发布

awalias 于 2020-11-25

👍4

我看到2个问题：

解码需要很长时间。在本地，解码一百万行的INSERT只需要一个多小时就可以解码。另一方面，对于具有第二个DB的预订，解码和应用需要5秒钟。
解码后， SubscribersNotification在handle_call/3崩溃。可能是由于参数的庞大，因为每个事务都发送消息，即一次发送所有100万条已解码消息。

我觉得像一个Rust NIF逐个发送消息在这里...

PS修复此问题还应该解决WAL崩溃问题，因为缓慢的解码意味着无法足够快地acknowledge_lsn 。

soedirgo 于 2021-01-09

解码需要很长时间。

有趣。这里有没有低落的水果？是实际的解码还是解析为各种通道？

否则，如果您可以对NIF进行快速POC，则最好进行比较

kiwicopple 于 2021-01-09

只是解码，当notify进入SubscribersNotification时，它会出错。

如果可以对NIF进行快速POC

👍

soedirgo 于 2021-01-11

：tada：版本0.10.2中已解决此问题：：tada：

该版本在GitHub版本上

您的语义发布机器人：package :: rocket：

github-actions[bot] 于 2021-01-14

此页面是否有帮助？

0 / 5 - 0 等级