Комментарии 47
Я думаю, это скорее косяк утилиты ionice, что дисковый приоритет выставляется только для одного процесса, но не его тредов. Если запускать программу с ionice изначально, приоритет, я думаю, все же должен наследоваться
Индикатор load при старте системы стал подниматься выше 11, а процессорная нагрузка стала состоять по большей части из wait.
Это говорит о том, что планировщик deadline работал оптимальнее. wait в нагрузке процессора означает, что текущая выполняемая задача ожидает завершения I/O операций. И пока операция не завершится, другие задачи тоже вынуждены ждать, о чём и говорит рост очереди (параметр load).
Как можно предположить, при использовании Deadline приоритет отдаётся задачам (процессам), не так активно использующим ввод-вывод, они быстрее отрабатывают, и очередь не растёт. Выходит, что при переключении на CFQ произошла деградация, и разумнее вернуться на Deadline.
Но деградация была в промежуточный момент, когда ionice не выставляла правильный приоритет потокам Dropbox'а. Сейчас, скорее всего, всё намного лучше, да, Highstaker?
Да, стало намного лучше.
Видимо, deadline неправильно выставлял приоритеты процессам, и потоки dropbox в результате съедали много, просто за счёт их количества.
Пришлось через ionice вручную сообщить системе, что все потоки dropbox должны иметь низкий приоритет. И всё полетело какв попу ужаленное ракета 8)
Видимо, deadline неправильно выставлял приоритеты процессам, и потоки dropbox в результате съедали много, просто за счёт их количества.
Пришлось через ionice вручную сообщить системе, что все потоки dropbox должны иметь низкий приоритет. И всё полетело как
Во многих современных дистрибутивах используется новая система инициализации — systemd. Можно красиво и технично решить вашу задачу. Для Dropbox сделать стартовый юнит, что не сложно и указать там BlockIOReadBandwith
Хорошие примеры
http://0pointer.de/blog/projects/resources.html
Хорошие примеры
http://0pointer.de/blog/projects/resources.html
В 14.04 и до 15.04 использовалась SysV init, в 15.04 можно было переключиться и использовать systemd, а в 15.10 уже systemd по умолчанию, как и во многих современных дистрибутивах (хотя немало споров вокруг этого идёт).
В 14.04 используется upstart, совместимый с SysV init, SystemD выпилен, есть systemd-shim, но самого systemd нету — демонами управлять он не может и поставить нормальный systemd не представляется возможным.
Да и насколько я знаю, Dropbox запускается не системой, а DE, то есть запускается не какой-нибудь /etc/init.d/dropbox, а Dropbox.desktop, так что это обсуждение — бессмысленно.
Несколько советов вам по оптимизации этого хозяйства.
Для начала попроще собираем пиды тредов dropbox:
$(ps -LC dropbox -o tid=)
Потом обращаем внимание, что ваше решение приводит к запуску 50 процессов каждые 5 секунд. Это условно ~5% загрузки процессора. Не жалко вам на это тратить ресурсы? ionice может за раз выставить io класс нескольким пидам:
ionice -c3 --pid $(ps -LC dropbox -o tid=)
Так сокращаем количество порождаемых каждые 5 секунд процессов с N тредов dropbox (у меня 51) +2 до 3
Но вообще постоянно висящий фоном скрипт с циклом тоже излишен. Достаточно заменить автозапуск dropbox на автозапуск
ionice -c3 dropbox
io класс процесса наследуется при порождении новых процессов/тредов (как и переменные окружения и практически все свойства процесса). Так что все треды, которые наклепает dropbox, тоже будут с классом idle.
Для начала попроще собираем пиды тредов dropbox:
$(ps -LC dropbox -o tid=)
Потом обращаем внимание, что ваше решение приводит к запуску 50 процессов каждые 5 секунд. Это условно ~5% загрузки процессора. Не жалко вам на это тратить ресурсы? ionice может за раз выставить io класс нескольким пидам:
ionice -c3 --pid $(ps -LC dropbox -o tid=)
Так сокращаем количество порождаемых каждые 5 секунд процессов с N тредов dropbox (у меня 51) +2 до 3
Но вообще постоянно висящий фоном скрипт с циклом тоже излишен. Достаточно заменить автозапуск dropbox на автозапуск
ionice -c3 dropbox
io класс процесса наследуется при порождении новых процессов/тредов (как и переменные окружения и практически все свойства процесса). Так что все треды, которые наклепает dropbox, тоже будут с классом idle.
Возможно чего-то не понял, но не проще ли было изначально запускать дропбокс через ionice?
ionice -c3 dropbox
ionice -c3 dropbox
Пусть лучше pfactum нам расскажет про wb-buf-throttle
А есть ли что-то подобное для Windows?
Dropbox на пару с GoogleDrive на старте занимают лаптоп на добрых 10 минут.
Dropbox на пару с GoogleDrive на старте занимают лаптоп на добрых 10 минут.
конкнретно приоритеты занижаются так:
Скрытый текст
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\syncthing.exe] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\syncthing.exe\PerfOptions] "IoPriority"=dword:00000000 "PagePriority"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\syncthing.exe] [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\syncthing.exe\PerfOptions] "IoPriority"=dword:00000000 "PagePriority"=dword:00000001
В какой версии?
Спасибо, попробую.
Это получается настройки берутся по названию exe-шки?
А как быть если разные файлы с одним названием? Какие-нибудь launcher.exe для различных софтов, или вообще java.exe. Просто любопытно.
Это получается настройки берутся по названию exe-шки?
А как быть если разные файлы с одним названием? Какие-нибудь launcher.exe для различных софтов, или вообще java.exe. Просто любопытно.
В
...\Image File Execution Options\<filename>.exe\ можно создать значение "UseFilter"=dword:00000001 и произвольное количество подключей с произвольными именами, внутри подключей — значение "FilterFullPath"="C:\<полный путь к filename>.exe", тогда настройки будут браться из подключа с FilterFullPath, совпавшим с полным путём (если такого не нашлось, то, как и раньше, из самого IFEO\<filename>.exe\).
Только IoPriority лучше ставить Low, а не VeryLow ибо при последнем клиент будет вынужденно писать и читать данные маленькими порциями, а это увеличит количество вызовов системных API что плохо скажется на производительности в случае синхронизации большого объёма данных.
и для Vitaljok и MacIn
P.S. да и в целом MS рекомендует выставлять только CPUPriority, который также называется BasePriority ибо IO выставляется тоже, вот тут разъяснения https://bitsum.com//pl_io_priority.php, но ссылки на msdn не приведу.
"IoPriority"=dword:00000001
и для Vitaljok и MacIn
P.S. да и в целом MS рекомендует выставлять только CPUPriority, который также называется BasePriority ибо IO выставляется тоже, вот тут разъяснения https://bitsum.com//pl_io_priority.php, но ссылки на msdn не приведу.
P.S. ссылка
А что делать если ни в той ни в другой ветке у меня нету файла Dropbox.exe?
Выкинуть cd-rom, воткнуть второй hdd, перенести хранилище туда, блаженствовать.
На мой взгляд выносить хранилище таких вот штук на отдельный от системного физический носитель — лучшее из возможных решений. Если нет такой возможности — стартовать ручками по необходимости.
На мой взгляд выносить хранилище таких вот штук на отдельный от системного физический носитель — лучшее из возможных решений. Если нет такой возможности — стартовать ручками по необходимости.
Для периодических бэкапов с помощью rsnapshot использую стратегию Best-effort вместо Idle. Выглядит как `nice -n 19 ionice -c 2 -n 7 rsnapshot`. Почитал man ionice и так и не понял, в каких случаях лучше использовать Best-effort, а в каких Idle. Пробовал раньше использовать Idle, но производительность не устраивает в любом случае. Юниты с таймерами в systemd кажуются самым элегантным решением в сложившейся ситуации.
Не ради хейтерства, да и хочется понять, что это было и как с этим бороться:
Летом 2015 года, после скачки и установки deb с сайта dropbox'а и после запуска: инсталлятор начал скачивать сам клиента dropbox, попутно выжрав во время! скачивания свободные 7/8гб оперативки, все 4гб свопа(больше 500мб не поднимался прежде) и устроив нагрузку процессора(4ядра) за 50 и не установившись в итоге.
Следующая версия dropbox'а встала без проблем на тот же ноут с HDD и ubuntu 14.04 x64.
Вот такое у меня было первое знакомство с ним, так и не прижился он у меня.
Летом 2015 года, после скачки и установки deb с сайта dropbox'а и после запуска: инсталлятор начал скачивать сам клиента dropbox, попутно выжрав во время! скачивания свободные 7/8гб оперативки, все 4гб свопа(больше 500мб не поднимался прежде) и устроив нагрузку процессора(4ядра) за 50 и не установившись в итоге.
Следующая версия dropbox'а встала без проблем на тот же ноут с HDD и ubuntu 14.04 x64.
Вот такое у меня было первое знакомство с ним, так и не прижился он у меня.
Привет, я работаю в Dropbox (правда, в несвязанной с топиком области). Может быть, можно ключевые моменты перевести на английский, чтобы я мог передать фидбек кому надо?
Насколько я понял суть:
Dropbox, at least under Linux, creates ~50 threads, some of which end up competing for disk I/O on Dropbox client startup (i.e. during user login), which in turn, makes system unresponsive for minutes right after logging in.
This behavior was confirmed at least under Ubuntu 14.04.
Some people work around this decreasing I/O priority for Dropbox.
Отсебятина:
But the real fix should be either eliminating need for such massive I/O on startup or adding options to decrease number of threads that do I/O simultaneously or decreasing their priority.
@Highstaker, напишите, пожалуйста внизу поста всем, что в Ubuntu 14.04 systemd выпилен с потрохами, место под него залито бетоном, обнесено ключей проволокой и по периметру стоят пулеметные вышки.
Юзерские стартап задачи запускаются, обычно, десктопным окружением через .desktop файлы. Можно в ~/.local создать свой Dropbox.desktop, с ionice и запускать его. Пробовали?
Не в обиду никому, но приоритезация не ускорит I/O, а только переместит проблему в другое место, где ее будет не так сильно заметно. Почему бы не приобрести SSD (если бюджет скромный) или не замутить RAID (если деньги позволяют)?
SSD или RAID? На этом ноуте? Не вариант.
SSD в данном случае не решение проблемы, а уход от нее. Сама же проблема в плохо спроектированном софте: дропбокс не учитывает разницу между ssd/hdd, спавнит дофига потоков которые долбят диск одновременными запросами, тем самым убивая производительность hdd. Можно ведь запросто сделать только один читающий поток и кучу обрабатывающих и это вероятнее всего почти полностью решит проблему, особенно если добиться чтобы индексы в фс всегда хранились без фрагментации(не знаю возможно ли).
Да, костылизм тот ещё.
Если сделать предположение, что демон синхронизации дропбокса нагружает дисковое io синхронно с cpu (ну там же скорее всего диффы/хэши считаются в этот момент), то более красивым может быть решение с планировщиком процессов (не io планировщики, которые вы пытались крутить).
Гуглить по SCHED_BATCH — процесс с таким правилом будет получать свои тики только когда все остальные отдыхают. Предположительно, это даст именно то, что хотите — дропбокс будет работать только когда вы, условно, «отошли от комьютера».
Если сделать предположение, что демон синхронизации дропбокса нагружает дисковое io синхронно с cpu (ну там же скорее всего диффы/хэши считаются в этот момент), то более красивым может быть решение с планировщиком процессов (не io планировщики, которые вы пытались крутить).
Гуглить по SCHED_BATCH — процесс с таким правилом будет получать свои тики только когда все остальные отдыхают. Предположительно, это даст именно то, что хотите — дропбокс будет работать только когда вы, условно, «отошли от комьютера».
CPU нагружается процессом dropbox по минимуму. Бутылочное горлышко именно в I/O
Я понимаю, что проблема в io. Смысл в том, что процесс дропбокса не будет получать управление, когда работают другие процессы, а значит и обращений к диску не будет. Результат не гарантирован, но можно попробовать. Это более прямое решение.
Обычно проблема в том, что другие процессы работать не могут, т.к. сидят ждут чтения/записи диска в очереди. Именно поэтому я на ноуте с медленным диском аналогичным образом понижал приоритеты именно i/o некоторым процессам. Отзывчивость системы сильно повышается при этом.
Ну что вы мне третий раз одно и то же разными словами говорите? :) Понятно, что iowait. Но дропбокс плодит потоки и каждому нужно переназначать ionice, для чего в бесконечном цикле дёргается команда ionice. Работает, но выглядит костыльно, поэтому я предложил попробовать воркэраунд через планировщик процессов.
Для автовыставления приоритетов CPU и IO, правила можно дописывать самому, в частности для дробокса и пушить в апстрим.
https://github.com/Nefelim4ag/Ananicy
https://github.com/Nefelim4ag/Ananicy
А что мешает ограничить процессы dropbox-а с помощью cgroups?
Видимо потому что запускается от того же юзера.
Возможности cgroups не настолько ограничены, а свойство наследования группы cgroup решит проблему с запуском дочерних процессов. Relationships Between Subsystems, Hierarchies, Control Groups and Tasks.
В простейшей схеме, можно поместить запускаемый процесс в нужную группу запустив через cgexec.
В простейшей схеме, можно поместить запускаемый процесс в нужную группу запустив через cgexec.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HDD посвящается: усмиряем приложение, прожорливое на дисковое время