Uaktualniam element zestawu repliki wtórnej do elementu wiredTiger. Uaktualniłem go z wersji MongoDB 2.6.3 do wersji 3.0.4 i zmieniłem silnik pamięci na wiredTiger. Teraz synchronizuje wszystkie dane z podstawowego. W pewnym momencie odbierany jest następujący komunikat o błędzie, a proces zaczyna się od nowa:WiredTiger - "błąd zbyt wielu otwartych plików" podczas resynchronizacji elementu zestawu repliki wtórnej
2015-07-22T13: 18: 55,658 + 0000 I INDEX [rsSync] indeksu przy użyciu metody bulk budowy
2015 -07-22T13: 18: 55.664 + 0000 I Sporządzono indeks indeksu [rsSync]. zeskanowanych 1591 rekordów ogółem. 0 sekund
2015-07-22T13: 18: 56,397 + 0000 E przechowywaniu [rsSync] WiredTiger (24) [1437571136: 397083], [20413: 0x7f3d9ed29700] Plik: WiredTiger.wt, session.create: WiredTiger.turtle : fopen: zbyt wiele otwartych plików
2015-07-22T13: 18: 56.463 + 0000 E rEPL [rsSync] 8 24: Zbyt wiele otwartych plików
2015-07-22T13: 18: 56,463 + 0000 E REPL [rsSync] początkowa próba synchronizacji nie powiodła się, 9 prób pozostało
To samo urządzenie było wcześniej w wersji 2.6.3 w przypadku jakichkolwiek problemów z otwartymi plikami limitów. Jestem świadomy, że wiredTiger może tworzyć znacznie więcej plików, więc to musi być to, ale czy jednocześnie wszystkie są otwarte?
dokumencie:
cat/proc/sys/F/plików maks
W /etc/init.d/mongod konfiguracja jest:
ulimit -n 64000
Zgodnie z dokumentacją wydaje się, że mongo posiada deskryptor pliku dla każdego pliku danych. Podobnie jak w wiredTiger powoduje to, że plik dla każdej kolekcji + plik dla każdego indeksu, zgodnie z obliczeniem dla naszego usecase, może dodać do ponad 700K.
Więc mogę zmienić ulimit na 700000 lub wyższy, ale zastanawiam się, czy jest to najbardziej poprawne rozwiązanie i jakie alternatywy istnieją.
Należy sprawdzić limity nałożone na sam proces (niekoniecznie ustawienie systemowe). Jest tu przydatny skrypt, który robi to za Ciebie: http://docs.mongodb.org/manual/reference/ulimit/#proc-file-system –
Sprawdziłem to również - aktualnie moja /etc/init.d/ skrypt mongod pochodzi z 64000 jako limit.Wierzę, że to nie wystarczy - tak jak w przypadku wiredTiger istnieje osobny plik na każdą kolekcję + każdy indeks, więc dla DB z 100 kolekcji i około 10-20 indeksów na kolekcję średnio otrzymuję około 1000-2000 plików na DB i mówimy o setkach DB. –