Що робить команда синхронізації?


15

Я знаю, що це робить ... Напевно, мені цікаво, чому це виправляє проблему в додатку, який я успадкував. Я взяв на себе досить великий додаток tomcat, який виступає як сервер Red5 для безлічі флеш-клієнтів, і обробляє багато даних про взаємодію в режимі реального часу, які в кінцевому підсумку видаються на api-рейку. Проблема виснажувалась із великим навантаженням, з часом відповіді цих клієнтів зростали до 3-400 мс, там, де зазвичай <100 мс. Клієнт підозрював, що це питання пам'яті, яке ми насправді ніколи не могли підтвердити. Одного разу сервер постановки я проводив тест навантаження, в основному перестав приймати запити або був дуже повільним. На примху я послав

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

і чарівно сервер повернувся до життя і почав працювати на повній швидкості, обслуговуючи це з'єднання. Це був збіг чи ця поведінка має сенс і чому?


4
Це дві команди. Який із них мав ефект, який ви помітили?
Майкл Хемптон

linuxtidbits.wordpress.com/2008/02/20/purge-memory запропонував запустити їх разом, тому я не знаю.
j_mcnally

це додатково перероблено тут: commandlinefu.com/commands/view/1026 / ...
j_mcnally

4
Важко сказати. Ви не очікували, що ці команди можуть зробити щось корисне на сервері, якщо б це не було жахливо заглушене. Але це, безумовно, не виключається без більш ретельного вивчення. Якщо це повториться, спробуйте просто syncабо просто echo. Потім спробуйте з’ясувати, чому сервер повільний у випадках, які це виправляє (чи CPU максований? Чи мається IO? Чи є пейджинг системи?)
Девід Шварц

Відповіді:


20

Будь-який жорсткий диск на порядок менший, ніж ваша ОЗУ, тому Linux використовує будь-яку запасну оперативну пам’ять, яка, можливо, плаває навколо вас, щоб кешувати дані файлової системи. Однак це насправді ніколи не повинно спричиняти проблем з продуктивністю, якщо на вашому жорсткому диску щось не так, або служби на вашому сервері намагаються записувати дані з такою високою швидкістю настільки довго, поки сервер не зможе кешувати або отримувати дані. Це також може бути ознакою того, що ваш жорсткий диск закінчується термін служби.

У будь-якому випадку:

  • біг man syncпідкаже вам, що синхронізація [промиває FS буфери]
  • googling 'linux drop_caches' скаже вам, що повторення числа 3 в ньому вивільняє всі непотрібні сторінки пам'яті з кешу [це не повинно бути необхідним для здорової системи]
  • command1 && command2 розбивається на "якщо команда1 закінчується успішно, тоді запустіть команду2"
    • партнер для цього є command1 || command2aka "якщо command1 не вдається, то запустіть command2"

Команда, яку вам дали, є в кращому випадку тимчасовим виправленням і є симптоматикою чогось іншого, що не так у вашій системі. Або ваші диски вже закінчуються, або ваша система занадто недостатня для того, що ви робите з цим, або обох .


дякую, я не впевнений, я вважав, що це дуже короткострокове рішення. Я думаю, я хотів трохи зрозуміти, чому це може працювати. Сервер знаходиться на EC2, тому не впевнений у ідеї HD EOL.
j_mcnally

@j_mcnally EC2? Тоді я можу лише здогадуватися, як виглядає ваш конкретний екземпляр, але це, мабуть, комбінація факторів, таких як EBS, який завжди надзвичайно лускатий, крихітні розподіли оперативної пам’яті та відсутність розділу swap.
Саммітч

Так ви кажете, що рішення може бути дійсно дійсним лол?
j_mcnally

@j_mcnally сумно, якщо ви не перебуваєте в одному з оптимізованих випадків IO на мільйон доларів на місяць, можливо, так.
Саммітч

5

AWS не для слабкодухих, і ви просто зіткнулися з однією з причин того. Погана ситуація вводу / виводу диска на AWS є загальновідомою, і один з головних факторів, який слід враховувати для всіх, хто будує додаток на цьому. Існують оптимізовані для дисків екземпляри та кілька інших хитрощів (наприклад, створення RAID 0 з томів EBS), за допомогою яких ви можете спробувати покращити питання. Переконайтеся, що використовуйте більші екземпляри (принаймні m1.large), щоб гарантувати, що ядро ​​може буферувати дискові введення-виведення.


так, використовуючи m1.large. Ці сервери запускаються для додатка, а потім згортаються годинами пізніше ... тому не впевнені в інвестиціях часу тощо для диска io. Я вдячний всім вкладам та пропозиціям виглядають так, що виправлення може спричинити дійсність, навіть якщо це не бажано. знову дякую.
j_mcnally
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.