The OpenNET Project / Index page

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

Выпуск Nohang 0.1, предотвращающего OOM в пространстве пользователя

23.11.2018 20:10

Состоялся первый выпуск проекта Nohang, в рамках которого подготовлен демон для GNU/Linux, обрабатывающий ситуации нехватки памяти и предотвращающий исчерпание свободной памяти (OOM, Out Of Memory). Демон написан на языке Python, потребляет около 10 MiB VmRSS и настраивается с помощью файла конфигурации (/etc/nohang/nohang.conf). По сравнению с аналогичным проектом earlyoom, nohang обладает некоторыми дополнительными возможностями. Код открыт под лицензией MIT.

Основные особенности:

  • Настраиваемая интенсивность мониторинга: если на сервере не предполагаются резкие перепады потребления памяти, то можно снизить нагрузку на процессор, снизив интенсивность мониторинга;
  • При нехватке памяти nohang сначала отправляет SIGTERM процессу с наибольшим oom_score. При дальнейшем падении уровня доступной памяти и отсутствии реакции на SIGTERM процесс с наибольшим oom_score получает SIGKILL. Уровни доступной памяти, при достижении которых должны происходить корректирующие действия, могут задаваться в процентах и в MiB;
  • Возможность отправки GUI уведомлений о результатах завершения процессов (реализовано с помощью notify-send);
  • Возможность отправки GUI уведомлений о низком уровне доступной памяти. В уведомлениях отображается уровень доступной памяти, а также Pid и имя процесса с наибольшим коэффициентом "badness". Предоставляется возможность настойки уровня памяти, при котором отправляются уведомления, и минимальной периодичности отправки уведомлений (по умолчанию уведомления отключены). Рекомендуемые по умолчанию уровни памяти для отправки: одновременное снижение уровней SwapFree и MemAvailable до 20%;
  • Поддержка zram - mem_used_total в качестве триггера (может быть актуально для систем с большим размером хранилища (disksize) и низкой степенью сжатия сохраняемых в zram данных);
  • Предохранение от безусловного завершения невинных процессов: задержки после отправки сигналов (по умолчанию 0.5 секунд для SIGTERM и 3 секунды для SIGKILL) предотвращают возможное массовое безусловное завершение процессов, так как память при завершении процессов может освобождаться не сразу. Имеется возможность игнорировать процессы, имеющие коэффициент "badness" ниже заданного;
  • Возможность модификации "badness" процессов перед выбором жертвы через сопоставление имён процессов с заданным в конфигурации регулярным выражением;
  • Поддержка настройки запуска произвольной команды (например, sendmail или systemctl restart) вместо отправки сигнала SIGTERM жертве, если имя процесса-жертвы совпадает с заданным в конфигурации именем.


  1. Главная ссылка к новости (https://github.com/hakavlad/no...)
  2. OpenNews: Выпуск earlyoom 1.2, процесса для раннего реагирования на нехватку памяти
  3. OpenNews: Facebook открыл код для обработки ситуации нехватки памяти в системе
  4. OpenNews: Релиз ядра Linux 4.6
  5. OpenNews: Релиз ядра Linux 4.18
  6. OpenNews: Механизм уведомления приложений о нехватке памяти в системе
Автор новости: hakavlad
Тип: Программы
Ключевые слова: nohang, oom, memory
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (143) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (1), 20:29, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +21 +/
    Почему питон то? Если так хочется удобства (т.е. не C), то плюсцов бы хватило.
     
     
  • 2.3, Your Mama (?), 20:35, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Тут и C был бы Ок, ИМХО. Может перепишем на православном?
     
     
  • 3.16, Аноним (16), 22:22, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +22 +/
    На 1С что ли?
     
     
  • 4.35, Аноним (35), 23:14, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Вы зря смеетесь.
    Тут ко мне на днях подошли наши 1с макаки, и потребовали, что бы я на продакшн серверах поставил обработчика языка "OSCRIPT".
    Глянул я это чудо россиянской мысли, посмотрел, увидел, что они даже файлы помощи ("╫ЄхэшхXML.htm" и "─рээ√хPOST╟ряЁюёр.htm" ), записали в некорректной кодировке, и как из интернета оно само тянет невесть какие скрипты из "репозитария" и запускает их, и мне стало плохо.
    Выделил им для забавы отдельную машинку, так эти дегенераты умудрились превратить ее в вирусный рассадник.
     
     
  • 5.89, Гентушник (ok), 18:51, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вы про onescript?
    Разработчики вендузятники, я пытался эту штуку на линуксе запустить, но оно работало довольно криво, ибо много виндово-специфичного захардкожено. Да и вообще оно на дотнете написано.

    А насчёт скриптов из репозиториев... Сейчас у многих языков так заведено - собственный пакетный менеджер (npm, pip и т.д.). Пользоваться никто не заставляет, можете ставить все зависимости руками или пакетным менеджером вашего дистрибутива, если там есть такие пакеты (а их там скорее всего нет).

     
     
  • 6.109, пох (?), 14:21, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сейчас у многих языков так заведено

    да помним, помним мы про npm leftpad!

    > Пользоваться никто не заставляет

    авторы этого дерьма заставляют. Не предусмотрев никакого метода ни фиксации исходников, ни сборки в дистрибутивные пакеты. У них в винде, с которой эти макаки спрыгнули, по другому все равно не бывает.

    > (а их там скорее всего нет)

    потому и нет, что нужны нечеловеческие усилия.

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

     
     
  • 7.158, Аноним (-), 08:20, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > да помним, помним мы про npm leftpad!

    Eval в битмессаге тоже ничего так получился. Целевая аудитория кирпичи откладывали долго. А я 1 раз посмотрел на код этой штуки и выводы сделал о том какой безопасТности от такого ПО можно ждать...

     
  • 2.4, Илья (??), 20:38, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да какая разница? Это же простейшая тула. Питон почти везде установлен
     
     
  • 3.12, Аноним (12), 21:29, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если простейшая то и писать лучше на простом и не требовательном.
     
     
  • 4.24, d (??), 22:36, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    На нём и написали.
     
     
  • 5.100, Аноним (100), 04:17, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не об интеллекте программиста речь была, а о ресурсах системы.
     
  • 3.58, Аноним (58), 06:14, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > почти

    Ключевое слово. Например у меня его нету.

     
  • 3.98, Аноним (98), 23:39, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Специально взглянул исходник. #!/usr/bin/env python3

    Его вообще почти нигде нет по-умолчанию.

    Зачем такие программы писать на питоне?.... Почему нельзя сборку на C сделать?....

     
  • 2.5, Stax (ok), 20:38, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +11 +/
    Если посмотреть на код, становится понятно, почему. В питоне батарейки в комплекте, как известно. А в плюсах без сторонних библиотек делать нечего - даже регэкспов нет (я знаю, что в распоследнем стандарте теоретически есть, но компиляторов и libstdc++ с поддержкой этих стандартов в продакшене вы не встретите). А код чуть менее чем полностью состоит из парзинга всякого разного в /proc, /sys и иже с ними. Такие вещи не только проще, но и безопаснее писать на безопасном языке, где нет целочисленных переполнений, строковых переполнений, выходов за границы массивов, небезопасных операций с указателями и прочего, особенно с учетом того, что программа работает под рутом и не должна добавлять уязвимостей.

    Это можно написать на плюсах, но оно будет хотеть кучу библиотек (напр. монстра boost ради реэкспов) и безопасно это написать тоже будет намного сложнее.

     
     
  • 3.7, ноня (?), 20:54, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это все, конечно, хорошо, я целиком за питон.
    Но, приличия ради, надо упомянуть что программы на питоне не утруждаются проверкой входных данных. Можно такое подсунуть, что самому питону поплохеет. Под рутом. Хорошо если просто вывалится с исключением.
     
     
  • 4.9, Gannet (ok), 21:13, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Раз уж на то пошло, я за Assembler!
     
     
  • 5.67, View (?), 10:27, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем им RegExp-ы? Может ещё нейросети туда завезти?
     
  • 5.159, Аноним (-), 08:21, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Раз уж на то пошло, я за Assembler!

    А для каких архитектур ты его умеешь? На ARM или MIPS смогешь портануть?!

     
     
  • 6.167, Gannet (ok), 04:40, 01/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я не сказал, что я его умею. Но это ведь не мешает мне быть "За", правда?
     
  • 4.64, z (??), 09:11, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    иногда мои программы на языке *вставьте любой язык* тоже не утруждаются проверкой входных данных
     
  • 3.10, Аноним (10), 21:18, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я бы на вашем месте людей не дезинформировал по поводу поддержки последних стандартов. Да, C++17/20 ещё может и не везде и не в полной мере, но C++11 (частью которого <regex> и является) вполне себе поддерживается уже пару лет так точно в libstdc++, libc++ и что-там-у-ms. О качестве реализации говорить не буду, это вопрос отдельный.
     
     
  • 4.13, Stax (ok), 21:29, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Пару лет - поддерживается. Проблема в том, что вы на сервере не встретите штатных компиляторов, которые были бы свежее пары лет. Возьмите свежайший релиз RHEL 7.6 (2018 год) - gcc и libstdc++ 4.8.5 - самые тривиальные регэкспы там или не скомпилируются, или будут непрерывно падать после компиляции. Возьмите еще поддерживаемый RHEL 6.10 (тоже 2018 год) - gcc 4.4, там вообще на эту тему ничего нет.

    И то, что в распоследней убунте или федоре таки будет gcc / libstdc++, которые это умеют, никак не спасает - софт-то нужен на сервере.

    Так что в жизни весь реальный код скорее всего будет использовать pcre (если на C), его же либо boost либо что-нибудь еще, если C++.

    А в питоне модуль re был еще в версии 1.5 (1999 год), которая была где-то в районе 6 редхата. Который просто 6/6.1/6.2, не rhel 6.

     
     
  • 5.22, Michael Shigorin (ok), 22:33, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну pcre, положим, тоже уж немолодое.
     
     
  • 6.27, Stax (ok), 22:41, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да, я всего лишь имел ввиду, что это отдельная внешняя зависимость, а в питоне "все в комплекте" (и, к слову сказать, от pcre он не зависит).
     
     
  • 7.42, Аноним (1), 00:44, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Сейчас бы говорить о комплекте в ОС с репозитариями.
     
  • 5.33, Аноним (33), 22:58, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да что за фигню вы несёте, регекспы давно превосходно работают.
     
     
  • 6.122, Ложечка (?), 18:47, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Да что за фигню вы несёте, регекспы давно превосходно работают.

    Всё он правильно говорит. В libstdc++ 4.8.5 в текущем RHEL7, например заглушки стоят, которые кидают на всё regex_error. Тоже дико угорал с редхатовцев - конформный хедер <regex> есть, но ничего не работает, просто прелесть.

     
     
  • 7.128, Аноним (33), 22:51, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вывод какой? Правильно, не юзать старьё.
     
  • 5.37, all_glory_to_the_hypnotoad (ok), 23:42, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Несёшь полнейшую чушь. Если взять мировых айти гигантов вроде G, FB и их братьев поменьше, которые в совокупности формируют подавляющую долю серверного ПО, то увидишь повальное использование самых свежих компиляторов вроде clang7, gcc6 и с++17. Гогно мамонта, без нормальных санитайзеров и человеческих отчётах об ошибках, в 2018 нафиг никому не сдалось. Но стандартыне re скорее всего никогда не станут популярными. Пользователи плюсов всё таки люди требовательные и им какие попало батарейки не подойдут, особенно если речь о серверном ПО.
     
     
  • 6.44, Алексей Михайлович (?), 01:45, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Лицокнига очень жалует D, кстати говоря. И memory safe, и компилится в нативный код, и много чего вкусного из коробки имеет.
     
     
  • 7.45, all_glory_to_the_hypnotoad (ok), 01:51, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В FB собирают маргиналов со всего мира в надежде на их талантливость, даже местами упарываются функциональщиной. Да в любой крупной компании найдётся букет используемых ЯП. Но основным ЯП серверной разработки кластерного ПО пока осаётся С/C++.
     
     
  • 8.168, Алексей Михайлович (?), 10:17, 11/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Netflix и eBay тоже, наверное, маргиналов по всему миру днём с огнём ищут ... текст свёрнут, показать
     
  • 6.54, Владимир (??), 04:17, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Подождите, у меня у одного возник вопрос а наxера на продакшен сервере компилятор? Ради рантайма что ли?
    Типа задеплоить с нужной либой рантайма компилятора это фуфуфу и моветон?
     
     
  • 7.65, Акакжев (?), 09:46, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Подождите, у меня у одного возник вопрос а наxера на продакшен сервере компилятор? Ради рантайма что ли?

    Это был такой... ораторский приём.

     
  • 7.86, Stax (ok), 17:03, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На продакшен сервере компилятора может не быть Но почему код надо собирать на т... текст свёрнут, показать
     
  • 3.20, asdasd (?), 22:31, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    C++11 с regexp не распоследний и реализуется это не рантаймом, а заголовками с исходниками.
     
     
  • 4.25, Stax (ok), 22:39, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Возможно, но заголовки с исходниками (те libstdc++-devel) настолько же старые, насколько и gcc.
     
     
  • 5.30, asdasd (?), 22:52, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я все равно вас не понял. G++, Clang++, MSVC поддерживают. Что еще нужно?
     
     
  • 6.87, Stax (ok), 17:05, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Я все равно вас не понял. G++, Clang++, MSVC поддерживают. Что еще
    > нужно?

    Возьмите виртуалку с RHEL6/7 и скопимпилируете ваш код с помощью штатных g++ или clang и сразу все поймете. Если лень ставить, можно в AWS взять free tier с RHEL.

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

     
  • 3.43, Аноним (43), 00:53, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > компиляторов и libstdc++ с поддержкой этих стандартов в продакшене вы не встретите

    Какой-то у вас замшелый продакшн. Поддержка regex появилась в gcc 4.9, который вышел в 2015.

     
     
  • 4.72, Аноним (72), 13:11, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В 2014-м
     
  • 3.47, Аноним (47), 02:20, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И все же, подобные штуки стоило писать на системном языке, а не пайтоне.
     
     
  • 4.56, Ordu (ok), 05:51, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    В linux'е пайтон системный язык. Для венды он инороден, в линуксах же последние лет 15-20 он системный. Используется не реже чем bash.

    А вообще, чем языком молоть, если не согласен, возьми и напиши.

     
     
  • 5.60, Аноним (58), 06:19, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > в линуксах же последние лет 15-20

    Как будешь объяснять что у меня его нету? При этом полноценный десктоп на C, C++, Qt.

     
     
  • 6.61, Ordu (ok), 07:01, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    И что это за дистрибутив, если не секрет?
     
     
  • 7.63, Илона (??), 08:48, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Арч 'я у мамы конструктор'.

    Питона у него нет для того чтобы писать в интернете что у него нет питона.

    И сабж ему не нужен принципиально.

     
     
  • 8.157, Аноним (-), 08:17, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    У меня на половине дебианов тоже питона нет Потому что тормозное глюкавое гуано... текст свёрнут, показать
     
  • 6.73, Аноним (72), 13:13, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >Как будешь объяснять что у меня его нету?

    Могу только предположить, что у тебя не Gentoo.

     
  • 5.156, Аноним (-), 08:14, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В linux'е пайтон системный язык.

    Какой он на... системный? Это язык скриптомакак, типа тех которые на васике в 80 програмили. Для работы системы это гуидогуано даром не упало.

     
  • 3.55, iPony (?), 04:27, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если посмотреть на код
    > нужных компиляторов в продакшене вы не встретите

    Если посмотреть на код, тотпонятно, что это наколеннная утилита написаная абы как за кружкой пива. Что ей делать в подакшене?

     
     
  • 4.74, Аноним (72), 13:14, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кто бы про продакшон говорил, но не маководы.
     
  • 3.59, Аноним (58), 06:17, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > даже регэкспов нет

    Вообще-то есть. И с помощью stl можно сделать всё, было бы желание. Для такого простого проекта stl хватило бы с головой.

    > А код чуть менее чем полностью состоит из парзинга всякого разного в /proc, /sys и иже с ними

    Пфф. Я простейший их парсер в 10 строк на чистом C++ писал без всяких регексп.

    > небезопасных операций с указателями и прочего

    В C++ это и не нужно будет. А насчёт того что питон (то есть сам интерпретатор, который ещё и компилировать в нативный код может, duh) не имеет уязвимостей насмешил, конечно. Глянь как-нибудь в их багтрекер.

     
  • 3.62, barmaglot (??), 08:28, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> даже регэкспов нет (я знаю, что в распоследнем стандарте теоретически есть, но компиляторов и libstdc++ с поддержкой этих стандартов в продакшене вы не встретите

    Какая махровая чушь. GCC поддерживает C++11 уже около 7-ми лет точно (c 4.3.x если не ошибаюсь). Что у вас за продакшн такой ?

     
     
  • 4.88, Stax (ok), 17:10, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >>> даже регэкспов нет (я знаю, что в распоследнем стандарте теоретически есть, но компиляторов и libstdc++ с поддержкой этих стандартов в продакшене вы не встретите
    > Какая махровая чушь. GCC поддерживает C++11 уже около 7-ми лет точно (c
    > 4.3.x если не ошибаюсь). Что у вас за продакшн такой ?

    RHEL любой версии. Впрочем, можете взять SLES 12, там ситуация аналогичная (SLES 15 вышел всего несколько месяцев назад, по факту мало кто еще обновился).

    GCC C++11-то поддерживает, но не regexp. Поддержка regexp появилась в 4.9, но по факту много чего не работало до 5.x или 6.x.

     
  • 3.106, Kir (??), 12:32, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Монстр boost ради regex  это одна маленькая библиотека, которая линкуется статически
     
     
  • 4.120, Stax (ok), 17:24, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Монстр boost ради regex  это одна маленькая библиотека, которая линкуется статически

    Ну, некоторым не нравится, что это доступно только в составе 150+ МБ комплекта библиотек. Я, в целом, не против; главное с C++11 regexp осторожнее, тк реально очень много где не заработает.

     
  • 2.26, th3m3 (ok), 22:39, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вот и я думаю, надо было писать на Rust.
     
     
  • 3.75, Аноним (72), 13:17, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    О нет, уж лучше Python, хоть маргинальщина. Этого Rust нет в системе у ещё гораздо большего числа пользователей, чем Python.
     
     
  • 4.79, th3m3 (ok), 14:18, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > О нет, уж лучше Python, хоть маргинальщина. Этого Rust нет в системе
    > у ещё гораздо большего числа пользователей, чем Python.

    А он в системе и ненужен для запуска, это же не Python  :) Rust же компилируемый, будет просто бинарик.

     
     
  • 5.83, mikhailnov (ok), 16:01, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На e2k mike@ уже завез Rust? Нет и не будет в ближайшее время.
     
  • 2.66, Анонидзе (?), 10:15, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А чем он плох? Простой и очень удобный язык. Или ты хочешь, чтобы у демона, предотвращающего нехватку ОЗУ, постоянно текло это самое ОЗУ?
     
  • 2.155, Аноним (-), 08:11, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему питон то? Если так хочется удобства (т.е. не C), то плюсцов бы хватило.

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

    Но, понятное дело что питонисты о таких интимных особенностях системного программирования - как свиньи об апельсинах.

     

     ....большая нить свёрнута, показать (61)

  • 1.2, Аноним (2), 20:33, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эта тулза мне нужна.

    29 выпуск федоры течёт не отображает какой процесс не освобождает память.

     
     
  • 2.23, Michael Shigorin (ok), 22:34, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Возьмите lavaps :)
     

  • 1.8, Аноним84701 (ok), 21:09, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    earlyloom, nohang, oomd (https://www.opennet.ru/opennews/art.shtml?num=48994)
    Астрологи объявили полугодие юзерспейсных заменителей ООМ?

    Интересно, мне одному такая формулировка режет глаз?
    > Предохранение от убийства невинных процессов … возможное массовое убийство процессов

    Вместо:
    > "Предохранения от принудительного завершения непричастных процессов … возможное массовое завершение процессов"
    >

     
     
  • 2.14, Gannet (ok), 21:45, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Предлагаю следующую:
    Предотвращение геноцида процессов не замеченных в причастности к жадности памяти и излишней геперактивности в дисковом пространстве.
     
  • 2.36, Аноним (36), 23:37, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    People for ethical treatment of digital entities. Stop killing them!
     
  • 2.48, Аноним (47), 02:22, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Все это похоже на жуткие костыли.
     
  • 2.96, Himik (ok), 23:13, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    По-моему в FSF киллеров объявили вне закона, и вот опять...
     
  • 2.154, Andrey Mitrofanov (?), 09:49, 29/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Прочитал заголовок---^^, подумал "новая игрушка поттера".  Ан нет.

    > Астрологи объявили полугодие юзерспейсных заменителей ООМ?

    //Ага. Про это уже пошутили, надо держаться. Держаться.

     

  • 1.11, Аноним (11), 21:26, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а для докера эта тулза имеет смысл? вот с oom падает контейнер, какой профит предоставляет данная утилита, не вижу рабочей ситуации.
     
     
  • 2.49, DerRoteBaron (ok), 02:30, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    такой, что контейнер будет перезапущен не тогда, когда памяти уже нет, почти все страницы с кодом выгружены на диск, а отзывчивость системы потеряна, а когда сильно плохо еще не стало, и деградация отзывчивости не будет существенной
     

  • 1.15, Аноним (15), 22:02, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Почему на python, а не на nodejs?
     
     
  • 2.17, Аноним (17), 22:25, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    в node.js был npm leftpad, а пихон это "искуственный дата майнинк дип лёрнинк бик дата интелект" с нескучным синтаксисом
     
  • 2.18, Аноним (18), 22:26, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это сарказм?
     
  • 2.28, th3m3 (ok), 22:41, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Радуйся, что не на Electron.
     
  • 2.29, Аноним (33), 22:45, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Зачем мелочиться, надо сразу на electron.
     
  • 2.112, Xasd (ok), 14:54, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    заменить python на electron ещё ни кто не успел предложить?
     

  • 1.21, Аноним (33), 22:31, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Походу линю нужен особый сигнал OOM, сообщающий процессу, что если он сейчас немедленно не освободит память, то его прибьют. Всё лишь бы баг 12309 не фиксить.
     
     
  • 2.76, Аноним (72), 13:20, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    За...ли вы уже со своим 12309, не смешно уже, придумайте шутку посвежее.
     
     
  • 3.82, Кирилл (??), 15:07, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, не смешно, потому что сколь бы не говорили о том, что 12309 давно исправлен (раза три уже говорили, что "ну вот теперь точно пофиксили"), он до сих поп проявляется и имеет место быть.
     
     
  • 4.139, none_first (ok), 13:59, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Да, не смешно, потому что сколь бы не говорили о том, что
    > 12309 давно исправлен (раза три уже говорили, что "ну вот теперь
    > точно пофиксили"), он до сих поп проявляется и имеет место быть.

    цитата с лурка: http://lurkmore.to/12309#.D0.9D.D0.B0_.D1.81.D0.B0.D0.BC.D0.BE.D0.BC_.D0.B4.D
    перевожу - виндовз крякнет чавкой с высокой вероятностью и работа виндовзусера закончится "как всегда" - перезапуском мсявого творения
    и да - забивать память вской уйней и быдлопрограммами - это в крови виндовзусеров ;)

     
  • 4.160, Аноним (160), 08:30, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    До некоторых так за столько лет никак не дойдет что разные тормоза разныз конфиг... текст свёрнут, показать
     
     
  • 5.166, Аноним (-), 13:32, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > До некоторых так за столько лет никак не дойдет что разные тормоза
    > разныз конфигураций, ВНЕЗАПНО могут быть РАЗНЫМИ багами, по РАЗНЫМ причинам.

    До некоторых за столько лет никак не дойдет, что 12309 давно стало собирательным обозначением.

     
  • 2.77, Аноним (-), 13:35, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тогда почему вы пишите комментарии в интернете, а не фиксите баг
     
  • 2.131, Аноним (131), 01:58, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    И процесс, получив такой сигнал, начинает лихорадочно шариться по своему адресному пространству выискивая что бы такого освободить, тем самым только увеличивая интенсивность пейджинга.
     
  • 2.136, SysA (?), 12:19, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Bug 12309 - Status: CLOSED CODE_FIX ;)
     

  • 1.32, Онаним (?), 22:58, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачем оно? kernel oom handler'а мало?
     
     
  • 2.46, Аноним (46), 02:12, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вроде неоднократно везде писали, что он слишком слоупочный и ненастраиваемый.
     
     
  • 3.68, Онаним (?), 10:56, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что значит ненастраиваемый? Есть oom_adj, есть memory cgroups.
     
  • 3.161, Аноним (160), 08:33, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Вроде неоднократно везде писали, что он слишком слоупочный

    Если своп убрать нафиг или перенести в zram (эмулировать оперативку винчом слоупочно хоть там как) - более-менее нормальный становится. Хрустеть будет разве что на paging бинарников на диске, но это относительно немного. А на SSD так никто и не заметит, там быстро. Так что система тупанет несколько секунд да грохнет offender'а. Чаще всего по делу при том. А вес таки настраивается. И если кто ценный, можно настроить ему вес пониже и его постараются не убивать, кроме совсем уж ж@пных ситуаций.

    Ну и написать такой тул на питоне - это просто глум над здравым смыслом.

     

  • 1.38, M i M (?), 23:46, 23/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Глянул.
    Какой-то трэш и каша.
    Комментарии и сообщения в перемешку на английском и на русском.
    Весь код свален в одну кучу:
    https://github.com/hakavlad/nohang/blob/master/nohang
     
     
  • 2.39, M i M (?), 23:57, 23/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И да, ни одного теста не увидел.
    Пожалуй, я бы побоялся такое запускать, даже если бы оно мне было нужно.

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

     
  • 2.40, Нодежээсовцы и питонисты (?), 00:02, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ну если ты не понимаешь что-то это не значит что написано плохо. Писать юникс-демоны - задача сложная. Код сложный потому что тема сложная.

    Linux, nohang, X.Org Server... у всех этих наших проектов высок порог вхождения, мы пишем системные вещи.

     
     
  • 3.41, M i M (?), 00:05, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Код там не сложный, но его качество оставляет желать лучшего.
     
  • 2.57, Ordu (ok), 05:55, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Весь код свален в одну кучу:

    Там всего 1.5k строк, включая комменты и пустые строки, кои по моему в коде используются излишне часто. Если бы там было 5-10k можно было бы поныть, что слишком много в одном файле, а так...

     
     
  • 3.84, Аноним (84), 16:25, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это уже очень много. Есть принцип единой ответственности, который явно нарушается.
     
     
  • 4.92, Ordu (ok), 19:48, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Это уже очень много. Есть принцип единой ответственности, который явно нарушается.

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

     
  • 3.103, zoonman (ok), 08:13, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ># found experimentally
    >zram_disksize_factor = 0.0042

    Магические константы, забытые комменатрии, отсутствие какой-либо структуры. Код требует шлифовки.
    Вообще его бы переписать на Go, работал бы быстрее и память меньше кушал.
    Считаю текущий вариант прототипом и в продакшене такое бы использовать не стал.
    Советую Алексею привести код в порядок, добавить тесты и бенчмарки.

     
     
  • 4.111, Ordu (ok), 14:40, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Я к любому коду могу придраться, и сказать ой, фу, тут не то, а здесь не так К ... текст свёрнут, показать
     
     
  • 5.113, Xasd (ok), 15:00, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > в нём чётко указано, что версия софтины 0.1.

    это много или мало?

    если там было бы написано что версия софтины 345.0 (а не 0.1) -- это говорило бы о чём-то другом?

     
     
  • 6.114, Ordu (ok), 15:10, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> в нём чётко указано, что версия софтины 0.1.
    > это много или мало?
    > если там было бы написано что версия софтины 345.0 (а не 0.1)
    > -- это говорило бы о чём-то другом?

    Да.

     
  • 6.129, zoonman (ok), 23:12, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это такой способ сделать тег. Поставил первый попавшийся тег, v0.1 показался нормальным.
    Человек знакомый с версионированием сделал бы 0.0.1-alpha.
    Т.к. это самая настоящая альфа.
     
     
  • 7.133, Ordu (ok), 02:59, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Бла-бла-бла Ещё один начитавшийся учебников Как много тебе известно примеров п... текст свёрнут, показать
     
     
  • 8.140, none_first (ok), 14:36, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https greenteapress com wp think-bayes если про эту книгу - то название неско... текст свёрнут, показать
     
  • 8.148, zoonman (ok), 19:45, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Пора кому-то повзрослеть Учебники написаны на основе реального опыта других люд... текст свёрнут, показать
     
     
  • 9.150, Ordu (ok), 22:55, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да, несомненно Но учебник -- это не опыт Даже если это хороший учебник, то чте... текст свёрнут, показать
     
  • 5.130, zoonman (ok), 23:16, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Торвальдс уже давно не тот: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id= ;-)
     
     
  • 6.134, Ordu (ok), 03:00, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Торвальдс уже давно не тот: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=
    > ;-)

    Вот к чему ты это сказал? Во-первых, не то чтоб давно, во-вторых, мне-то что? Если Торвальдс принимает Code of Conduct, меня это разве к чему-то обязывает? Или заветы Торвальдса перестали быть заветами Торвальдса?

     
     
  • 7.137, нах (?), 12:31, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Если Торвальдс принимает Code of Conduct, меня это разве к чему-то обязывает?

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

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

     
     
  • 8.138, Ordu (ok), 13:37, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты о чём вообще, родный Ты тред читал Я сказал о том, что я следую завету Торв... текст свёрнут, показать
     
     
  • 9.142, Michael Shigorin (ok), 17:30, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Коллеги, прям озадачили ... текст свёрнут, показать
     
  • 9.143, нах (?), 17:59, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ты топ-топ менеджер линукса или сравнимого по размеру проекта Санитары Этого ... текст свёрнут, показать
     
     
  • 10.149, Ordu (ok), 21:33, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, но и тем не менее я советую даже разработчикам небольших и даже прям скажем... текст свёрнут, показать
     
  • 4.145, Аноним (145), 19:09, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >zram_disksize_factor = 0.0042

    Описание есть в начале файла.

    >забытые комменатрии

    Где?

    >отсутствие какой-либо структуры

    Структура есть, код разделен на разделы, разделенные строками ############################, и разделы прокомментированы.

    >Вообще его бы переписать на Go, работал бы быстрее и память меньше кушал.

    Уже. Старт дан. https://github.com/hakavlad/nofreeze

    >Считаю текущий вариант прототипом

    как вам угодно. Тем не менее, прототип прекрасно работает.

     
     
  • 5.146, zoonman (ok), 19:24, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вот целый кусок забытых комментариев
    https://github.com/hakavlad/nohang/blob/master/nohang#L934

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

    У вас хорошая идея, продолжайте ее развивать.

     
     
  • 6.147, Аноним (145), 19:29, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это прям свежий коммит, не от автора. Будет почищено вскоре. Ничего не забыто.
     
  • 2.152, Аноним (152), 17:56, 28/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Говнокод ещё тот

    # НА МЕСТЕ!!!
    if 'swap_min_warnings' in config_dict:
        swap_min_warnings = config_dict['swap_min_warnings']

     
     
  • 3.153, Аноним (145), 05:14, 29/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Что Вас смутило в этом участке кода?
     
     
  • 4.163, Аноним (-), 08:40, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Что Вас смутило в этом участке кода?

    Ну вот меня например такой комент в коде смущает. Видя такое я как-то сразу прикидываю что и остальное каКчество кода оправдает самые смелые ожидания.

     
  • 2.162, Аноним (-), 08:38, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это ты еще код bitmessage читать не пробовал Сразу видно - крутой про огреб кру... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (29)

  • 1.50, Аноним (50), 02:42, 24/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Решение несуществующей проблемы.
    Намного логичнее выставить лимиты памяти в cgroups тем процессам, которые ее могут схавать. Да, браузеру.
     
     
  • 2.119, Аноним (145), 16:46, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Решение несуществующей проблемы.

    Проблема есть, look at https://www.reddit.com/r/linux/comments/56r4xj/why_are_low_memory_conditions_h

    >Намного логичнее выставить лимиты памяти в cgroups тем процессам, которые ее могут схавать. Да, браузеру.

    Nohang ни к чему вас не обязывает. Делайте так, как считаете нужным.

     
     
  • 3.132, Аноним (132), 02:45, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это не проблема, а вопрос неопытного пользователя.
    На который ему ответили. В том числе указав, что если есть предположения о том, что потребуется завершать в первую очередь, то можно предупредить проблему с помощью cgroups.

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

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

     

  • 1.51, anonkin (?), 03:06, 24/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    *лицоладонь*

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

    и будет эпично, если сам этот nohang подвесит систему))

     
     
  • 2.70, Нанобот (ok), 12:18, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > а если памяти не хватает, то конечно какие-то приложения будут прибиваться, этого не избежать

    просто некоторые свято верят, что любую проблему можно решить, если прибивать процессы в правильном порядке

     
     
  • 3.116, Аноним (-), 15:43, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >> а если памяти не хватает, то конечно какие-то приложения будут прибиваться, этого не избежать
    > просто некоторые свято верят, что любую проблему можно решить, если прибивать процессы
    > в правильном порядке

    systemd что ли?

     

  • 1.52, Sw00p aka Jerom (?), 03:59, 24/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    я вот только одного вкурить не могу - в чём разница между убитым процессом (из-за ООМ) и процессом который никогда не выполнится (то есть не использовать данное ПО, которое течет)?
     
  • 1.53, Vitaliy Blats (?), 04:13, 24/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Вот уж типично линуксячий подход - создать технологию которая будет килять процессы для освобождения памяти, а потом создать тулзу которая будет мешать этой технологии которая киляет процессы для освобождения памяти.

    Если процесс стал потреблять ОЗУ - он это сделал не зря, значит ему так нужно. Что будет если mysqld с криво настроенным innodb_buffer_pool_size получит SIGTERM? Он резко выгрузит все таблицы, кэши и тд ? Сомневаюсь. А значит получит SIGKILL и будет то же самое что и просто с OOM но при этом на серваке не будет стоять левое пихоновое поделие. А раз так, то зачем ставить это на сервер ?


    Короче что только не придумают, лишь бы не сделать
    fallocate -l 2G /anti_oom;mkswap /anti_oom;swapon /anti_oom

     
     
  • 2.69, Онаним (?), 10:59, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Короче что только не придумают, лишь бы не сделать

    fallocate -l 2G /anti_oom;mkswap /anti_oom;swapon /anti_oom

    Когда упрётесь в производительность например SAN - поймёте, почему не надо так делать.

    Впрочем, это не отменяет того, что ядрёного механизма OOM вкупе с cgroups для контроля за oom-ситуациями более, чем достаточно.

     
     
  • 3.81, Vitaliy Blats (?), 14:24, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Когда упрётесь в производительность например SAN

    Переполнение памяти обычно бывает по двум причинам:

    1. Владелец железки криворукий олень и установил несовместимое количество софта\железного ОЗУ на девайс. Ну например купил ВПСку шоб подешевше, с гигабайтом мозгов, и заставил ее обрабатывать веб на 1000 коннектов в секунду и на apache. Тогда его своп ДОЛЖЕН юзаться активно, и все это рано или поздно упрется в производительность. То же самое можно сделать на дорогом оборудовании, просто в других масштабах, суть не изменится.

    2. Случайный всплеск. Ну вот поставили вы гигабайт ОЗУ на вашу ВПСку, все настроили тоненько тоненько, отлично работает, но раз в неделю ваш плагин на Вордпрессе делает бэкап, и тогда нужны дополнительные пару мегабайт ОЗУ на час.

    В первом случае владелец железки сам себе злобный буратино, и его не спасут никакие Nohang'и даже свопы: ему надо либо умерять аппетит софта к железу, либо апгрейдить железо к аппетиту софта.
    Во втором случае никакой просадки скорости не будет, пушо своп будет временной мерой для непродолжительной операции.

     
     
  • 4.90, Онаним (?), 19:27, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    1) да
    2) см. п.1
     
     
  • 5.91, Онаним (?), 19:28, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    За исключением свопа в п.1 - как только скрипт у хостера заметит аномальную дисковую активность от непрерывно юзаемого свопа, он сразу же нерегламентированный IOPS порежет.
     
  • 2.94, Аноним (33), 22:34, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Понимаете ли, на линуксе совершенно отвратительные механизмы управления памятью ... текст свёрнут, показать
     
     
  • 3.95, Michael Shigorin (ok), 22:42, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну да, ну да.  LGBT-шники из MoFo жрут память тоннами, а виноват линукс.  И пишет нам об этом многолетний хакер ядёр и VM-ов, не иначе.
     
     
  • 4.102, Аноним (102), 06:48, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Firefox так себя ведет не важно под какой ОС. Из всех браузеров включая Edge. Именно Firefox сейчас жрет больше всего ОЗУ и нагружает CPU ради пресвятого JS.

    Самый банальный пример: https://www.twitch.tv/videos/340281255?t=36m20s

     
  • 4.117, Аноним (33), 15:46, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Как уже заметили,жрёт на всех ОС, а колом всё встаёт шт этого только на Лине.
     
     
  • 5.151, трурль (?), 20:43, 27/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Как уже соврали,жрёт на всех ОС, а колом всё встаёт шт этого только на Лине.

    fixed

     
  • 3.101, Аноним (102), 06:41, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Чем-то же нужно мотивировать продажу 32+гб ноутбуков.
    Поделия JetBrains на виртуалке с 4гб озу уже моментально пишут в swap после открытия Hello World.
     
     
  • 4.118, Аноним (33), 15:48, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    IDE под JVM лучше вообще не использовать.
     
  • 2.164, Аноним (-), 08:45, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А что будет, если ядру потребуется память и оно не сможет ее себе выкроить, сэр ... текст свёрнут, показать
     

  • 1.78, RomanCh (ok), 13:53, 24/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Какой дурдом. Пишем watchdog для контроля потребления ресурса на языке который сам любит пожрать этого ресурса. Напоминает государственную систему управления - нужно больше чиновников контролирующих потребление государственных средств!

    Что только не сделают что бы cgroups + cgrulesengd не изучать...

    PS

    ps -C cgrulesengd -o rss
      RSS
    1712

     
  • 1.93, InuYasha (?), 21:52, 24/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А летом было вот это: https://www.opennet.ru/opennews/art.shtml?num=48994 от фейсбука =)
     
     
  • 2.97, Аноним (97), 23:35, 24/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Такое вот хреновое лето... (с)
     

  • 1.99, Аноним (102), 02:37, 25/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >> Демон написан на языке Python, потребляет около 10 MiB VmRSS и настраивается с помощью файла конфигурации (/etc/nohang/nohang.conf)

    Подозреваю если его переписать на C/C++/Go/Rust/whatever он будет занимать 1 Мб памяти максимум?

     
     
  • 2.104, Аноним (104), 10:31, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Feel free to implement?
     
  • 2.108, Аноним (145), 14:05, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Больше. Earlyoom на C занимает 2 МБ.
     
     
  • 3.121, Аноним (33), 18:21, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >About 2 MiB (VmRSS), though only 220 kiB is private memory (RssAnon). The rest is the libc library (RssFile) that is shared with other processes.
     
  • 3.165, Аноним (-), 08:48, 30/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Больше. Earlyoom на C занимает 2 МБ.

    У питона один только интерпретатор нынче занимает заметно больше. Это при том что программу вообще выполнять не начали даже. А ей тоже что-то надо. Хотя питонисты конечно же цифры мастерски подгоняют - но системные штуки интересны тем что там если кого-то и можно на...ть то разве что самого себя.

     
  • 2.135, Проходил мимо (?), 07:13, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если его переписать на С, то, думаю, он будет занимать не более сотни килобайт.

    У Rust бинарник, призванный анализировать лог почтового сервера и собранный с ключом --release занимает на диске порядка 400 Кб, а если собрать отладочную версию, то порядка 1.3Мб. При этом дебажная версия обрабатывает 500 Мб mail.log примерно за 2 минуты, а релизная примерно за 10 секунд. Я хз, как им удалось так затормозить дебажную версию, до этого ни в одном языке таких тормозов не было. И это не ошибка в алгоритме, это именно тормоза кода, так как --release работает быстро.

    У Go бинарник на диске весит порядка 2Мб, если сделать ему strip, то от несколько худеет, но при этом это статическая версия, не имеющая никаких зависимостей.

     

  • 1.105, Ддд (?), 11:12, 25/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Издевательство. Могу на Голанг сиатически слинкованный бинарник запилить и весить будет мегабайт
     
     
  • 2.107, Аноним (145), 14:03, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, https://github.com/hakavlad/nofreeze
     
     
  • 3.110, Аноним84701 (ok), 14:26, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати, https://github.com/hakavlad/nofreeze

    [code]
    func main() {
    ...
    var t float64 = 0.001
    var oo float64 = 1000000000 * t
    var tt time.Duration = time.Duration(oo)

    var yoba int8 = 1

    for true {

    fmt.Println(yoba, yoba, yoba)

    time.Sleep(tt)
    //u++
    //u--
    }
    [/code]
    мощно!

     
     
  • 4.124, КГБ СССР (?), 19:09, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вот ведь как бывает: один аноним не поленился заглянуть в г-нокод, а другие заберут в продакшын. Программа как раз на должном уровне. :)

    yoba, yoba, yoba!

     

  • 1.115, Аноним (115), 15:33, 25/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень хорошая и нужная вещь!!! Совместно с ulatencyd можно выжать максимум с компа!!!
     
  • 1.125, Аноим (?), 21:48, 25/11/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Вместо того, чтобы расширить функционал ООМ, запилили ненужную прослойку. Всегда так. Вместо того, чтобы обновить ifconfig - объявили ее deprecated и написали сразу веер новых фуфлокоманд.
    Linux-way как он есть
     
     
  • 2.126, Stax (ok), 22:26, 25/11/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Вместо того, чтобы расширить функционал ООМ, запилили ненужную прослойку. Всегда так. Вместо
    > того, чтобы обновить ifconfig - объявили ее deprecated и написали сразу
    > веер новых фуфлокоманд.
    > Linux-way как он есть

    У вас какой-то баттхерт личного характера на тему устаревания ifconfig? Е-мае, больше 15 лет как iproute2 в ядре а ifconfig не более чем обертка, он раньше 2000 года появился точно. Где-то с ядра 2.2 еще. Можно было за этот срок и научиться пользоватся ip, не?

    А по поводу linux-way - ну тут решили так, а что такого? Все равно стандарта никакого на ifconfig/route нет. Их синтаксис в линуксе, фряхе и солярисе разный, возможности тоже разные.

     
     
  • 3.144, нах (?), 18:09, 26/11/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Все равно стандарта никакого на ifconfig/route нет. Их синтаксис в линуксе,
    > фряхе и солярисе разный, возможности тоже разные.

    то есть собственно, ровно до того места, где они одинаковые - кривой враппер, который еще в 2000м грозились выкинуть, эту самую совместимость вполне обеспечивает. Ну вдруг забрел админ bsd386 из криокамеры, и ему к ней непременно надо по ip подключиться, чтоб обратно залезть - на это хватит и его умений и того ifconfig.
    (на самом деле там не так все солнечно - это два разных ядерных интерфейса, первый тоже для совместимости, используется, но крайне редко по делу, а второй теоретически может быть не вкомпилен в ядро)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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