Miłosz 2311 Zgłoś post Napisano Lipiec 20, 2014 Mam dwie maszyny Dell R320. Sprzętowo są obsadzone identycznie: E5, 16Gb ramu, sasy, 2x 4port na i350-T4. Kernel 3.14.9, moduł pf_ring, sterowniki igb od pf_ringa, Debian 7, te same wersje wszystkich innych softów. Te same ustawienia biosu, włączone HT, irq sieciówek rozłożne po corach. Na pierwszym serwerze wszystko działa prawidłowo. Odpaliłem ntopng, działa już kilka dni i zbiera dane. Na drugim serwerze jest jakiś fail, którego nie mogę zlokalizować. Po włączeniu ntopng serwer trafia szlag i kernel panic. Sprawdziłem już nawet zbieranie danych najpierw z jednej sieciówki, potem z drugiej. Efekt ten sam: http://imageshack.com/a/img540/5323/00ea27.png tylko tyle widać na ekranie. txqueuelen:5000 Ring parameters for eth9:Pre-set maximums:RX: 4096RX Mini: 0RX Jumbo: 0TX: 4096Current hardware settings:RX: 4096RX Mini: 0RX Jumbo: 0TX: 4096 modules: pf_ringoptions pf_ring transparent_mode=1 min_num_slots=65536 enable_tx_capture=1 Ma ktoś jakiś pomysł na to? Udostępnij ten post Link to postu Udostępnij na innych stronach
m0t 0 Zgłoś post Napisano Lipiec 20, 2014 (edytowany) lspci -vv standardowo juz bios(ustawienia szczegolnie apic itp) takie same ? temperatury itp wszystko w normie ? ram sprawdzony ? jesli to nie hot produkcje, to zamien dyskami i wyklucz soft napewno a da sie wyzej zeskrolowac okno ? jesli nie to zrob jakies dumpa i strzel jakiegos backa zeby zobaczyc na czym sie wydupczyl (ale skoro to samo masz na obu maszynach to pewnie sprzet) Edytowano Lipiec 20, 2014 przez m0t (zobacz historię edycji) Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Lipiec 21, 2014 Ustawienia biosu takie same na obu maszynach, wybierane z predefiniowanego profilu. Temp ok, draci nie zgłaszają żadnych problemów. Dzisiaj przetestuje ram. Właśnie dysków nie mogę zamienić, bo nie bardzo mogę wyłączyć te maszyny. Sęk w tym, że soft jest identyczny, te same wersje wszystkiego. Udostępnij ten post Link to postu Udostępnij na innych stronach
malu 460 Zgłoś post Napisano Lipiec 21, 2014 Teoretycznie nie powinno mieć to znaczenia,ale jak kompilowałeś jądro ze wsparciem dla pf_ringa to kompilowałeś ręcznie na tych 2 serwerach ręcznie czy tylko na jednym, a na drugim wrzuciłeś je tylko? Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Lipiec 21, 2014 kernel na jednym, potem instalowałem deby na drugim i tam kompilowałem moduł pf_ring Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Lipiec 21, 2014 Ram wygląda ok. Przeleciały już dwie pętle testu i cały czas jest ok. Udostępnij ten post Link to postu Udostępnij na innych stronach
theONE 526 Zgłoś post Napisano Lipiec 21, 2014 To jest pamięć rejestrowana więc już dawno by ci błąd wywaliła jakby to był problem. Jak hardware to stawiam na grzanie się sieciówki przez uszkodzony radiator. To pod obciążeniem czy tak po prostu? Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Lipiec 21, 2014 kilkadziesiąt megsów raczej obciążeniem nazwać nie można. Tylko pytanie czemu pierwszy sie nie wykłada, skoro jest praktycznie identyczny. Sprzętowego problemu nie znalazłem. Z pierwszego: 76.38 Mbps [15,353 pps]Uptime: 2 days, 21 h, Drac pokazuje temp systemową na poziomie 25 st. Udostępnij ten post Link to postu Udostępnij na innych stronach
m0t 0 Zgłoś post Napisano Lipiec 21, 2014 - sproboj moze te jajo syncnac z modulami - temp system z drac nie pokaze ci temp na wbudowanych sieciowkach - pogrzeb jakims frameworkami typu herm systap itp a noz - moze jakis reset escd / conf data? Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Lipiec 21, 2014 To są sieciówki na pci-e Udostępnij ten post Link to postu Udostępnij na innych stronach
malu 460 Zgłoś post Napisano Lipiec 21, 2014 Ten sam system, te same sieciówki, ale sprawdzałeś czy firmware sieciówek jest ten sam? Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Lipiec 21, 2014 Ten sam. Udostępnij ten post Link to postu Udostępnij na innych stronach
robson345 53 Zgłoś post Napisano Lipiec 22, 2014 Albo trzepnięta karta sieciowa albo port. Takie błędy sypią się przy problemach sprzętowych. Udostępnij ten post Link to postu Udostępnij na innych stronach
m0t 0 Zgłoś post Napisano Lipiec 22, 2014 pcie rowniez sie realokuje (nawet embedy choc problemem tu moze byc fizyczna sciezka, ale skoro dziala na pierwszym to watpie) jeszcze nie wymyslono urzadzen pracujacych w inny sposb, od portu by kernel nie spanikowal, na chwile obecna bez mozsliwosci pomiaru karty tylko podmiana tych dyskow moze ci dac odpowiedz Udostępnij ten post Link to postu Udostępnij na innych stronach
mcbarlo 61 Zgłoś post Napisano Lipiec 22, 2014 Jeśli sieciówki są na pci-e to możnaby je zamenić w celu wykluczenia, ale to też niestety downtime. Czy parametry kernela w boot loaderze masz takie same? Pewnie to sprawdziłeś, ale czasem na rzeczy oczywiste najtrudniej wpaść. Ja z kolei walcze z ACPI w routerze BGP i jeśli tylko jest włączone to raz na dzień bądź raz na dwa dni rozłącza mi niektóre sesje BGP i rośnie load. Zupełnie losowo... Pomogło trochę wyłaczenie c-state w biosie, ale nadal to nie to. Kombinowałem na wszelkie możliwe sposoby i nadal kicha. Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Lipiec 25, 2014 Zaorałem tą maszyne i postawiłem na niej Centos 7. Zainstalowałem co trzeba, uruchomiłem ntopa. Już działa ponad 12h. Na debianie wywalało się już nawet po 15 minutach. Udostępnij ten post Link to postu Udostępnij na innych stronach
marekxbx 71 Zgłoś post Napisano Lipiec 25, 2014 idhosting.pl - Nie wszystkie cpu działają stabilnie z c-state przy niektórych os, wirtualizacjach (dokłądnie spradź cpu revision) orazy czy dany cpu obsługuje, inaczej tak opcja nie powinna być do zmiany w biosie. Miłosz - kiedyś miałem podobną sytuację wadliwa okzałą się karat sieciowa, po restarcie zasilania wracała do prawidłowej pracy. Udostępnij ten post Link to postu Udostępnij na innych stronach
mcbarlo 61 Zgłoś post Napisano Lipiec 25, 2014 Tam mam właśnie tylko i3 i nie wydaje mi się to najlepszym procesorem dla routera, ale z drugiej strony wydajnościowo daje spokojnie rade i jeszcze nosie podłubie. Jeśli miałbym gwarancję, że na e3 nie będzie problemu to już bym go dawno zmienił, ale któż takiej mi udzieli? Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Lipiec 25, 2014 Marek, sęk w tym, że wywalało się na obu kartach sieciowych. Czy brałem interfejs z sieciówki nr 1 czy nr 2 to efekt taki sam. Obecnie ntop działa już 22h bez problemów. Udostępnij ten post Link to postu Udostępnij na innych stronach
Gość Kamikadze Zgłoś post Napisano Lipiec 25, 2014 Jak by to był Windows to bym powiedział że sterowniki skopane i wzięte z torrentów 2 Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Lipiec 26, 2014 Emil, ale to nie jest windows Wnieś chociaż jakąś konstruktywną uwagę. Udostępnij ten post Link to postu Udostępnij na innych stronach
marekxbx 71 Zgłoś post Napisano Lipiec 28, 2014 Miłosz sieciówki są w raiser card, czy obsadzone są w te same porty ja w serwerze normalnie pracującym? Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Lipiec 28, 2014 Są w pionowych raiserach, tak samo zapakowane jak w działającej maszynie. Co dziwniejsze... Zaorałem ten niepoprawnie działający serwer. Wrzuciłem tam Centos 7. Ntop działał przez 24h bez problemu.... Coraz większe WTF Udostępnij ten post Link to postu Udostępnij na innych stronach
marekxbx 71 Zgłoś post Napisano Lipiec 28, 2014 Z nudów czasem ludziom odbija może serwer też to przeżył Możliwe, że podczas instalacji coś poszło nie tak, jeżeli tak było to wracając do poprzedniej wersji powinno działać. Udostępnij ten post Link to postu Udostępnij na innych stronach
Miłosz 2311 Zgłoś post Napisano Lipiec 28, 2014 To już raczej z desperacji Na centku przypadłość jest taka, że jak tylko pojawia się ruch na sieci, to proces NetworkManagera żre 100% 1 cora. A bez niego nie mogę za cholere podnieść interfejsów z vlanami. Udostępnij ten post Link to postu Udostępnij na innych stronach