Запустил под юзером — в итоге пришибло через минуту все процессы юзера (OOM-Killer постарался) остался один только только эксплоитовый. Причем через какое-то время он просто сожрал 1 ядро и система лишь чуть чуть потеряла в отклике и ничего страшного не случилось. Жопа только то, что убить сей процесс у меня не получилось =)
Решил уж совсем добить сервер и запустил ещё один эксплоит, но уже от рута =). Забавно, что на этот раз OOM-Killer первым делом прибил запущенный эксплоит от юзера =)))))))))). Клин клином…
Рутовый же не заставил OOM-Killer убить ни один процесс и просто сожрал 1 ядро. Убить его руками тоже не получилось.
Все это время мог попасть по ssh на машину (даже пробовал перезапускать ssh при запущенном эксплоите — ноу проблем). Перезагрузился стандартными средставми, дольше все отмаунтился root /, но в целом перезагрулся за минуту-полторы, не больше.
Так что — «не подвержен» вероятно будет разумным вердиктом) Жаль только что процесс не убить.
Это коллизия любых двух разных наборов данных с одинаковым хешем стремится к нулю. А чтобы два торрента (со своей внутренней структурой) оказались с одним хешем — это оно не просто стремится, а стремглав устремляется к нулю)
Для меня исходники куда более понятны, чем непрозрачные размышления непонятно кого (я про Windows Internals). При этом недостатка информации по работе с памятью ядра линуха я вообще не ощущал никогда.
ну погодите. Если не говорить о ситуации когда своп используется как расширение памяти которой _не_ хватает, то ни о каком изменении времени отклика приложений при своппинге и быть не может. Ситуацию когда памяти не хватает я вообще не рассматривал — тут все относительно просто: тормозить будет в любом случае =)
когда же памяти в целом хватает для рантаймовых данных всех приложений — для чего можно ещё заюзать память? Кеш файловый, кеш файловых систем, кеш «ещё какой-нибудь». При этом непонятно что важнее — закешить вооооот этот воот файлик или оставить в памяти кусок оперы открытой неделю назад. Для рабочих станций важнее явно будет кешить как можно больше скидывая оперу в своп и наплевав на то что обращение к ней потом будет достаточно дорогим — зато данные которые нужны здесь и сейчас будут в кеше. Для ноутбука важнее будет довольствоваться тем что есть, стараясь не дергать винт вообще. А для рядового убунту-юзера вероятно вообще надо будет выбрать нечто среднее, не вдаваясь в крайности.
Вот никто лучше меня самого и никакой великий аналитический алгоритм не угадает что у меня за машина и зачем она мне нужна и какой софт я собираюсь запустить через пять минут.
ещё раз. Винты бывают слабыми, бывают шустрыми, бывают сервера настолько шустрые, что вообще любые механические винты (и SCSI и SAS) будут для них относительно «слабыми». Но винты используются не только же для свопа, блин. И возня со свопом для слабых винтов может уменьшить отклик для всех остальных операций.
в линухе можно хоть чуть чуть влиять на процесс. Не хотите — не влияйте, в чем проблема-то? Я от swappiness ощущаю больше пользы, чем зла.
да и вообще, админы при тонкой настройке серверов зачастую вообще ядро патчат =). А для десктопа — вон, тот же deluge вообще запрещает сваппинг своей памяти. И правильно делает.
windows убить сжиранием памяти ничуть не сложнее.
тем не менее, в линухе неоднократно лицезрел «app XXX killed because out of swap space», что восстанавливает работоспособность системы без ребута.
swappiness не управляет «скидывать в своп или не скидывать в своп». Он управляет коэффициентом «лучше скинуть» или «лучше не скинуть».
Так, swappiness = 100 вовсе не означает что в своп будет скидываться все подряд. Равно как и swappiness = 0 не говорит о том что своп не будет использоваться вообще.
можно размышлять об этом примерно так:
при swappiness = 100 в своп будет скидываться то, что не запрашивалось 5 минут
при swappiness = 60 в своп будет скидываться то, что не запрашивалось 1 час
при swappiness = 0 в своп будет скидываться то, что не запрашивалось 24 часа.
Это лишь коэффициент и не более того. Помимо swappiness работа с памятью и свопом нифига не простая штука и в ядре линукса — там тоже много интеллектуальных вещей.
Суть swapiness в том чтобы сказать ядру «чувак, сохраняй поменьше в своп — у меня IO жутко медленный» (0 < swapiness < 60) и, наоборот, «сохраняй побольше, у меня IO шустрое» (60 < swappiness < 100).
нет ну я понимаю писать скрипты например для автоматической перекодировки *.flac -> (bchunk -> tracks*.flac с сохранением всех тегов из cue. Это действительно полезная штука. А вот так вот извращаться с простым и мощным mplayer… уффффф.
smplayer напроч заставил меня даже не думать о подобном. Реально крутанская обёртка.
дык а чего факты-то.
вон например www.pps.jussieu.fr/~kerneis/software/files/libev-vs-libevent/dat.t1.png.
давно ясно что libevent2 быстрее чем libevent1 и сравним с libev. Но libevent2 до сих пор в альфа-стадии и там много касяков (течёт по памяти => not production ready).
Запустил под юзером — в итоге пришибло через минуту все процессы юзера (OOM-Killer постарался) остался один только только эксплоитовый. Причем через какое-то время он просто сожрал 1 ядро и система лишь чуть чуть потеряла в отклике и ничего страшного не случилось. Жопа только то, что убить сей процесс у меня не получилось =)
Решил уж совсем добить сервер и запустил ещё один эксплоит, но уже от рута =). Забавно, что на этот раз OOM-Killer первым делом прибил запущенный эксплоит от юзера =)))))))))). Клин клином…
Рутовый же не заставил OOM-Killer убить ни один процесс и просто сожрал 1 ядро. Убить его руками тоже не получилось.
Все это время мог попасть по ssh на машину (даже пробовал перезапускать ssh при запущенном эксплоите — ноу проблем). Перезагрузился стандартными средставми, дольше все отмаунтился root /, но в целом перезагрулся за минуту-полторы, не больше.
Так что — «не подвержен» вероятно будет разумным вердиктом) Жаль только что процесс не убить.
Слона надо есть частями. Тут проблемы нет.
Для меня исходники куда более понятны, чем непрозрачные размышления непонятно кого (я про Windows Internals). При этом недостатка информации по работе с памятью ядра линуха я вообще не ощущал никогда.
когда же памяти в целом хватает для рантаймовых данных всех приложений — для чего можно ещё заюзать память? Кеш файловый, кеш файловых систем, кеш «ещё какой-нибудь». При этом непонятно что важнее — закешить вооооот этот воот файлик или оставить в памяти кусок оперы открытой неделю назад. Для рабочих станций важнее явно будет кешить как можно больше скидывая оперу в своп и наплевав на то что обращение к ней потом будет достаточно дорогим — зато данные которые нужны здесь и сейчас будут в кеше. Для ноутбука важнее будет довольствоваться тем что есть, стараясь не дергать винт вообще. А для рядового убунту-юзера вероятно вообще надо будет выбрать нечто среднее, не вдаваясь в крайности.
Вот никто лучше меня самого и никакой великий аналитический алгоритм не угадает что у меня за машина и зачем она мне нужна и какой софт я собираюсь запустить через пять минут.
в линухе можно хоть чуть чуть влиять на процесс. Не хотите — не влияйте, в чем проблема-то? Я от swappiness ощущаю больше пользы, чем зла.
да и вообще, админы при тонкой настройке серверов зачастую вообще ядро патчат =). А для десктопа — вон, тот же deluge вообще запрещает сваппинг своей памяти. И правильно делает.
тем не менее, в линухе неоднократно лицезрел «app XXX killed because out of swap space», что восстанавливает работоспособность системы без ребута.
весьма бессмысленный коммент получился у вас)
Так, swappiness = 100 вовсе не означает что в своп будет скидываться все подряд. Равно как и swappiness = 0 не говорит о том что своп не будет использоваться вообще.
можно размышлять об этом примерно так:
при swappiness = 100 в своп будет скидываться то, что не запрашивалось 5 минут
при swappiness = 60 в своп будет скидываться то, что не запрашивалось 1 час
при swappiness = 0 в своп будет скидываться то, что не запрашивалось 24 часа.
Это лишь коэффициент и не более того. Помимо swappiness работа с памятью и свопом нифига не простая штука и в ядре линукса — там тоже много интеллектуальных вещей.
smplayer напроч заставил меня даже не думать о подобном. Реально крутанская обёртка.
вон например www.pps.jussieu.fr/~kerneis/software/files/libev-vs-libevent/dat.t1.png.
давно ясно что libevent2 быстрее чем libevent1 и сравним с libev. Но libevent2 до сих пор в альфа-стадии и там много касяков (течёт по памяти => not production ready).