Wpis z mikrobloga

Czy jest tu ktoś korzystający z #n8n?
Workflow jest stosunkowo prosty
weź plik xlsx -> dołącz jego zawartość do tabeli SQL

I jako taki prosty sobie działa.
Działa z plikami ~200.000 wierszy
Działa z plikami CSV po 200MB

Rzecz w tym, że mam pliki po XLSX po milion wierszy i ważące ~100MB.
I tutaj już nie działa. Mieli godzinami na "read file" bez jakiegokolwiek efektu.

Ktoś ma jakieś pomysły? Najprostszym rozwiązaniem, które przychodzi mi do głowy byłoby chyba czytanie takiego pliku w batchach? Tylko jak?

#selfhosted
  • 6
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@garar2: MA dostęp do 40GB ramu. Przez cały proces wykorzystuje ~3GB. Właśnie nie tędy droga. Żeby było zabawniej to jeszcze wykonałem kilka testów.
Plik 54MB - bez problemu, szybko i sprawnie konwertuje do JSON i wysyła do DB
Plik 58MB - cisza. Użycie procesora leci do 100% i tak się utrzymuje przez kilka godzin do restartu usługi

Myślę, że spokojnie w takiej sytuacji można wyeliminować problemy z brakiem zasobów. Gdzieś
  • Odpowiedz
@garar2: Też z różnymi wartościami kombinowałem w --max-old-space-size i bez zmian.
Ustawiłem też N8NDEFAULTBINARYDATAMODE na filesystem więc binarki powinny być zapisywane na dysku.

To, czego mój umysł nie jest w stanie ogarnąć:
- plik CSV 150MB - przerabia szybko, sprawnie i bez najmniejszego problemu
- plik XLSX 550.000 wierszy -
Dziadzlabem - @garar2: Też z różnymi wartościami kombinowałem w --max-old-space-size ...

źródło: image

Pobierz
  • Odpowiedz
@malamute: Jeszcze nie :)
Ale za to wymieniłem CPU i dzisiaj przychodzi do mnie dodatkowe 32G ramu do serwera :D

Tak prawdę mówiąc nie mam pojęcia o co chodzi i dlaczego tak się dzieje akurat w przypadku tych plików XLSX. Dzisiaj jak znajdę czas to spróbuję zmigrować n8n z sqlite to postgres. Jakoś nie wydaje mi się, żeby pomogło, ale powoli zaczyna mi brakować pomysłów.
Na pewno nie jest to problem fizycznego rozmiaru
  • Odpowiedz