Форум русскоязычного сообщества Ubuntu


Увидели сообщение с непонятной ссылкой, спам, непристойность или оскорбление?
Воспользуйтесь ссылкой «Сообщить модератору» рядом с сообщением!

Автор Тема: Процессы "В ожидании на диске"  (Прочитано 6850 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн MooSE

  • Старожил
  • *
  • Сообщений: 1194
    • Просмотр профиля
Re: Процессы "В ожидании на диске"
« Ответ #15 : 29 Апреля 2014, 15:27:40 »
Но должна же быть какая-то опция, чтобы регулировать остающееся кол-во свободной памяти, момент, когда пора системе беспокоится о том, чтобы дропнуть кэш?

ну дык кэш и дропается. собственно отсюда и проблема: большое количество мелких обращений к диску вдруг перестаёт кэшироваться. и если с учётом кэширования они маленькие и быстрые, то при работе непосредственно с диском они маленькие и медленные, а если учесть их количество - всё встаёт колом.

т.е. проблема не в наличии дискового кэша, а наоборот: в практически полном его отсутствии.

Оффлайн Hi

  • Автор темы
  • Любитель
  • *
  • Сообщений: 92
    • Просмотр профиля
Re: Процессы "В ожидании на диске"
« Ответ #16 : 29 Апреля 2014, 19:31:50 »
Но должна же быть какая-то опция, чтобы регулировать остающееся кол-во свободной памяти, момент, когда пора системе беспокоится о том, чтобы дропнуть кэш?

ну дык кэш и дропается. собственно отсюда и проблема: большое количество мелких обращений к диску вдруг перестаёт кэшироваться. и если с учётом кэширования они маленькие и быстрые, то при работе непосредственно с диском они маленькие и медленные, а если учесть их количество - всё встаёт колом.

т.е. проблема не в наличии дискового кэша, а наоборот: в практически полном его отсутствии.

Да нет же, все наоборот: если бы дропался кэш... Честно сказать, я собирался описать, что бы тормозило, да, вот, только, практически ничего бы не тормозило. Браузеры? Они и так в RAM практически все держат. Файловый менеджер? Ну пришлось бы мне посмотреть пару секунд на пустую папку, пока она с диска не загрузится.
Поймите вы, если бы дропался кэш, тормозов бы практически не было, но вместо этого ядро сбрасывает на диск практически все, что можно зацепить: браузеры, плазму...

Оффлайн MooSE

  • Старожил
  • *
  • Сообщений: 1194
    • Просмотр профиля
Re: Процессы "В ожидании на диске"
« Ответ #17 : 30 Апреля 2014, 14:45:59 »
Да нет же, все наоборот: если бы дропался кэш... Честно сказать, я собирался описать, что бы тормозило, да, вот, только, практически ничего бы не тормозило. Браузеры? Они и так в RAM практически все держат. Файловый менеджер? Ну пришлось бы мне посмотреть пару секунд на пустую папку, пока она с диска не загрузится.
Поймите вы, если бы дропался кэш, тормозов бы практически не было, но вместо этого ядро сбрасывает на диск практически все, что можно зацепить: браузеры, плазму...

Вы меня не слушаете. Или слушаете, но не хотите понимать. Или не очень понимаете что же такое "дисковый кэш". В этом кэше действительно всё: и браузеры, и плазма. Всё что считывается с диска система сохраняет в дисковом кэше в RAM. При записи на диск реально модифицируются данные в RAM. Из RAM данные периодически сбрасываются на диск. Управлять этим можно с помощью ряда переменных sysctl, в частности vm.dirty_ratio, vm.dirty_background_ratio, vm.vfs_cache_pressure.

Вобщем просто докиньте RAM и будет вам счастье.

Оффлайн Ampermetr

  • Активист
  • *
  • Сообщений: 491
    • Просмотр профиля
Re: Процессы "В ожидании на диске"
« Ответ #18 : 30 Апреля 2014, 22:32:16 »
У меня подобное постоянно происходит на дебиане с smplayer`ом (после закрытия плеера остается процесс, расходует около 20 мб памяти) и некоторыми другими приложениями, но тормозов нет, даже не смотря на то, что процессов в ожидании скапливается штук по 50 и судя по системному монитору используется именно оперативная память, а не swap.
Женский форум,топик "Плакала всю ночь, подскажите из-за чего?"
Линукс форум, топик "Всю ночь собирал генту, подскажите зачем?"

Оффлайн Hi

  • Автор темы
  • Любитель
  • *
  • Сообщений: 92
    • Просмотр профиля
Re: Процессы \"В ожидании на диске\"
« Ответ #19 : 01 Мая 2014, 08:18:57 »
Да нет же, все наоборот: если бы дропался кэш... Честно сказать, я собирался описать, что бы тормозило, да, вот, только, практически ничего бы не тормозило. Браузеры? Они и так в RAM практически все держат. Файловый менеджер? Ну пришлось бы мне посмотреть пару секунд на пустую папку, пока она с диска не загрузится.
Поймите вы, если бы дропался кэш, тормозов бы практически не было, но вместо этого ядро сбрасывает на диск практически все, что можно зацепить: браузеры, плазму...

Вы меня не слушаете. Или слушаете, но не хотите понимать. Или не очень понимаете что же такое "дисковый кэш". В этом кэше действительно всё: и браузеры, и плазма. Всё что считывается с диска система сохраняет в дисковом кэше в RAM. При записи на диск реально модифицируются данные в RAM. Из RAM данные периодически сбрасываются на диск. Управлять этим можно с помощью ряда переменных sysctl, в частности vm.dirty_ratio, vm.dirty_background_ratio, vm.vfs_cache_pressure.

Вобщем просто докиньте RAM и будет вам счастье.

Ладно, если вы так уверены в этом, давайте обратимся к википедии:
Цитировать
промежуточный буфер с быстрым доступом, содержащий информацию, которая может быть запрошена с наибольшей вероятностью.
Давайте я вам теперь объясню, что относится к кэшу: например вы включили в плеере музыку. Если в системе достаточно свободной RAM, при каждом очередном обращении к файлу на диске, система просто его не выгружает из памяти, на случай, если он понадобится кому-то еще -- чтобы, не пришлось заново обращаться к диску, и считывать его оттуда, что достаточно медленная операция. Так же, к примеру, с файловым менеджером -- он не считывает заново данные с диска, а просто их "запоминает".
Теперь давайте обсудим, что НЕ является кэшом. Не является кэшом загруженные в память библиотеки, равно, как и программы. Принцип прост: все, что не было загружено в память непосредственно системой -- неприкосновенно, т.к. система не может знать, для чего оно лежит. Единственное, что она может сделать с этими данными, это скинуть их на диск(в swap, при наличии такового) при отсутствии свободной памяти, дабы приложения не начали помирать из-за невозможности выделения памяти.
Тут мы с вами подходим к сути нашей дискуссии: когда не хватает свободной памяти, первым делом система должна сбрасывать накопленный ей кэш. То, что она не загружала самовольно, не является для нее кэшем. Вернее, в принципе, эти данные тоже могут быть кэшем других приложений: к примеру тот же плеер однозначно сразу загрузит песню в память, вместо того, чтобы читать ее по байту с диска во время проигрывания. Но это не системный кэш, проще говоря система не знает, что это кэш. Для нее это просто данные, относящиеся к приложению, с совершенно неизвестным содержимым.

И на моем ноутбуке три Ггб, сколько ж надо для счастья докинуть то :D

Пользователь решил продолжить мысль 01 Мая 2014, 08:37:48:
Цитата: MooSE
Управлять этим можно с помощью ряда переменных sysctl, в частности vm.dirty_ratio, vm.dirty_background_ratio, vm.vfs_cache_pressure.
Спасибо большое, похоже это то, что нужно. Думаю, тема решена; подытоживая: параметр vfs_cache_pressure отвечает за кэширование дисковых операций. Текущее значение можно посмотреть через cat, в процентах:
$ cat /proc/sys/vm/vfs_cache_pressure
100
100 -- это мое старое значение, означает агррессивное кэширование дисковых операций. Видимо в этом проблема и была. Вводим:
$sudo sysctl -w vm.vfs_cache_pressure=80
vm.vfs_cache_pressure = 80
чтобы изменить дисковый кэш на 80% вместо ста.
« Последнее редактирование: 01 Мая 2014, 08:37:48 от Hi »

Оффлайн MooSE

  • Старожил
  • *
  • Сообщений: 1194
    • Просмотр профиля
Re: Процессы "В ожидании на диске"
« Ответ #20 : 01 Мая 2014, 15:31:49 »
Давайте я вам теперь объясню, что относится к кэшу: например вы включили в плеере музыку. Если в системе достаточно свободной RAM, при каждом очередном обращении к файлу на диске, система просто его не выгружает из памяти, на случай, если он понадобится кому-то еще -- чтобы, не пришлось заново обращаться к диску, и считывать его оттуда, что достаточно медленная операция. Так же, к примеру, с файловым менеджером -- он не считывает заново данные с диска, а просто их "запоминает".
Теперь давайте обсудим, что НЕ является кэшом. Не является кэшом загруженные в память библиотеки, равно, как и программы. Принцип прост: все, что не было загружено в память непосредственно системой -- неприкосновенно, т.к. система не может знать, для чего оно лежит. Единственное, что она может сделать с этими данными, это скинуть их на диск(в swap, при наличии такового) при отсутствии свободной памяти, дабы приложения не начали помирать из-за невозможности выделения памяти.

Это ваши фантазии, не имеющие ничего общего с реальностью. Система не различает файлы библиотек, приложений, музыки и видео. При кэшировании в отношении них действует совершенно одинаковая политика. Другое дело что при особождении кэша убирается в первую очередь то что не нужно.

Библиотеки и приложения же не выгружаются потому что они используются. Но если вы запустили приложение а потом закрыли его - все его файлы и связанные с ним библиотеки останутся в RAM (при условии что RAM достаточно много). Это можно пронаблюдать запустив что-то тяжёлое вроде LibreOffice и GIMP: холодный старт занимает достаточно много времени, так как требуется подгрузка большого числа данных с диска. Однако если потом закрыть приложение и открыть заново - загрузка произойдёт много быстрее. Потому что она произошла из дискового кэша.

Я сейчас ради интереса запусти GIMP, закрыл его и запустил заново. Первый запуск занял 18 секунд, второй - 11.

Тут мы с вами подходим к сути нашей дискуссии: когда не хватает свободной памяти, первым делом система должна сбрасывать накопленный ей кэш. То, что она не загружала самовольно, не является для нее кэшем. Вернее, в принципе, эти данные тоже могут быть кэшем других приложений: к примеру тот же плеер однозначно сразу загрузит песню в память, вместо того, чтобы читать ее по байту с диска во время проигрывания. Но это не системный кэш, проще говоря система не знает, что это кэш. Для нее это просто данные, относящиеся к приложению, с совершенно неизвестным содержимым.

Бред сивой кобылы. Проверяется очень легко:
moose@note:~$ time cat GeoIP-106_20130702.dat > /dev/null

real    0m0.210s
user    0m0.000s
sys     0m0.004s
moose@note:~$ time cat GeoIP-106_20130702.dat > /dev/null

real    0m0.004s
user    0m0.000s
sys     0m0.000s

Т.е. повторное считывание файла прошло много быстрее, т.к. он был закэширован.

И на моем ноутбуке три Ггб, сколько ж надо для счастья докинуть то :D
Смотря какие задачи вы решаете на ноутбуке. Три гигабайта в 2014-м году очень мало. Попробуйте увеличить. У вас однозначно проблемы из-за малого объёма RAM.




Оффлайн Hi

  • Автор темы
  • Любитель
  • *
  • Сообщений: 92
    • Просмотр профиля
Re: Процессы "В ожидании на диске"
« Ответ #21 : 02 Мая 2014, 18:43:51 »
MooSE, позволю себе заметить, что приведенные вами примеры никоим образом не опровергают мои предположения. Естественно, что после ваших слов я останусь при своем мнении, т.к. на данный момент, мне кажется моя гипотеза более логичной.

Уверен, кому-то из нас надо привести пруфлинк. Я попытался найти что-то, но, в большинстве случаев описание не противоречит не вам, ни мне. Тем не менее, я нашел косвенное упоминание
Цитировать
Оперативная память тратится не только для данных, используемых прикладными приложениями. В ней также хранятся данные для самого ядра и, самое главное, в эту память могут отображаться данные, хранящиеся на жестком диске, что используется для супер-быстрого к ним доступа — команда top указывает об этом в столбцах "buffers/cache" ("буферы / кэш"), "disk cache" ("дисковый кэш)" или "cached" ("кэшировано"). Кэшированная память по сути свободна, поскольку ее можно быстро освободить в случае, если работающей (или только что запущенной) программе потребуется память.
Обратите внимание, что автор в первом предложении указывает на разницу между оперативной памятью для данных, используемых приложениями(вспоминаем мой пример с плеером), и кэшем; и в последнем предложении Кэшированная память по сути свободна, поскольку ее можно быстро освободить в случае, если работающей (или только что запущенной) программе потребуется память, здесь работающей равносильно запущенной, надеюсь, вы понимаете, что работающее приложение не престает быть таковым только из-за того, что за несколько дней работы ПК оно вообще никому не потребовалось -- к примеру какой-нибудь модуль для людей со слабым зрением, или что-нибудь типа того.
Цитата: MooSE
Смотря какие задачи вы решаете на ноутбуке. Три гигабайта в 2014-м году очень мало. Попробуйте увеличить. У вас однозначно проблемы из-за малого объёма RAM.
Три Ггб мало, когда вы занимаетесь 3D моделированием, или играетесь в тяжелые игры. Я программист, да и то пока студент, изредка играюсь в Xonotic, и такое гигантское кол-во памяти мне, как правило, иметь абсолютно незачем.
« Последнее редактирование: 02 Мая 2014, 23:26:50 от Hi »

Оффлайн MooSE

  • Старожил
  • *
  • Сообщений: 1194
    • Просмотр профиля
Re: Процессы \"В ожидании на диске\"
« Ответ #22 : 04 Мая 2014, 09:53:34 »
MooSE, позволю себе заметить, что приведенные вами примеры никоим образом не опровергают мои предположения. Естественно, что после ваших слов я останусь при своем мнении, т.к. на данный момент, мне кажется моя гипотеза более логичной.

Ваше право. Только у вас не реальное знание, а предположение.

Три Ггб мало, когда вы занимаетесь 3D моделированием, или играетесь в тяжелые игры. Я программист, да и то пока студент, изредка играюсь в Xonotic, и такое гигантское кол-во памяти мне, как правило, иметь абсолютно незачем.

Смотрите на вывод команды free у себя и делайте выводы. Но всё-таки 3GB это мало. Я даже вот это гигантским размером не считаю:
# free
             total       used       free     shared    buffers     cached
Mem:     132025392  111093668   20931724          0     225224    5968324
-/+ buffers/cache:  104900120   27125272
Swap:      3905532        100    3905432


Уверен, кому-то из нас надо привести пруфлинк. Я попытался найти что-то, но, в большинстве случаев описание не противоречит не вам, ни мне.

Ваша проблема в том что во-первых вы ищете на русском языке, во-вторых не пытаетесь рассуждать логически. Расскажите мне каким образом fopen различает для чего открывается файл: для считывания вашей mp3'шки или для считывания кода приложения?:)


Пользователь решил продолжить мысль 04 Мая 2014, 10:02:59:
Вот кстати восхитительная софтина, как раз использующая дисковый кэш для приложений: http://sourceforge.net/projects/preload/

А вот тут рассказывают как этим пользоваться: http://techthrob.com/2009/03/drastically-speed-up-your-linux-system-with-preload/

А вот статья на MSDN про "холодный" и "горячий" запуск приложений: http://msdn.microsoft.com/ru-ru/library/vstudio/cc656914(v=vs.100).aspx - многое справедливо не только для Windows, но и вообще для большинства операционных систем.



« Последнее редактирование: 04 Мая 2014, 10:02:59 от MooSE »

Оффлайн Hi

  • Автор темы
  • Любитель
  • *
  • Сообщений: 92
    • Просмотр профиля
Re: Процессы \\\"В ожидании на диске\\\"
« Ответ #23 : 05 Мая 2014, 02:18:58 »
MooSE, позволю себе заметить, что приведенные вами примеры никоим образом не опровергают мои предположения. Естественно, что после ваших слов я останусь при своем мнении, т.к. на данный момент, мне кажется моя гипотеза более логичной.

Ваше право. Только у вас не реальное знание, а предположение.
Равно, как и у вас, коль вы не удосужились привести доказательств. ;)
Уверен, кому-то из нас надо привести пруфлинк. Я попытался найти что-то, но, в большинстве случаев описание не противоречит не вам, ни мне.

Ваша проблема в том что во-первых вы ищете на русском языке, во-вторых не пытаетесь рассуждать логически. Расскажите мне каким образом fopen различает для чего открывается файл: для считывания вашей mp3'шки или для считывания кода приложения?:)
Ну конечно же, ведь все русские блоггеры глупцы, и я заплутал в дебрях их лжи.
И, конечно же я не пытаюсь рассуждать логически, я тоже глупый, ведь мои совершенно самостоятельные выводы, которые я вам при возникших сомнениях даже найденной ссылкой подтвердил, ничто иное, как шизофренический, бессвязный бред. А ваши, до сих пор ничем не подтвержденные, идеи царствуют над нашим бренным, форумным миром.
И fopen(), open(), и прочим производным, вовсе незачем различать причины открытия файла. Все элементарно: при закрытии ранее открытого файла, система его внутренним, a.k.a. невидимым для вашего приложения способом, оставляет в памяти, закрывая лишь имеющийся у вас дискриптор; т.о. ставший закрытым файл превращается в кэш. При обращении к нему снова, файл не загружается с диска, а уже находится в памяти. Точно так же, при иссякающей свободной памяти, система сначала проходится по своему кэшу, чтобы выбросить его из RAM. И, только уже потом, если кэша не осталось, она начинает кидать в swap запущенные программы.

Пользователь решил продолжить мысль 05 Мая 2014, 02:51:36:
Держите, если вам так угодно, английский источник
Цитировать
Now for a pop quiz. Imagine that the last instance of our render program exits. Would the pages storing scene.dat in the page cache be freed immediately? People often think so, but that would be a bad idea. When you think about it, it is very common for us to create a file in one program, exit, then use the file in a second program. The page cache must handle that case. When you think more about it, why should the kernel ever get rid of page cache contents? Remember that disk is 5 orders of magnitude slower than RAM, hence a page cache hit is a huge win. So long as there’s enough free physical memory, the cache should be kept full.
Обратите внимание, что он так же указывает, что данные из памяти превращаются в кэш при их закрытии. Запущенная программа не является закрытой, и не является кэшем, даже, если она вам не нужна вообще, а была запущена случайно.

Пользователь решил продолжить мысль 05 Мая 2014, 07:31:53:
Давайте я вам теперь объясню, что относится к кэшу: например вы включили в плеере музыку. Если в системе достаточно свободной RAM, при каждом очередном обращении к файлу на диске, система просто его не выгружает из памяти, на случай, если он понадобится кому-то еще -- чтобы, не пришлось заново обращаться к диску, и считывать его оттуда, что достаточно медленная операция. Так же, к примеру, с файловым менеджером -- он не считывает заново данные с диска, а просто их "запоминает".
Теперь давайте обсудим, что НЕ является кэшом. Не является кэшом загруженные в память библиотеки, равно, как и программы. Принцип прост: все, что не было загружено в память непосредственно системой -- неприкосновенно, т.к. система не может знать, для чего оно лежит. Единственное, что она может сделать с этими данными, это скинуть их на диск(в swap, при наличии такового) при отсутствии свободной памяти, дабы приложения не начали помирать из-за невозможности выделения памяти.

Это ваши фантазии, не имеющие ничего общего с реальностью. Система не различает файлы библиотек, приложений, музыки и видео. При кэшировании в отношении них действует совершенно одинаковая политика. Другое дело что при особождении кэша убирается в первую очередь то что не нужно.

Библиотеки и приложения же не выгружаются потому что они используются. Но если вы запустили приложение а потом закрыли его - все его файлы и связанные с ним библиотеки останутся в RAM (при условии что RAM достаточно много). Это можно пронаблюдать запустив что-то тяжёлое вроде LibreOffice и GIMP: холодный старт занимает достаточно много времени, так как требуется подгрузка большого числа данных с диска. Однако если потом закрыть приложение и открыть заново - загрузка произойдёт много быстрее. Потому что она произошла из дискового кэша.
Знаете, мне тут подумалось: а о чем вообще мы спорим?  ;D Я решил перечитать топик, и, мне кажется, что мы просто друг друга недопоняли. Вернее вот в этой цитате вы меня поняли неправильно, в результате я, уверенный, что вы все поняли верно, сделал превратные выводы; и пошло-поехало...
Вы же ведь не имели ввиду там, что любая работающая программа является кэшем? Вы просто хотели сказать, что закрытые программы, мир их праху, так же превращаются в кэш?
« Последнее редактирование: 05 Мая 2014, 07:33:29 от Hi »

 

Страница сгенерирована за 0.022 секунд. Запросов: 21.