2017-04-10 43 views
10

Występuje sporadyczny błąd z Cloud Functions for Firebase podczas konwersji stosunkowo małego obrazu (2mb). Po pomyślnym ukończeniu tej funkcji zajmuje to około 2000ms lub mniej, a zgodnie z dokumentacją Image Magick powinienem nie widzieć żadnych problemów.Funkcje Cloud for Firebase zabite z powodu przekroczenia limitu pamięci

Próbowałem zwiększyć rozmiar bufora dla polecenia, którego nie można uzyskać z poziomu Firebase, i próbowałem znaleźć alternatywę dla .spawn(), ponieważ może to być przeciążone przez śmieci i spowolnić działanie. Nic nie działa.

Odpowiedz

15

[aktualizacja] Jak sugerował jeden z komentatorów, nie powinno to już stanowić problemu, ponieważ funkcje bazy ogniowej zachowują teraz ustawienia ponownego wdrażania. Dzięki firebase!

Włącza się i nie jest to oczywiste lub udokumentowane, możesz zwiększyć przydział pamięci do swoich funkcji w Google Functions Console. Możesz także zwiększyć czas oczekiwania na długie funkcje. Rozwiązał problem z nadmiarem pamięci i teraz wszystko działa świetnie.

Edytuj: Pamiętaj, że Firebase zresetuje domyślne wartości podczas wdrażania, więc powinieneś pamiętać, aby zalogować się do konsoli i zaktualizować je od razu. Wciąż szukam sposobu na zaktualizowanie tych ustawień za pomocą interfejsu CLI, aktualizacja zostanie zaktualizowana po jej znalezieniu.

+0

nie mogłem znaleźć miejsce do zwiększenia al pamięci lokalizacja dla moich funkcji. Gdzie mam iść na konsoli funkcji? tks! – Walucas

+0

@Walcu Cloud Funkcje> {nazwa twojej funkcji}> Kliknij "Edytuj"> następnie edytuj numer w "alokacji pamięci" – Kirill

+0

Ustawienia funkcji są dla mnie resetowane. –

2

Aktualizacja: Wygląda na to, że zachowują teraz ustawienia ponownego wdrażania, więc możesz bezpiecznie zmieniać alokację pamięci w konsoli chmury!

+0

Dobra wiadomość! Przez jakiś czas nie ponownie składałem pracy, aby uniknąć awarii. Wypróbuje projekt testowy. Wspaniale, jeśli znowu działa! – Kirill

+0

Aktualizacja: resetuje je za każdym razem (i nie wdraża się, ponieważ limit pamięci został przekroczony _at wdrożyć time_, co powoduje problem z kurczakiem i jajkiem). –

10

byłem zagubiony w interfejsie, nie mógł znaleźć żadnej opcji, aby zmienić pamięć, ale w końcu okazało się, że:

  1. idź do Cloud Platform Console Google (nie konsoli Firebase)
  2. Select Cloud Functions w menu
  3. Teraz widzisz tutaj swoją funkcję bazy ogniowej, jeśli jest ona poprawna. W przeciwnym razie sprawdź, czy wybrałeś odpowiedni projekt.
  4. Zignoruj ​​wszystkie pola wyboru, przyciski i elementy menu, kliknij nazwę funkcji funkcji.
  5. Kliknij edytuj (górne menu) i zmień tylko przydzieloną pamięć i kliknij przycisk Zapisz.

Pozdrawiam, Piotr

0

Wydaje domyślny ImageMagick config zasobów funkcje Firebase chmurze nie odpowiada rzeczywistej pamięci przydzielonej do funkcji.

Running identify -list resource w kontekście ciągu Firebase chmurze rentowności funkcję:

File  Area   Memory  Map  Disk Thread Throttle  Time 
-------------------------------------------------------------------------------- 
18750 4.295GB  2GiB  4GiB unlimited  8   0 unlimited 

Domyślna pamięć przydzielona do FCF jest 256 - domyślna instancja ImageMagick uważa, że ​​ma 2GB i dlatego nie przydziela bufor z dysku i może łatwo spróbować przeliczyć pamięć powodującą awarię funkcji na jeden sposób, aby zwiększyć wymaganą pamięć, jak sugerowano powyżej - chociaż nadal istnieje ryzyko, że komunikator spróbuje przeskoczyć, w zależności od przypadku użycia i wartości odstających.

Bezpieczniejsze byłoby ustawienie właściwego limitu pamięci na IM w ramach procesu manipulacji obrazem przy użyciu -limit memory [your limit].Możesz określić swoje zużycie pamięci poprzez uruchomienie logiki IM za pomocą `-debug Cache '- pokaże Ci wszystkie przydzielone bufory, ich rozmiary oraz czy są pamięcią czy dyskiem.

Jeśli komunikator osiągnie limit pamięci, zacznie przydzielać bufory na dysku (odwzorowane na pamięć, a następnie na zwykłe bufory dyskowe). Musisz wziąć pod uwagę własną równowagę między wydajnością we/wy a kosztem pamięci. Cena każdego dodatkowego bajtu pamięć można przydzielić do FCF jest mnożona przez 100ms użytkowania -.., dzięki czemu można szybko rosną

0

Innym rozwiązaniem tutaj byłoby unikać .spawn() całkowicie

jest świetny pakiet przetwarzania obrazu dla węzła o nazwie Sharp że korzysta z biblioteki niskiego poziomu pamięci libvips. Możesz sprawdzić przykład funkcji chmury na Github .

Alternatywnie istnieje wrapper węzła dla ImageMagick (i GraphicsMagick) o nazwie gm. Obsługuje nawet opcję -limit zgłaszania ograniczeń zasobów do komunikatora.

+0

Interesujące. Daje ostry strzał. Problem z Google Cloud polega na tym, że nie możesz naprawdę testować niczego lokalnie i wymaga pchania każdej zmiany za pomocą kodu chmury. Koszt zmiany jest więc wysoki, nawet gdy jest to lepsze rozwiązanie. – Kirill

+1

Powinieneś sprawdzić niektóre z nowych, lokalnych funkcji testowania, które właśnie zostały dodane. Teraz testuj lokalne funkcje wyzwalane i uruchom test jednostkowy na nich. https://firebase.google.com/docs/functions/local-emulator#invoke_storage_and_auth_functions – Kiana

2

Najnowsza komenda wdrażania firebase nadpisuje przydzielenie pamięci na domyślne 256 MB i limit czasu do 60 sekund.

Alternatywnie, w celu określenia żądanego alokacji pamięci, a maksymalny czas zwłoki, używać polecenia gcloud takich jak:

funkcje gcloud beta rozmieścić YourFunctionName --memory = 2048MB --timeout = 540s

Inne opcje, patrz:

https://cloud.google.com/sdk/gcloud/reference/beta/functions/deploy