2015-07-23 14 views
5

Sto aggiornando un membro del set di repliche secondario a wiredTiger. L'ho aggiornato da MongoDB dalla 2.6.3 alla 3.0.4 e cambiato il motore di archiviazione su wiredTiger. Ora sta resinciando tutti i dati dal primario. Ad un certo punto è ricevuto il seguente errore, e il processo ricomincia:WiredTiger - "errore di file aperti troppi" durante la risincronizzazione di un membro del set di repliche secondario

2015-07-22T13: 18: 55,658 + 0000 I INDEX [rsSync] costruzione dell'indice mediante metodo bulk

2015 -07-22T13: 18: 55.664 + 0000 I INDICE [rsSync] indice di costruzione terminato. scansionato 1591 record totali. 0 sec

2015-07-22T13: 18: 56,397 + 0000 E STOCCAGGIO [rsSync] WiredTiger (24) [1.437.571,136 mila: 397083] [20413: 0x7f3d9ed29700], il file: WiredTiger.wt, session.create: WiredTiger.turtle : fopen: Troppi file aperti

2015-07-22T13: 18: 56.463 + 0000 E REPL [rsSync] 8 24: Troppi file aperti

2015-07-22T13: 18: 56,463 + 0000 E REPL [rsSync] tentativo di sincronizzazione iniziale non riuscito, 9 tentativi rimanenti

La stessa macchina eseguiva in precedenza la versione 2.6.3 wi tutti i problemi relativi ai limiti di file aperti. Sono consapevole che wiredTiger potrebbe creare molti più file, quindi deve essere così, ma li tiene tutti aperti contemporaneamente?

Per riferimento:

cat/proc/sys/fs/file-max

Nel /etc/init.d/mongod la configurazione è:

ulimit -n 64000

Secondo la documentazione sembra che mongo detenga un descrittore di file per ogni file di dati. Come in wiredTiger questo risulta in un file per ogni collezione + un file per ogni indice, in base a un calcolo per il nostro caso, può aggiungere fino a oltre 700K.

Quindi posso modificare l'ulimit a 700000 o superiore, ma mi chiedo se questa sia la soluzione più corretta e quali alternative esistono.

+0

È necessario verificare i limiti imposti al processo stesso (non necessariamente le impostazioni del sistema). C'è un comodo script qui che fa questo per te: http://docs.mongodb.org/manual/reference/ulimit/#proc-file-system –

+0

Ho controllato anche questo - attualmente il mio /etc/init.d/ lo script mongod viene fornito con 64000 come limite.Credo che questo non sia abbastanza - come con wiredTiger c'è un file separato per ogni raccolta + ogni indice, quindi per un DB di 100 collezioni e circa 10-20 indici per collezione in media, sto ricevendo circa 1000-2000 file per DB e stiamo parlando di centinaia di DB. –

risposta

4

WiredTiger sarà clean up open file descriptors in base a quanto a lungo sono rimasti inattivi, ma durante attività pesanti su un gran numero di raccolte e indici finirai per essere delimitati da ulimit su file aperti.

Quindi, sì, in pratica è necessario aumentare il limite fino a quando non si verifica più il problema, attenersi a MMAPv1 o consolidare alcune raccolte. Raccomanderei inoltre di presentare una richiesta di funzionalità che descriva il caso d'uso con i numeri di esempio per prevenire questo tipo di modello (ad esempio, più di una raccolta per file).

Problemi correlati