The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В Fedora 32 намерены включить earlyoom для раннего реагирова..., opennews (??), 05-Янв-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


42. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  –1 +/
Сообщение от Аноним (10), 06-Янв-20, 01:29 
>и будет у вас маллок фейлиться, как в венде.

Но в виндк-то не фейлится. В тех же программах тех же версий из тех же сырцов. На системах с в разы меньшей памятью.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

45. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  +/
Сообщение от Аноним (8), 06-Янв-20, 01:40 
Наверно там 32 битный софт и ему надо на 15% меньше памяти. Конечно фейлится, именно поэтому система не зависает, а софт знает, что память получить не удалось, в связи с чем не пытается использовать её.

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

Ответить | Правка | Наверх | Cообщить модератору

48. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  +/
Сообщение от Аноним (8), 06-Янв-20, 03:04 
И кстати, я очень оценил отсутствие киллера и magic-key в той ситуации. Но зато у виндоус есть хоткей для перезапуска графического драйвера, что не совсем то, но иногда помогает при зависании. Главное только не ждать, пока зависнет окончательно. Прямо как в линуксе.
Ответить | Правка | Наверх | Cообщить модератору

50. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  +1 +/
Сообщение от Аноним (41), 06-Янв-20, 03:07 
Линукс легко доходит до ручки потому что у людей обычно и своп включён и высокий лимит на размер кеша записи.

Когда какой-нибудь проге не хватает памяти, ей сначала отдаётся на откуп дисковый кеш чтения (от чего система начинает дико тупить). Затем, если памяти всё равно не хватает, забивается ВЕСЬ своп. Затем сбрасывается на диск ВЕСЬ кэш записи. Именно весь - не по частям, не сколько нужно для выделения памяти, а весь сразу, в один заход. Естественно, кэш может легко содержать несколько гигабайт ещё не закончившихся копироваться данных. Пока все они не окажутся на диске, система висит. И только ПОТОМ ядро начинает прибивать "лишние" процессы.

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

111. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  +/
Сообщение от Аноним (10), 06-Янв-20, 12:01 
>Затем сбрасывается на диск ВЕСЬ кэш записи.

Разве кэш не должен сбрасываться на диск по возможности, но сразу? То есть сначала пишется в кэш, программа продолжает делать что ей нужно, и сразу же кэш начинает сбрасываться на диск, а когда идёт чтение, то проверяется кэш, и выдаётся из кэша, если есть? Ведь иначе при отключении питания весь этот "гиговый" кэш пропадёт. Что-то я не замечал таких огромных потерь данных при вырубании питания.

Ответить | Правка | Наверх | Cообщить модератору

119. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  +/
Сообщение от Аноним (41), 06-Янв-20, 14:15 
Нет, не должен. Некоторые файлы создаются и почти сразу удаляются. Например, временные файлы, создаваемые при компиляции/линковке. Если сбрасывать их на диск с задержкой, можно потом не тратить время на удаление.

При выключении делается тройной вызов sync, стартующий немедленный сброс всех данных на все диски. Потом отмонтируются разделы (вызов unmount завершается только когда все данные в кеше закончат писаться). В некоторых конфигурациях инита у вызова unmount может быть таймаут, и тогда данные действительно потеряются (systemd не использует там таймаут или использует очень длинный, - из-за этого он иногда зависает на неопределённое время при попытке выключения).

Ответить | Правка | Наверх | Cообщить модератору

122. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  +/
Сообщение от Аноним (10), 06-Янв-20, 15:11 
>При выключении

Я не о выключении, а о пропадании питания. Иногда бывает даже в Москве, к сожалению. Так вот, таких огромных потерь данных я не замечал.

Ответить | Правка | Наверх | Cообщить модератору

105. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  +/
Сообщение от Аноним (10), 06-Янв-20, 11:34 
>Конечно фейлится, именно поэтому система не зависает

Главное - верить.

>Наверно там 32 битный софт

64 семёрка с 64 битным QtCreator + Firefox, запущены одновременно. 3 гига. Норм.

64 Kubuntu Eoan с таким же qtcreator и firefox. оверкоммит включёт - всё виснет. оверкоммит выключен - при работающем firefox не то что qtcreator может заглючить и даже иногда вылететь, но даже программы из меню не стартуют (а из предварительно запущенной konsolи - стартуют), видимо кдешники туда вкорячили какую-то жрущую дофига прослойку.

Выводы о качестве операционок делайте сами.

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

140. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  +/
Сообщение от Аноним (8), 06-Янв-20, 19:09 
>qtcreator
>Норм

Проблема наверняка в том, как он собран, я сталкивался с таким. Ну и всё же сравнивать легаси систему 20 летней давности, для которой уже давно не собирают софт, с современной — это несколько некорректно. Как минимум программы не в равных условиях работают. Но повторюсь, проблема скорее всего в вебкитах или чём-нибудь таком, на вскидку можно попробовать установить отсюда и он возможно будет лучше работать https://packages.msys2.org/package/mingw-w64-x86_64-qt-creat...

Ответить | Правка | Наверх | Cообщить модератору

117. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  +/
Сообщение от Аноним (-), 06-Янв-20, 13:40 
> Можете мне поверить
> у виндоус ровно такая же проблема и при исчерпании
> всей памяти и свопа она замечательно зависает целиком и полностью.
> И высока вероятность, что перезагружаться придётся с кнопки ресет
> Можете мне поверить

Чего тебе верить? У меня прямо сейчас под рукой две машины - винда и линукс. Скажу сразу - за последние 5 лет ресетал винду 0 раз. Линукс раз N-ть. Ну чё проверяем?

> Другой разговор, что в такой угол её надо постараться загнать

Забил прямо сейчас всю память/свап на винде - вообще под ноль. Проводник спокойно позволил кликнуть правой кнопкой мыши на муз. плеер и высвободить память - никаких ресетов, да при этом были лаги. Сделал тоже самое тут же на соседней слаке (забил всю память/свап) - просто тотальное замерзание системы - только аппаратный ресет, ни иксы не отвечают + нельзя переключиться по второй/третьей итп консоли.

> Можете мне поверить, у виндоус ровно такая же проблема

Так что верить тебе я не буду, я сам взял под рукой и проверил только что. Так что в винде "ровно такой же проблемы" не существует. А в линуксе она есть и это позор.

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

132. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  +/
Сообщение от Аноним (8), 06-Янв-20, 15:46 
Так это и не загоняние её в угол. Лайтово можно попробовать её повесить виртуалками, для харда нужно уменьшить своп и запустить какую-нибудь жручую игрушку и она наверняка зависнет намертво. Только условие, что у видеокарты должно быть мало памяти, а в коде эта ситуация не должна обрабатываться корректно. Никакие хоткеи и тем более запуск программ работать не будут. :)
Ответить | Правка | Наверх | Cообщить модератору

65. "В Fedora 32 намерены включить earlyoom для раннего реагирова..."  +1 +/
Сообщение от Аноним (65), 06-Янв-20, 06:51 
Прекрасно фейлится. Дайте к примеру в hyper-v виртуальной машине памяти не строго 2 gb например, а по умолчанию "от" и "до" и вы тут же увидите как гость сожрёт всю память и винда зависнет.
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру