The OpenNET Project / Index page

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

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


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

Оглавление

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

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


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ообщить модератору

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

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




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

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