Что делает команда синхронизации?


15

Я знаю, что он делает ... Думаю, мне любопытно, почему он исправляет проблему в приложении, которое я унаследовал. Я взял на себя довольно большое приложение tomcat, которое выступает в качестве сервера Red5 для группы Flex-клиентов и обрабатывает множество данных о взаимодействии в реальном времени, которые в конечном итоге сбрасываются в rails 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. Затем попытайтесь выяснить, почему сервер работает медленно в случаях, когда это исправляет (максимальный ЦП? Максимальный IO? Системный пейджинг?)
David Schwartz

Ответы:


20

Любой жесткий диск на несколько порядков медленнее вашей оперативной памяти, поэтому linux использует любую свободную оперативную память, которую вы можете использовать для кэширования данных файловой системы. Однако это никогда не должно вызывать проблем с производительностью, если с вашим жестким диском либо что-то не так, либо сервисы на вашем сервере пытаются записывать данные с такой высокой скоростью, пока сервер не сможет кешировать или извлечь данные. Это также может быть признаком того, что срок службы вашего жесткого диска подходит к концу.

Так или иначе:

  • запуск man syncпокажет вам, что делает синхронизация [сбрасывает буферы FS]
  • Поиск в Linux 'linux drop_caches' скажет вам, что повторение числа 3 в нем освобождает все ненужные страницы памяти из кэша [это не должно быть необходимо в исправной системе]
  • command1 && command2 разбивается на «если команда1 завершается успешно, тогда запускаем команду2»
    • партнером для этого является command1 || command2aka 'если команда 1 завершится неудачей, тогда запустите команду 2'

Команда, которую вам дали, в лучшем случае является временным исправлением и является признаком того, что что-то не так с вашей системой. Либо у ваших дисков закончился срок службы, либо ваша система слишком слаба для того, что вы с ней делаете, или и то, и другое .


спасибо, я не уверен, я полагал, что это было очень краткосрочное решение. Я думаю, я хотел немного понять, почему это может работать. Сервер на EC2, поэтому не уверен насчет идеи HD EOL.
j_mcnally

@j_mcnally EC2? Что ж, тогда я могу только догадываться, как выглядит ваш конкретный экземпляр, но это, вероятно, комбинация таких факторов, как EBS, который всегда очень ненадежен, крошечное распределение ОЗУ и отсутствие раздела подкачки.
Sammitch

Так вы говорите, что решение может быть действительно LOL?
j_mcnally

@j_mcnally к сожалению, если вы не находитесь в одном из случаев, оптимизированных для ввода-вывода в миллион долларов в месяц, потенциально да.
Саммит

5

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


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