Najnowszy blog

Nie zwiększaj najpierw wartości max_connections. Zmierz sesje Immich, zsumuj zapotrzebowanie wszystkich kontenerów, zachowaj rezerwę dla administratora i dostosuj tylko faktycznie potwierdzone wąskie gardło.

Oddziel powtarzające się zadania od zduplikowanych zasobów. Użyj jednej kanonicznej ścieżki pozyskiwania danych, kontroluj ponowne próby i zmiany ścieżek, a następnie przetestuj ponowne wprowadzanie na małej grupie.

Nigdy nie usuwaj dziennika WAL PostgreSQL, aby zwolnić miejsce. Zatrzymaj operacje zapisu w Immich, zachowaj stan bazy danych, bezpiecznie zwiększ pojemność, odzyskaj działanie PostgreSQL, a następnie zapobiegaj ponownemu wystąpieniu problemu.

Immich nie powinien po cichu odtwarzać brakujących oryginałów źródłowych. Zidentyfikuj typ i autora ponownie wygenerowanego pliku, a następnie napraw dane dotyczące jego utworzenia.

Najpierw ustal, która ścieżka uległa zmianie: zarządzane katalogi główne multimediów i ścieżki importu bibliotek zewnętrznych mają różne zasady migracji oraz obsługi nieaktualnych danych.

Zachowaj stary host Immich bez zmian, dopóki przywrócony serwer nie potwierdzi tożsamości, multimediów, relacji, zapisów, restartów oraz utworzenia nowej kopii zapasowej możliwej do odzyskania w rzeczywistym użytkowaniu.

Rozdzielony układ Immich często sprawdza się dobrze: SSD na bazę danych i często używane wygenerowane dane, HDD na oryginały, a każda ścieżka ma odpowiednią pojemność, kopię zapasową i została przetestowana po ponownym uruchomieniu.

Kopia zapasowa może uruchamiać zadania związane z procesorem, uczeniem maszynowym, wideo, bazą danych i dyskiem po zakończeniu przesyłania. Przed zmianą chłodzenia lub współbieżności dopasuj prędkość wentylatora do aktywnej kolejki.