GNU/Linux >> Znalost Linux >  >> Linux

Proč git selže při push/fetch s příliš mnoha otevřenými soubory

Existují dvě podobné chybové zprávy:

EMFILE: Too many open files
ENFILE: Too many open files in system

Zdá se, že dostáváte EMFILE , což znamená, že je překročen počet souborů pro jednotlivý proces. Takže zkontrolujte, zda vi možnost otevřít soubory je irelevantní – vi bude používat vlastní samostatnou tabulku souborů. Zkontrolujte své limity pomocí:

$ ulimit -n
1024

V mém systému je tedy limit 1024 otevřených souborů v jednom procesu. O zvýšení limitu byste neměli žádat správce systému (nepoužívejte prosím zkratku SA, je příliš neprůhledná; pokud musíte zkrátit, použijte „sysadmin“).

Možná budete chtít zkontrolovat, které soubory Git otevírá, spuštěním Gitu pod strace .

Může to být chyba v Gitu nebo v knihovně, nebo to může být, že používáte starou verzi něčeho, nebo to může být něco bizarnějšího. Zkuste strace nejprve zjistit, které soubory otevírá, a zkontrolovat, zda Git tyto soubory zavírá.

Aktualizace od společnosti Hazok:

Po použití výše uvedených doporučení se ukázalo, že chyba byla způsobena příliš velkým množstvím uvolněných předmětů. Bylo tam příliš mnoho volných objektů, protože git gc nebyl provozován dostatečně často.


Proč se to stalo?

Z dokumentace git:

Když je v úložišti přibližně více než toto množství volných objektů, git gc --auto je zabalí. Některé příkazy Porcelain tento příkaz čas od času používají k provedení lehkého sběru odpadu. Výchozí hodnota je 6700.

Zde "Některé příkazy porcelánu" zahrnuje git push , git fetch atd. Pokud je tedy maximální limit otevřených souborů ulimit -n <6700, budete nakonec zablokováni git gc --auto jakmile získáte ~6700 volných objektů v jediném git repo.

Spěchám. Jak to opravit?

Pokud máte dostatečná oprávnění k úpravě systémového ulimit:

$ sudo ulimit -n 8192

V opačném případě můžete zakázat git gc nastavením git config gc.auto 0 , takže můžete poslat své místní commity do vzdáleného zařízení, odstranit repo a naklonovat jej zpět bez tisíců uvolněných objektů.

Jak můžeme zabránit tomu, aby se to opakovalo?

Nastavte git config --global gc.auto 200 , kde 200 je o nějakou hodnotu nižší, než je váš maximální limit otevřených souborů. Pokud jste vybrali příliš malou hodnotu, git gc by běžel příliš často, takže vybírejte moudře.

Pokud nastavíte gc.auto=0 , volné objekty nebudou nikdy zabaleny, pokud nespustíte git gc ručně. Ve stejném adresáři tedy mohou být nahromaděny statisíce souborů, což může být problém, zejména pro uživatele mechanického pevného disku nebo Windows. (Viz také:Kolik souborů v adresáři je příliš mnoho? a Je v pořádku (z hlediska výkonu) mít stovky nebo tisíce souborů ve stejném adresáři Linuxu?).


Linux
  1. Proč se příkaz Ls pomalu přerušuje v adresáři Nfs se spoustou souborů?

  2. Proč Files (nautilus) otevírá nové okno, i když je již jedno otevřené?

  3. Proč selže sed s mezinárodními znaky a jak to opravit?

  1. Proč Tomcat pracuje s portem 8080, ale ne s 80?

  2. bash:/bin/tar:Při komprimaci mnoha souborů pomocí tar je seznam argumentů příliš dlouhý

  3. Proč tento kód selhává při zapnuté randomizaci adres?

  1. Proč se vypnutí net rpc nezdaří se správnými přihlašovacími údaji?

  2. Co Linux dělá s existujícími soubory v přípojném bodě?

  3. Proč se aktualizace yum nezdaří v CentOS 6.4?