The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Выпуск earlyoom 1.2, процесса для раннего реагирования на не..., opennews (??), 04-Ноя-18, (0) [смотреть все]

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


57. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от Аноним (57), 05-Ноя-18, 10:44 
> завершит работу процесса, наиболее активно потребляющего память

Охренеть политика... Убивается активно работающее приложение, которое после скоропостижной кончины оставит на диске хз что. Почему-то винда ещё в давние лохматые годы просто уведомляла юзера "чувак, я тебе свопа добавила", и можно было работать. А эти гении программирования в 2018 году изощряются в способах проактивного убийства процессов.

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

61. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от пох (?), 05-Ноя-18, 10:53 
> Почему-то винда ещё в давние лохматые годы просто уведомляла юзера "чувак, я тебе свопа
> добавила", и можно было работать.

потому что в тех случаях, когда там "можно было работать", в линуксе своп даже не начинался.
В виду разной модели выделения памяти. И да, тогда это считали достижением.

А когда по ctrl-alt-del пол-часа десктоп построчно перерисовывается на пустое место, а process manager так и не всплывает (или нельзя даже переключиться на уже открытый) - результат был в общем примерно тот же что у линуксов - семь бед, один ресет.

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

62. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +1 +/–
Сообщение от Аноним (62), 05-Ноя-18, 11:25 
>Охренеть политика... Убивается активно работающее приложение

Не убивается, а корректно завершается через SIGTERM

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

65. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от Аноним (33), 05-Ноя-18, 11:51 
А чем вот это "свопа добавило" полезно в современных реалиях? Программисты привыкли работать с памятью так, будто её анлим, и возможность своппинга фактически игнорируют. В итоге при своппинге на HDD всё тупит так, что его в любом случае приходится отключать, а своп на SSD как-то нелеп ввиду ограниченности циклов ячеек.

А вот убийство самого жрущего процесса как раз сравнительно безопасно: в серверном софте и память обычно не течет - всё вылизано, и спонтанное убийство он нормально переживает, а уж, тем более, по SIGTERM. Браузер восстановит сессию, ничего страшного. А проблемы самописного софта, в котором течет память - это проблемы его разработчиков.

Может, конечно, неловко получиться, когда условный фотошоп в вайне ест 3 гига из 4, и тут, внезапно, браузер съедает оставшийся гиг, но киляется как раз фотошоп. Но всякий такой софт просто добавляется в --avoid.

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

66. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от Аноним (33), 05-Ноя-18, 11:54 
Ну и да, учитывая, что альтернатива - перезагрузка по трём кнопкам, даже убийство фотошопа в такой ситуации не фатально. Да и он, кажется, в актуальных версиях умеет восстанавливаться после спонтанного вылета.
Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от Аноним (74), 05-Ноя-18, 15:27 
> Программисты привыкли работать с памятью так, будто её анлим

Розгами за это надо пороть. Так, чтобы неделю сесть за клавиатуру не могли.

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

98. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от пох (?), 05-Ноя-18, 22:06 
а что по-твоему современный программист может сделать?
"проверять malloc на null"? Так это показатель некомпетентности.

Можно еще вручную померять доступную память - так делали ранние версии videolan x264 - к сожалению, они не умели отличать реальную от свопа, с интересным результатом ;-)

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

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

110. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от Аноним (33), 06-Ноя-18, 17:30 
эмммм. мы 50+ лет развиваем IT, но до сих пор не можем сделать так, чтобы программа знала, сколько физически памяти в машине, на которой она работает?

нда, абстракции абстракций абстракций это круто, конечно. с таким подходом только со всякими костылями типа earlyoom и можно жить.

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

114. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от пох (?), 06-Ноя-18, 20:12 
> эмммм. мы 50+ лет развиваем IT, но до сих пор не можем сделать так, чтобы программа знала,
> сколько физически памяти в машине, на которой она работает?

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

нет. в позикс-стандартах (даже, наверное, самых наираспоследних, в которые понапихана масса всякого бреда), во всяком случае, такого не было предусмотрено.

К тому же память бывает разная - вон там товарисч, считающий себя очень умным, продемонстрировал некий код для некоей bsd. Но вряд ли он вам сможет объяснить, какую именно память пытается получить этот код. И что, кстати, нужно делать, если ее нет.
Применительно к той же freebsd: у нас есть 1. inactive 2. wired 3. Buf который есть часть этого wired и 4. еще у нас есть zfs arc  - и вот какую часть из этого зоопарка вы считаете "свободной", и с какого, собственно, бодуна именно ее?
А теперь добавим к ним еще zfs abd, захваченные но незанятые сетевым стеком mbufs (на 10G там могут лежать _гигабайты_ памяти - которая в данный момент никак не используется) и кучу всякой другой хрени, о которой я просто не имею несчастья знать, которую и посмотреть-то толком хрен его знает, как.

И как тут определять, что есть свободная память в принципе, и чего дальше-то делать с этим знанием?


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

124. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  –1 +/–
Сообщение от Аноним (33), 07-Ноя-18, 12:35 
Изумительной концепции виртуальной памяти, отучившей программистов думать, и надо говорить спасибо за все тормоза, не объясняющиеся запланированным устареванием, если на то пошло.

А как торрент-клиенты определяют скорость соединения и ограничивает скачивание при забитом канале, чтоб другим не мешать? Даже никаких специальных API на уровне ОС не понадобилось.

Так и здесь никто не мешает сделать: выделение памяти идёт дольше обычного? Память забита, пошла фрагментация, хватит жрать память. Обращение к выделенной памяти даёт заметную тупку? Мы загремели в своп, и снова хватит жрать память. На каждое обращение к памяти такие проверки - долго? Да можно и не на каждое, отдельная проверялка отзывчивости памяти в отдельном потоке раз в N ms.

Нет возможности перестать жрать? Сохраняем состояние на винт и завершаем работу корректно.

Но нет, пусть будет виртуальная память и своп в случайное время с непредсказуемым для пользователя поведением. Программистам же так проще, думать меньше надо.

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

126. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от КГБ СССР (?), 07-Ноя-18, 17:43 
Всё правильно, анон. Действия по упрощению жизни программистов приводят, как правило, к ухудшению получаемой от них готовой продукции.
Ответить | Правка | Наверх | Cообщить модератору

113. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от тот самый аноним (?), 06-Ноя-18, 18:22 
> а что по-твоему современный программист может сделать?
> "проверять malloc на null"? Так это показатель некомпетентности.

О, опять пошли байки о вездесущности overcommit и "современный malloc никогда не возвратит 0"?


# rctl -h
user:restricted:vmemoryuse:deny=1024M/process
user:restricted:memoryuse:deny=512M/process
user:restricted:swapuse:deny=1024M
% uname -rs;whoami && cat test.c && ./test|tail 
FreeBSD 11.2-STABLE
restricted
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#define MB (1024*1024)
#define PSIZE 4096
int main(void){
    size_t sum = 0;
    char *ptr;
    for (size_t i=0;;i++) {
        if ((ptr = malloc(MB)) == NULL) {
            perror("Err:");
            exit(EXIT_FAILURE);
        }
        for (size_t j = 0;j < (MB-PSIZE-1); j += PSIZE) ptr[j] = 0;
        sum += MB;
        printf("allocated: %zu MB\n", sum/MB);
    }
    return EXIT_SUCCESS;
}
allocated: 497 MB
allocated: 498 MB
allocated: 499 MB
allocated: 500 MB
allocated: 501 MB
allocated: 502 MB
allocated: 503 MB
allocated: 504 MB
allocated: 505 MB
allocated: 506 MB
Err:: Cannot allocate memory

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

117. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от пох (?), 06-Ноя-18, 20:33 
>> а что по-твоему современный программист может сделать?
>> "проверять malloc на null"? Так это показатель некомпетентности.
> О, опять пошли байки о вездесущности overcommit и "современный malloc никогда не
> возвратит 0"?

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

> # rctl -h

rctl: RACCT/RCTL support not present in kernel; see rctl(8) for details

то есть ты сам себе разложил отдельное от проблемы оверкомита поле уникальных грабель, и все-все разработчики под тебя, талантище, должны подстраиваться?

rctl предназначен для совершенно другой ситуации - когда на машине заведомый oversubscription, но на проблемы что чему-то не хватит памяти, админу наплевать (читай, массовый шитхостинг), пока это что-то не его, и можно ее урезать всем гораздо ниже физических лимитов.

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

120. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от тот самый аноним (?), 06-Ноя-18, 21:25 
> Ну так пусть сам и проверяет, нечего терять производительность
> - у нормальных людей эти проверки даром будут жрать cpu.

Ну да, лучше пусть словит sigsegv при обращении, потому что третье приложение на электроне за это время выжрало всю оставшуюся память.
Зато целый jnz short после жирного вызова malloc сэкономили. Профит, че.


> rctl: RACCT/RCTL support not present in kernel; see rctl(8) for details
> то есть ты сам себе разложил отдельное от проблемы оверкомита поле уникальных грабель, и все-все разработчики под тебя, талантище, должны подстраиваться?

Сам придумал, сам оспорил. Удобно, да.
Лады, контейнеры не нужны! Жили без этого тысячи лет, значит и дальше проживем!

> rctl предназначен для совершенно другой ситуации - когда на машине заведомый oversubscription,
> но на проблемы что чему-то не хватит памяти, админу наплевать (читай,
> массовый шитхостинг), пока это что-то не его, и можно ее урезать всем гораздо ниже физических лимитов.

Оversubscription будет на любой не самой новой машине с ОЗУ < 9000гигз, особенно мобильной, если запустить кроме браузера еще что-то жручее. Ну или просто долго не закрывать браузер.
А, да, я ж забыл, что у кое-кого на десктопе десяточка. Прошу звиняний, вопросы снимаются.


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

122. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от пох (?), 06-Ноя-18, 21:47 
>> Ну так пусть сам и проверяет, нечего терять производительность
>> - у нормальных людей эти проверки даром будут жрать cpu.
> Ну да, лучше пусть словит sigsegv при обращении, потому что третье приложение

ну словит, результат ровно тот же - ты пойдешь искать дополнительную планку.

> на электроне за это время выжрало всю оставшуюся память.

то есть ты еще и неправильно настроил свой распрекрасный rctl, но виноват опять автор программы, которой памяти не хватило ?

> Зато целый jnz short после жирного вызова malloc сэкономили. Профит, че.

в цикле этак с 10000 итераций, например.

Я тут пытался уговорить разработчиков одной _очень_ известной софтины (очень чувствительной к подобным вещам) на проверку указателей хотя бы в тех случаях, когда там _может_ оказаться null (то есть не malloc, а неправильный набор параметров передан) - получил в ответ "знаешь, он там оказываться не должен, так что лучше мы в этом случае просто функцию вызывать не будем- это в любом случае вредный вызов". И не добавили. Там примерно сотни три таких проверок в теле рекурсивно-вызываемой функции и надо-то, причем срабатывает из этих трех сотен - с десяток максимум в одной итерации (сколько их вообще может быть - не до конца понимаю, вроде и немного).

> Сам придумал, сам оспорил. Удобно, да.
> Лады, контейнеры не нужны! Жили без этого тысячи лет, значит и дальше

контейнеры в том виде, в котором нам их принес доцкер - не, не нужны.

контейнеры в виде jail - нужны для запуска untrusted кода, но это вовсе не означает что в них должен запускаться скачанный без регистрации и sms - у меня таким кодом, к примеру, являлся bind и syslog.

А вот чего такое я хотел бы запускать с дубово-ограниченным размером rss - что-то и придумать не могу. Особенно учитывая сколько сил как раз на платформе freebsd потрачено чтобы память задачам хоть иногда отдавалась.

> Оversubscription будет на любой не самой новой машине с ОЗУ < 9000гигз,
> особенно мобильной, если запустить кроме браузера еще что-то жручее. Ну или

если это жручее не жалко обломить о жесткие лимиты - то зачем, прости, ты его запускал?

> просто долго не закрывать браузер.

      20   0 619m 1279m  70m R     91 20.6 493:27.89 palemoon
достаточно долго?

> А, да, я ж забыл, что у кое-кого на десктопе десяточка. Прошу

у десяточки я не знаю как спросить что-то похожее. Но больше недели точно одна из мурзил не закрывалась.
Там, правда, поменьше табов, что-то около сорока.

> звиняний, вопросы снимаются.

да, у божественной десяточки совсем нет проблемы "выбегает на сцену oom и бросает в зрительный зал гранату". Заметим, без всяких искусственных ограничителей и ненужно-контейнеров там, где они действительно не нужны совсем.

у нее есть другие проблемы, но ей простительно.

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

123. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от тот самый аноним (?), 07-Ноя-18, 00:13 
>> на электроне за это время выжрало всю оставшуюся память.
> то есть ты еще и неправильно настроил свой распрекрасный rctl, но виноват
> опять автор программы, которой памяти не хватило ?

Причем тут rctl? Можешь передергивать не так явно?

>> Зато целый jnz short после жирного вызова malloc сэкономили. Профит, че.
> в цикле этак с 10000 итераций, например.

Какой-какой "например"?
Вызов в цикле 10000 раз malloc? Так и тут дополнительный jnz особой погоды не сделает. Или вы собрались на всякий случай в цикле 10000 раз проверить, не ноль ли вернул вам вызов malloc?


> на остальной передерг можешь сам придумать ответы. Заодно и красиво, с чувсвтом, толком и с расстановкой их опровергнуть.

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

82. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от КГБ СССР (?), 05-Ноя-18, 16:10 
> Программисты привыкли работать с памятью так, будто её анлим,

Таких программистов сжигать в биореакторе и отлучать от профессии навсегда без права обжалования.


> А вот убийство самого жрущего процесса как раз сравнительно безопасно: в серверном
> софте и память обычно не течет - всё вылизано, и спонтанное
> убийство он нормально переживает, а уж, тем более, по SIGTERM. Браузер
> восстановит сессию, ничего страшного.

В серверном софте другие настройки ведра и планировщика. Но, впрочем, это одна из причин выбирать себе на десктоп и ноут серверные редакции ОС.


> А проблемы самописного софта, в котором течет память - это проблемы его разработчиков.

Нет, анон, это именно что наша проблема. Автору г-нокода плевать на мучения юзеров.

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

91. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от Аноним (33), 05-Ноя-18, 19:30 
Юзерам, в свою очередь, плевать, будет ли сожравший всю память и отказавшийся вовремя корректно завершиться по SIGTERM говнокод убит перезагрузкой системы или по SIGKILL.

Говнокод это объективная реальность, данная нам в ощущениях, и, поскольку не во всех случаях можно перейти на отлично-код или написать отлично-код самому, приходится как-то жить с этим явлением. Например, убивать и автоматически перезапускать каким-нибудь systemd этот говнокод до того, как он  положит систему и в итоге будет всё равно убит при перезагрузке.

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

93. "Выпуск earlyoom 1.2, процесса для раннего реагирования на не..."  +/–
Сообщение от КГБ СССР (?), 05-Ноя-18, 19:53 
> Юзерам, в свою очередь, плевать, будет ли сожравший всю память и отказавшийся
> вовремя корректно завершиться по SIGTERM говнокод убит перезагрузкой системы или по
> SIGKILL.
> Говнокод это объективная реальность, данная нам в ощущениях, и, поскольку не во
> всех случаях можно перейти на отлично-код или написать отлично-код самому, приходится
> как-то жить с этим явлением. Например, убивать и автоматически перезапускать каким-нибудь
> systemd этот говнокод до того, как он  положит систему и
> в итоге будет всё равно убит при перезагрузке.

Кому как. Я не могу с этим сжиться. Седьмая Шапка — это уже _не_ юникс, а какой-то SystemdOS. Причём они это, похоже, понимают и сами и в мануалах пишут (см. напр. man init, ага). Пока оно работает, как настроили индусы в Редхате, всё ещё терпимо. Если что-то ломается, то седьмое поколение RHEL и его производных невозможно внятно администрировать по понятиям адекватного юникса. О написании каких-то своих полезных скриптов с учётом концептуального идиотизма системды — даже говорить неохота.

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

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

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




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

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