Dlaczego otrzymuję odmowę połączenia po 1024 połączeniach?


Testuję na lokalnym serwerze Linux z serwerem i klientem na tym samym serwerze. Po około 1024 połączeniach w moim kodzie, w których się łączę, otrzymuję odmowę połączenia. Na początku myślałem, że to limit 1024 fd_set_max dla select i zmieniłem serwer, aby przeprowadzał ankietę zamiast wyboru, i nadal nie mogę przekroczyć tej liczby. Mój ulimit-n jest ustawiony na 2048 i śledzę lsof na serwerze, wzrasta do około 1033 (nie jestem pewien, czy to dokładna liczba) i kończy się niepowodzeniem. Każda pomoc jest mile widziana.
2021-03-02 Dodaj komentarz
Udostępnij to

Nie znaleziono powiązanych wyników

    Zaproszony:
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Jeśli łączysz się szybciej niż Twój serwer wywołuje
    accept ()
    , oczekujące połączenia mogą być pełne. Maksymalna długość kolejki jest ustawiana przez drugi argument
    listen ()
    na serwerze lub przez
    sysctl net.core.somaxconn
    (zwykle 128), jeśli jest mniejszy.
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Być może osiągnąłeś limit procesu dla otwartych deskryptorów plików.
    Nie jestem pewien, czy dobrze cię zrozumiałem: czy masz zarówno stronę serwera, jak i klienta w tym samym procesie? Wtedy użyjesz dwa razy więcej deskryptorów plików. Jest to zbliżone do tego, co widzisz z wężem. Jeśli tak nie jest, czy problem może wystąpić po stronie serwera? Proces serwera mógł zabraknąć deskryptorów i nie może już tego zrobić

    brać

    brak połączeń.
    Na

    akceptacja strony podręcznika
    http://manpages.ubuntu.com/man ... .html
    wspomina się, że powinieneś otrzymać zwracaną wartość:

    EMFILE

    Osiągnięto limit liczby otwartych deskryptorów plików dla każdego procesu.
    ENFILE

    Osiągnięto limit systemowy dotyczący całkowitej liczby otwartych plików.

    Jaki kod błędu otrzymujesz? Oczywiście możesz dodawać tylko połączenia, które zostały pomyślnie _akceptowane

    select

    lub

    poll

    .
    Wiem, że już wiesz, jak to sprawdzić

    ulimit
    , ale inni mogą nie wiedzieć: 
    ulimit -a
    
core file size (blocks, -c) 0
    
data seg size (kbytes, -d) unlimited
    
scheduling priority (-e) 0
    
file size (blocks, -f) unlimited
    
pending signals (-i) 40448
    
max locked memory (kbytes, -l) 32
    
max memory size (kbytes, -m) unlimited
    
open files (-n) 4096
    
pipe size (512 bytes, -p) 8
    
POSIX message queues (bytes, -q) 819200
    
real-time priority (-r) 0
    
stack size (kbytes, -s) 8192
    
cpu time (seconds, -t) unlimited
    
max user processes (-u) 40448
    
virtual memory (kbytes, -v) unlimited
    
file locks (-x) unlimited
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Miałem te same objawy. Nawet po zwiększeniu ulimit-n nadal nie mogłem obsłużyć więcej niż 1024 połączeń przychodzących ...
    Mój problem polegał na tym, że używałem select, który nie radzi sobie z gniazdami FD powyżej 1024. Więc kiedy zwiększyłem swój limit, mój problem naprawdę się zmienił !!! (czego na początku nie zauważyłem ...)
    Dlatego, aby pomóc każdemu z podobnymi problemami:

    Jeśli potrzebujesz więcej niż 1024 gniazd, powinieneś to zrobić

    • zwiększać Twój limit dla otwartych FD (ulimit -n)
    • a ty nie można użyć funkcji wyboru () (zamiast tego użyj poll ())
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Widziałem komentarz, który zrobiłeś z instrukcją close (sock_fd) w procedurze błędu.
    Jawnie zamykasz gniazda po ich użyciu - close () lub shutdown ().
    Nie sądzę. Czy naprawdę masz ponad 1024 jednoczesnych aktywnych połączeń? Aby to zrobić, będziesz musiał mieć zaangażowane pthreads. Prawda?
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Czy istnieje niebezpieczeństwo, że serwer otworzy osobny plik dziennika dla każdego zaakceptowanego połączenia?
    Jaki jest górny limit według innej grupy, którą ma serwer?
    Jeden program, którym się opiekowałem (kilka lat temu) miał kod, który ustawiał maksymalny rozmiar pliku na 1 MB. Szkoda, że ​​kiedy został dodany po raz pierwszy, powiększył się, ale z biegiem czasu i limitami plików później, oznaczało to, że zmniejszył się! Czy jest szansa, że ​​serwer ma podobny problem - ustawia maksymalną liczbę otwartych plików na śmiesznie dużą liczbę, np. 1024?
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Przepraszamy za najczęściej błahe pytania :)

    Czy przekompilowałeś serwer, gdy powiedziałeś „zmieniono na ankietę”? Czy serwer działa na tym samym koncie? Czy jest to
    fork
    -ing, czy może serwer strumieniowy? Czy otrzymujesz
    errno == ECONNREFUSED
    po wywołaniu
    connect ()
    na kliencie? Czy możesz potwierdzić, że otrzymujesz
    RST
    w odpowiedzi na
    SYN
    z
    tcpdump
    ? Czy numery portów klientów są ponownie wykorzystywane? Czy są linki w stanie
    TIME_WAIT
    ?
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Twoje ograniczenie wynika z ograniczeń użytkowników Linuksa. Jeśli nie zostanie określony, limity Linuksa to 1024 otwartych plików. Aby to zmienić na stałe, wyedytuj/etc/security/limits.conf i dodaj
    miękki nofile 16535
    przez Hard nofile 16535
    lub z konsoli spróbuj
    ulimit-n 16535
    z szacunkiem
    2021-03-02 0 0
    Udostępnij to
    Anonimowy użytkownik

    Anonimowy użytkownik

    Potwierdzenie od:

    Więc po dokładniejszych poszukiwaniach ... wygląda na to, że mój serwer nasłuchujący ma kolejkę o głębokości 20. Myślę, że to jest powód. Czy któryś z was też myśli, że to jest problem?
    z szacunkiem
    2021-03-02 0 0
    Udostępnij to
    Dlaczego jest złożony? 0 odpowiedzi zostało zwiniętych

    Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się

    Polityka prywatności: https://zweryfikowac.pl/Polityka-prywatnosci.pdf
    Copyright © 2023, All Rights Reserved