Realtime: Los insertos grandes obstruyen las micro instancias

Creado en 25 nov. 2020 · 6Comentarios · Fuente: supabase/realtime

insertar 1 millón de filas al mismo tiempo provoca un uso excesivo de la CPU durante un período prolongado posteriormente, junto con ~ 50% de RAM:

código de prueba aquí: https://raw.githubusercontent.com/supabase/benchmarks/feat/firestore-benchmarks/db/migrations/20201124141199_read_data.sql

descartó que el problema sea COPY, ya que el siguiente fragmento también da como resultado el mismo comportamiento:

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

Reiniciar el servicio (proceso) no resuelve el problema

bug released

Fuente

awalias

Comentario más útil

Supongo que la solución sensata por ahora es deshabilitar temporalmente la publicación supabase_realtime temporalmente para volcados grandes como este

awalias en 25 nov. 2020

👍4

Todos 6 comentarios

🤔 ¿Moverse a oxidarse?

Permítanme pensar en cómo podemos resolver esto: el plan era agregar flujos de trabajo a este servidor, lo que solo lo hará más lento. En este momento, estamos analizando cada evento y luego recorriendo cada columna, por lo que hay mucho que superar. De manera realista, un usuario no necesita todas estas notificaciones y debería agregar filtros de eventos para analizar solo lo que realmente necesita

kiwicopple en 25 nov. 2020

😄2

Supongo que la solución sensata por ahora es deshabilitar temporalmente la publicación supabase_realtime temporalmente para volcados grandes como este

awalias en 25 nov. 2020

👍4

Veo 2 problemas:

Decodificación tarda un tiempo muy largo. Localmente, la decodificación de un INSERT de 1 millón de filas lleva más de una hora solo para decodificar. Por otro lado, para una suscripción con un segundo DB, la decodificación y la aplicación demoran 5 segundos .
Después de decodificar, SubscribersNotification bloquea en handle_call/3 . Quizás debido al enorme tamaño de los argumentos, ya que los mensajes se envían por transacción, es decir, 1 millón de mensajes decodificados a la vez.

Me siento como un Rust NIF que envía mensajes uno por uno podría tener sentido aquí ...

PD: solucionar este problema también debería solucionar los problemas de explosión de WAL, ya que la decodificación lenta significa no poder acknowledge_lsn lo suficientemente rápido.