Os x terminal, ssh i zbyt wiele otwartych plików

Question

Cześć chłopaki: Mam kod, który uruchamia kilka zapytań dotyczących odpoczynku przez połączenie, które jest przekazywane do maszyny AWS (fyi: te zapytania trafiają do serwera Solr działającego na tym systemie maszyna), a zapytania są wykonywane na moim hoście lokalnym (który jest przekazywany do instancji AWS).

Kod początkowo działa świetnie, pobierając dane w razie potrzeby, ale po uruchomieniu na chwilę kod zostanie zatrzymany (w czasie zaćmienia).

Na taką chwilę, terminal (czyli gdzie zacząłem moją ssh tunel) przechodzi całkowicie zamrożone, napełniając się z ciągu:

„Accept: zbyt wiele otwartych plików”

Bo ten nieskończony wydruk nie jest związany z terminalem Bash (tzn. nie mogę powiedzieć, że połączenie ssh jest wciąż aktywne lub nie, a nie ma tekstu wskazującego, która skorupa jest w ... tylko niepakowane, nieustające instrukcje drukowania) Nie mogę powiedzieć Wiem, że pochodzi z Amazona lub z mojego terminalu klienta.

chcę znaleźć przyczynę tego problemu i wskazać urządzenie, które jest przyczyną mojego terminala eksplodować

Aby sprawdzić, który z dwóch maszyn było przyczyną nieskończone wydruków błędu, wpadłem komenda ulimit na serwerze ... i znalazła , że maksymalna dopuszczalna liczba otwartych plików (na serwerze aws) była znacznie większa niż ilość otwartych plików (określana również przy użyciu ulimit) w dowolnym momencie, podczas gdy program klienta (uruchamiany z moje ide) wykonuje.

Zrobiłem ten sam test na moim kliencie i nie stwierdziłem znaczącego wzrostu liczby otwartych plików.

Niektóre szczegóły strony: Mam kilkaset zapytań do serwera SOLR, który ma ponad 100 GB danych w krótkim czasie.

Wszelkie podpowiedzi o tym, jak ustalić, dlaczego mój terminal sshd mac os x umiera i nieskończenie drukuje ten komunikat byłby potencjalnie bardzo przydatny dla mnie. Oczywiście, czy nie były one specyficzne dla solr. To powiedziawszy, jakikolwiek wgląd w to, dlaczego tak się stało podczas korzystania z usługi solr, może również pomóc w rozwiązaniu tego problemu.

Answer 1

Nie ma tu wystarczających informacji, ale brzmi to tak, jakby ssh trafiał na swój limit deskryptorów plików podczas próbowania akceptowania połączeń z przekazywanym gniazdem lokalnie, co z kolei sugeruje, że już otwarte połączenia nie są być zamknięte w odpowiednim czasie. Możesz uruchomić ssh z -d, aby zobaczyć szczegóły połączeń i rozłączeń; możesz chcieć przechwycić jego stderr i użyć skryptu do śledzenia operacji gniazda, ponieważ będą one pochowane w wielu innych danych debugowania.

Należy pamiętać, że sama ssh może ograniczyć otwarte deskryptory plików poza domyślną, aby uniknąć ataków typu "odmowa usługi" na przekazywany port; Nie widzę w tym żadnej wskazówki, ale tego rodzaju rzeczy można się spodziewać.

Answer 2

można spróbować patrząc na ulimit (przez przyłącza):

ulimit -a 

szczególności sprawdzić wartość dla open files. Na moim komputerze (OS X) raportuje 256.Może chcesz spróbować zwiększyć ją do 512:

ulimit -n 512 

Answer 3

Wydaje się, że pracował dla mnie:

echo 'kern.maxfiles=20480' | sudo tee -a /etc/sysctl.conf 
echo -e 'limit maxfiles 8192 20480\nlimit maxproc 1000 2000' | sudo tee -a /etc/launchd.conf 
echo 'ulimit -n 4096' | sudo tee -a /etc/profile 

Następnie uruchom OS X.

https://superuser.com/questions/302754/increase-the-maximum-number-of-open-file-descriptors-in-snow-leopard

Answer 4

sudo launchctl limit maxfiles 1000000 unlimited 

lub

sudo sysctl -w kern.maxfilesperproc=1000000 
sudo sysctl -w kern.maxfilesperproc=18000 

dokonać zmiany na stałe, użyj sudo umieścić swoje ustawienia w /etc/sysctl.conf (która może trzeba utworzyć), podobnie jak to:

kern.maxfiles=20480 
kern.maxfilesperproc=18000 

Uwaga - wybrać numer na swój własne ryzyko