Realtime: Les grands inserts étranglent les micro-instances
l'insertion d'un million de lignes en même temps entraîne une utilisation excessive du processeur pendant une période prolongée par la suite, avec ~ 50% de RAM:
testez le code ici: https://raw.githubusercontent.com/supabase/benchmarks/feat/firestore-benchmarks/db/migrations/20201124141199_read_data.sql
a exclu que COPY soit le problème, car l'extrait suivant entraîne également le même comportement:
do $$
begin
for r in 1..1000000 loop
insert into public.read(id, slug) values(r, r);
end loop;
end;
$$;
Le redémarrage du service (processus) ne résout pas le problème
awalias
Tous les 6 commentaires
🤔 Passer à la rouille?
Laissez-moi réfléchir à la façon dont nous pouvons résoudre ce problème - le plan était d'ajouter des flux de travail à ce serveur, ce qui ne fera que le ralentir. Pour le moment, nous analysons chaque événement, puis nous parcourons chaque colonne, donc il y a beaucoup à traverser. De manière réaliste, un utilisateur n'a pas besoin de toutes ces notifications et devrait ajouter des filtres d'événements pour analyser uniquement ce dont il a vraiment besoin
kiwicopple
le 25 nov. 2020
Je suppose que la solution judicieuse pour le moment est de désactiver temporairement la publication supabase_realtime temporairement pour les gros vidages comme celui-ci
awalias
le 25 nov. 2020
Je vois 2 problèmes:
- Le décodage prend beaucoup de temps. Localement, le décodage d'un
INSERTde 1 million de lignes prend plus d'une heure juste à décoder. En revanche, pour un abonnement avec une seconde base de données, le décodage et l'application prennent 5 secondes . - Après le décodage,
SubscribersNotificationplante surhandle_call/3. Peut-être à cause de la taille énorme des arguments, puisque les messages sont envoyés par transaction, c'est-à-dire tous les 1 million de messages décodés à la fois.
J'ai l'impression qu'un NIF Rust qui envoie des messages un par un pourrait avoir du sens ici ...
PS la résolution de ce problème devrait également résoudre les problèmes d'explosion de WAL, car un décodage lent signifie ne pas pouvoir acknowledge_lsn assez rapidement.
soedirgo
le 9 janv. 2021
Le décodage prend beaucoup de temps.
Intéressant. Y a-t-il des fruits à portée de main? S'agit-il du décodage proprement dit ou de l'analyse en différents canaux?
Sinon, si vous pouvez faire un POC rapide du NIF, il peut être bon de comparer
kiwicopple
le 9 janv. 2021
Juste en décodant, il s'est trompé lorsque notify ing SubscribersNotification.
si vous pouvez faire un POC rapide du NIF
👍
soedirgo
le 11 janv. 2021
: tada: Ce problème a été résolu dans la version 0.10.2: tada:
La version est disponible sur la version GitHub
Votre bot sémantique : package :: rocket:
![github-actions[bot] picture](https://avatars.githubusercontent.com/in/15368?v=4&s=40)
github-actions[bot]
le 14 janv. 2021
Questions connexes
awalias
·
5Commentaires
retendo
·
12Commentaires
kiwicopple
·
16Commentaires
kiwicopple
·
14Commentaires
kwakwaversal
·
6Commentaires
Commentaire le plus utile
Je suppose que la solution judicieuse pour le moment est de désactiver temporairement la publication
supabase_realtimetemporairement pour les gros vidages comme celui-ci