Do czego służy polecenie synchronizacji?

Wiem, co robi ... Chyba jestem ciekawy, dlaczego rozwiązuje problem w odziedziczonej przeze mnie aplikacji. Przejęłam dość dużą aplikację tomcat, która działa jako serwer Red5 dla wielu klientów Flex i obsługuje wiele danych interakcji w czasie rzeczywistym, które ostatecznie są wyrzucane do interfejsu Railsowego. Problem z czasem był obciążony, a reakcje na tych klientów rosły do ​​3-400 ms, gdzie zwykle <100 ms. Klient podejrzewał, że to problem z pamięcią, którego tak naprawdę nigdy nie byliśmy w stanie potwierdzić. Pewnego dnia serwer pomostowy, na którym przeprowadzałem test obciążenia, zasadniczo przestał przyjmować żądania lub działał bardzo wolno. Na kaprys wysłałem

sync && echo 3 > /proc/sys/vm/drop_caches

i magicznie serwer wrócił do życia i zaczął działać na pełnych obrotach, obsługując te połączenia. Czy to był przypadek, czy to zachowanie ma sens i dlaczego?

Każdy dysk twardy jest o rząd wielkości wolniejszy niż pamięć RAM, więc Linux używa dowolnej wolnej pamięci RAM, którą możesz swobodnie przemieszczać, aby buforować dane systemu plików. Jednak tak naprawdę nigdy nie powinno to powodować problemów z wydajnością, chyba że coś jest nie tak z twoim dyskiem twardym lub usługi na twoim serwerze próbują zapisywać dane z tak dużą szybkością tak długo, aż serwer nie będzie w stanie buforować lub odzyskać danych. Może to również oznaczać, że Twój dysk twardy zbliża się do końca swojej żywotności.

W każdym razie:

• uruchomione man syncpowie ci, co robi synchronizacja [opróżnia bufory FS]
• przeglądanie „linux drop_caches” powie ci, że echo liczby 3 zwalnia wszystkie niepotrzebne strony pamięci z pamięci podręcznej [nie powinno to być konieczne w zdrowym systemie]
• command1 && command2 dzieli się na „jeśli polecenie 1 zakończy się pomyślnie, a następnie uruchom polecenie 2”
  • partnerem tego jest command1 || command2aka „jeśli polecenie 1 nie powiedzie się, uruchom polecenie 2”

Polecenie, które otrzymałeś, jest co najwyżej tymczasową poprawką i jest objawem czegoś innego, co jest nie tak z twoim systemem. Albo twoje dyski są u kresu żywotności, albo twój system jest zbyt słabo przygotowany do tego, co z nim robisz, albo jedno i drugie .

AWS nie jest dla osób o słabych nerwach i właśnie spotkałeś jeden z powodów, dla których to zrobiłeś. Słaba sytuacja wejścia / wyjścia dysku w AWS jest dobrze znana i jest jednym z głównych czynników, które należy wziąć pod uwagę dla każdego, kto tworzy aplikację na nim. Istnieją zoptymalizowane dyski wystąpienia i kilka innych sztuczek (takich jak budowanie RAID 0 z woluminów EBS), które możesz spróbować poprawić. Upewnij się, że używasz większych instancji (co najmniej m1.large), aby jądro mogło buforować dyskowe operacje we / wy.