Sytuacja:
Następujący dziwny problem wystąpił na pojedynczym serwerze plików z systemem OmniOS r151018 (95eaa7e) obsługującym pliki przez SMB dla gości Windows i OS X.
Zapisanie niektórych plików (.docx, .xlsx, niektóre obrazy) w oknie dialogowym „Zapisz jako ...” w udziale SMB powoduje opóźnienie około 3 do 5 sekund, w którym aplikacja w ogóle nie reaguje, a następnie plik jest zapisywany normalnie.
Problem pojawił się „w nocy”, nie robiąc nic na serwerze, ale trudno jest ustalić dokładną datę, ponieważ skargi użytkowników pojawiły się dopiero po pewnym czasie. Po ponownym uruchomieniu serwera jeden wirtualny serwer lustrzanej puli głównej był niedostępny, ale dokładniejsza inspekcja nie wykryła żadnych błędów na urządzeniu i została ponownie podłączona do puli. Problem nadal występuje.
Niektóre spostrzeżenia:
- Dzieje się tak na wszystkich klientach Windows 7
- Dzieje się tak dla wszystkich rozmiarów plików
- Dzieje się tak na wszystkich udziałach tego komputera, niezależnie od uprawnień
- Dzieje się tak w celu szybszego przechowywania danych importowanych na hoście przez iSCSI z innego serwera
- Normalna prędkość kopiowania wynosi 110 MB / s przez GBit Ethernet
- Dane i pula root wydają się być w porządku
- Nie dzieje się to na innych serwerach plików
- Nie dzieje się tak, gdy plik jest zapisywany lokalnie, a następnie kopiowany przez Eksploratora
- Nie dzieje się to w systemie OS X (można to przetestować tylko za pomocą OpenOffice)
dmesg
pokazuje kilka obliczeńNOTICE: bge0: interrupt: flags 0x0 - not updated?
z różnymi wartościami, ale miało to również miejsce wcześniej i nie wyrządziło szkody
Dalsze pomysły / plany:
Ponieważ nie można znaleźć wyraźnego komunikatu o błędzie, być może będę musiał przeprowadzić próbę i wyszukiwanie błędów. Kilka rzeczy, które rozważę ( wyniki są napisane kursywą ):
- Zastąpienie karty sieciowej Broadcom kartą Intel => nie miało znaczenia
- Zastąp pulę główną dyskami SATA SSD (obecnie pamięci USB SLC, które działały dobrze przez ponad 3 lata) => nie zrobiło różnicy
- Sprawdź sieć pomiędzy (sprzęt, poprzez bezpośrednie połączenie z serwerem)
- Przechwytywanie ruchu za pomocą WireShark: trudne, jeśli nie wiesz dokładnie, czego szukasz
- Powróć do poprzedniego środowiska / wersji rozruchowej OmniOS, aby wykluczyć konflikty oprogramowania => nie miało znaczenia
- Cofnij aktualizacje Windows / Office, aby wykluczyć błędy
Usuń pliki z
:
(dwukropkiem) w nazwach plików z migawek, sugestia txgsync w wątku reddit utworzonym przez ewwhite => nie zrobiła różnicyWidziałem coś podobnego do tego, gdy funkcja „poprzednich wersji” systemu Windows jest włączona z automatycznymi migawkami zawierającymi znak „:”. Po prostu strzelasz z tym wiatrem, ale może warto spojrzeć, ponieważ znak „:” nie jest dozwolony w nazwach plików Windows.
Monitorowanie dostępu do plików: jak sugeruje shodanshok, kiedyś
DTrace
i ten skrypt do monitorowania dostępu do plików. Użyłem go podczas zapisywania już otwartego pliku, usunąłem niepowiązane dane wyjściowe i dane osobowe, a wynik koncentruje się wokół trzech plików:CPU ID FUNCTION:NAME 1 18753 fop_open:entry Open: Workbook 0 18181 fop_create:return Create: temp_1 0 18753 fop_open:entry Open: temp_1 0 18753 fop_open:entry Open: Workbook 0 18753 fop_open:entry Open: Workbook 0 18753 fop_open:entry Open: temp_1 0 18888 fop_rename:entry Rename: Workbook -> temp_2 0 18888 fop_rename:entry Rename: temp_1 -> Workbook 0 18753 fop_open:entry Open: Workbook 0 18753 fop_open:entry Open: temp_2 0 18892 fop_remove:entry Remove: temp_2 0 18753 fop_open:entry Open: Workbook 0 18753 fop_open:entry Open: Workbook
Ta sama procedura na innym serwerze, na którym problem nie występuje, daje podobny wynik:
CPU ID FUNCTION:NAME 1 25182 fop_create:return Create: temp_1 1 25750 fop_open:entry Open: temp_1 1 25750 fop_open:entry Open: Workbook 1 25750 fop_open:entry Open: temp_1 1 25750 fop_open:entry Open: Workbook 1 25750 fop_open:entry Open: temp_1 1 25889 fop_rename:entry Rename: Workbook -> temp_2 1 25889 fop_rename:entry Rename: temp_1 -> Workbook 1 25750 fop_open:entry Open: Workbook 1 25750 fop_open:entry Open: temp_2 1 25893 fop_remove:entry Remove: temp_2 1 25750 fop_open:entry Open: Workbook 1 25750 fop_open:entry Open: Workbook 1 25750 fop_open:entry Open: Workbook
Dodałem także
walltimestamp
do skryptu znaczniki czasu ( ), ale w obu przypadkach wszystkie operacje na plikach odbywają się w tej samej sekundzie. => nie zrobił różnicy- Zaimportuj dyski na innym hoście, aby sprawdzić, czy fragmentacja puli lub dyski są wadliwe => nie zrobiło różnicy
- Przenieś dane i pulę główną na identyczną maszynę, aby wykluczyć okablowanie, płytę główną itp. => Problem nadal występuje, więc musi to być pula główna (oprogramowanie) lub określony sprzęt, który jest niezgodny z oprogramowaniem (lub nagle stał się niezgodny. ..)
Czy możesz zasugerować coś innego, co może być przyczyną tego zachowania? A może doświadczyłeś czegoś podobnego? ponieważ nie mogłem znaleźć niczego pomocnego w Internecie, podejrzewam, że jest to albo dziwny problem sprzętowy (ponieważ jest ograniczony do jednego komputera), albo problem z Windows / Office.
źródło
Odpowiedzi:
Rozwiązanie:
Problem dotyczy tylko OmniOS r151018, a nie poprzednich wersji. Ten wątek na liście dyskusyjnej Omnios dotyczył dokładnie mojego problemu, cytat z Geoffa:
Tak
biteCount++;
myślę. Problem został rozwiązany przez zastosowanie poprawki i szybkie ponowne uruchomienie.Lekcje na przyszłość: przed przystąpieniem do rozwiązywania problemów wystarczy skorzystać z wyszukiwania zaawansowanego na oficjalnych listach mailowych, ponieważ najprawdopodobniej problem wystąpił już na komputerze innej osoby. Uruchom także szybką maszynę wirtualną, aby wykluczyć wszelkie błędy oprogramowania, aktualizacji lub konfiguracji, zanim zaczniesz szukać błędów sprzętowych.
Jak się tam dostałem:
Po kilku różnych testach, jak widać w zaktualizowanym pytaniu, zawęziłem go do problemów programowych lub konfliktów sprzętowych / sterowników na konkretnym sprzęcie. Aby wykluczyć drugi, zainstalowałem dwie nowe maszyny wirtualne OmniOS, r151018 i r151016 na innym hoście i ręcznie skonfigurowałem podstawowy udział SMB na każdym z nich.
R151018 napotkał problem, r151016 działa dobrze. Podejrzewam, że nie zauważyłem tego podczas moich pierwszych testów, ponieważ przywróciłem tylko niektóre aktualizacje na r151018, a nie poprzedniej wersji. Myślę, że problem musiał istnieć dłużej, niż się spodziewałem.
Szukając sposobu na aktualizację pakietów tylko jeden po drugim, spojrzałem na listę mailingową i szukałem
smb
od ostatnich 6 miesięcy, gdzie pojawiło się prawidłowe rozwiązanie / ten sam problem, datowane od maja.źródło