Состоялся первый выпуск проекта Nohang (https://github.com/hakavlad/nohang), в рамках которого подготовлен демон для GNU/Linux, обрабатывающий ситуации нехватки памяти и предотвращающий исчерпание свободной памяти (OOM, Out Of Memory). Демон написан на языке Python, потребляет около 10 MiB VmRSS и настраивается с помощью файла конфигурации (/etc/nohang/nohang.conf). По сравнению с аналогичным проектом earlyoom, nohang обладает некоторыми дополнительными возможностями. Код открыт (https://github.com/hakavlad/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 жертве, если имя процесса-жертвы совпадает с заданным в конфигурации именем.
URL: https://github.com/hakavlad/nohang
Новость: https://www.opennet.me/opennews/art.shtml?num=49653
Почему питон то? Если так хочется удобства (т.е. не C), то плюсцов бы хватило.
Тут и C был бы Ок, ИМХО. Может перепишем на православном?
На 1С что ли?
Вы зря смеетесь.
Тут ко мне на днях подошли наши 1с макаки, и потребовали, что бы я на продакшн серверах поставил обработчика языка "OSCRIPT".
Глянул я это чудо россиянской мысли, посмотрел, увидел, что они даже файлы помощи ("╫ЄхэшхXML.htm" и "─рээ√хPOST╟ряЁюёр.htm" ), записали в некорректной кодировке, и как из интернета оно само тянет невесть какие скрипты из "репозитария" и запускает их, и мне стало плохо.
Выделил им для забавы отдельную машинку, так эти дегенераты умудрились превратить ее в вирусный рассадник.
Вы про onescript?
Разработчики вендузятники, я пытался эту штуку на линуксе запустить, но оно работало довольно криво, ибо много виндово-специфичного захардкожено. Да и вообще оно на дотнете написано.А насчёт скриптов из репозиториев... Сейчас у многих языков так заведено - собственный пакетный менеджер (npm, pip и т.д.). Пользоваться никто не заставляет, можете ставить все зависимости руками или пакетным менеджером вашего дистрибутива, если там есть такие пакеты (а их там скорее всего нет).
> Сейчас у многих языков так заведенода помним, помним мы про npm leftpad!
> Пользоваться никто не заставляет
авторы этого дерьма заставляют. Не предусмотрев никакого метода ни фиксации исходников, ни сборки в дистрибутивные пакеты. У них в винде, с которой эти макаки спрыгнули, по другому все равно не бывает.
> (а их там скорее всего нет)
потому и нет, что нужны нечеловеческие усилия.
причем до понимания необходимости пакетных менеджеров они уже сами додумались, или подсказали, неважно, а вот понимания, почему в дистрибутивах сделано не так, и они, кроме генты, никогда не автопересобираются каждый раз по-новому из каждый раз новых наисвежайших исходников, ждать не приходится.
> да помним, помним мы про npm leftpad!Eval в битмессаге тоже ничего так получился. Целевая аудитория кирпичи откладывали долго. А я 1 раз посмотрел на код этой штуки и выводы сделал о том какой безопасТности от такого ПО можно ждать...
Да какая разница? Это же простейшая тула. Питон почти везде установлен
Если простейшая то и писать лучше на простом и не требовательном.
На нём и написали.
Не об интеллекте программиста речь была, а о ресурсах системы.
> почтиКлючевое слово. Например у меня его нету.
Специально взглянул исходник. #!/usr/bin/env python3Его вообще почти нигде нет по-умолчанию.
Зачем такие программы писать на питоне?.... Почему нельзя сборку на C сделать?....
Если посмотреть на код, становится понятно, почему. В питоне батарейки в комплекте, как известно. А в плюсах без сторонних библиотек делать нечего - даже регэкспов нет (я знаю, что в распоследнем стандарте теоретически есть, но компиляторов и libstdc++ с поддержкой этих стандартов в продакшене вы не встретите). А код чуть менее чем полностью состоит из парзинга всякого разного в /proc, /sys и иже с ними. Такие вещи не только проще, но и безопаснее писать на безопасном языке, где нет целочисленных переполнений, строковых переполнений, выходов за границы массивов, небезопасных операций с указателями и прочего, особенно с учетом того, что программа работает под рутом и не должна добавлять уязвимостей.Это можно написать на плюсах, но оно будет хотеть кучу библиотек (напр. монстра boost ради реэкспов) и безопасно это написать тоже будет намного сложнее.
Это все, конечно, хорошо, я целиком за питон.
Но, приличия ради, надо упомянуть что программы на питоне не утруждаются проверкой входных данных. Можно такое подсунуть, что самому питону поплохеет. Под рутом. Хорошо если просто вывалится с исключением.
Раз уж на то пошло, я за Assembler!
Зачем им RegExp-ы? Может ещё нейросети туда завезти?
> Раз уж на то пошло, я за Assembler!А для каких архитектур ты его умеешь? На ARM или MIPS смогешь портануть?!
Я не сказал, что я его умею. Но это ведь не мешает мне быть "За", правда?
иногда мои программы на языке *вставьте любой язык* тоже не утруждаются проверкой входных данных
Я бы на вашем месте людей не дезинформировал по поводу поддержки последних стандартов. Да, C++17/20 ещё может и не везде и не в полной мере, но C++11 (частью которого <regex> и является) вполне себе поддерживается уже пару лет так точно в libstdc++, libc++ и что-там-у-ms. О качестве реализации говорить не буду, это вопрос отдельный.
Пару лет - поддерживается. Проблема в том, что вы на сервере не встретите штатных компиляторов, которые были бы свежее пары лет. Возьмите свежайший релиз 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.
Ну pcre, положим, тоже уж немолодое.
Да, я всего лишь имел ввиду, что это отдельная внешняя зависимость, а в питоне "все в комплекте" (и, к слову сказать, от pcre он не зависит).
Сейчас бы говорить о комплекте в ОС с репозитариями.
Да что за фигню вы несёте, регекспы давно превосходно работают.
>Да что за фигню вы несёте, регекспы давно превосходно работают.Всё он правильно говорит. В libstdc++ 4.8.5 в текущем RHEL7, например заглушки стоят, которые кидают на всё regex_error. Тоже дико угорал с редхатовцев - конформный хедер <regex> есть, но ничего не работает, просто прелесть.
Вывод какой? Правильно, не юзать старьё.
Несёшь полнейшую чушь. Если взять мировых айти гигантов вроде G, FB и их братьев поменьше, которые в совокупности формируют подавляющую долю серверного ПО, то увидишь повальное использование самых свежих компиляторов вроде clang7, gcc6 и с++17. Гогно мамонта, без нормальных санитайзеров и человеческих отчётах об ошибках, в 2018 нафиг никому не сдалось. Но стандартыне re скорее всего никогда не станут популярными. Пользователи плюсов всё таки люди требовательные и им какие попало батарейки не подойдут, особенно если речь о серверном ПО.
Лицокнига очень жалует D, кстати говоря. И memory safe, и компилится в нативный код, и много чего вкусного из коробки имеет.
В FB собирают маргиналов со всего мира в надежде на их талантливость, даже местами упарываются функциональщиной. Да в любой крупной компании найдётся букет используемых ЯП. Но основным ЯП серверной разработки кластерного ПО пока осаётся С/C++.
> В FB собирают маргиналов со всего мира в надежде на их талантливость,
> даже местами упарываются функциональщиной. Да в любой крупной компании найдётся букет
> используемых ЯП. Но основным ЯП серверной разработки кластерного ПО пока осаётся
> С/C++.Netflix и eBay тоже, наверное, маргиналов по всему миру днём с огнём ищут.
Подождите, у меня у одного возник вопрос а наxера на продакшен сервере компилятор? Ради рантайма что ли?
Типа задеплоить с нужной либой рантайма компилятора это фуфуфу и моветон?
> Подождите, у меня у одного возник вопрос а наxера на продакшен сервере компилятор? Ради рантайма что ли?Это был такой... ораторский приём.
> Подождите, у меня у одного возник вопрос а наxера на продакшен сервере
> компилятор? Ради рантайма что ли?
> Типа задеплоить с нужной либой рантайма компилятора это фуфуфу и моветон?На продакшен сервере компилятора может не быть. Но почему код надо собирать на таком же дистрибутиве или как минимум такой же версии glibc и libstdc++ вам, надеюсь, понятно? (нет, это тоже не является абсолютным требованием, но если вы его не выполняете, то это создает пачку проблем, которые тем или иным способом нужно решать).
Так вот, если вы будете собирать код для сервера на базе RHEL7, например, то даже на другой машине стандартным gcc или clang - regexp все равно не заработает. Чтобы заработало, надо, к примеру, собирать свежим gcc с более свежим libstdc++ и тащить его рядом с приложением. Это, опять же, возможно; но *в жизни* такое себе может позволить очень небольшой процент софта. В стандартной репе Red Hat или даже каком-нибудь EPEL такого софта не будет. И поэтому по факту люди просто возмут boost.regex, например.
C++11 с regexp не распоследний и реализуется это не рантаймом, а заголовками с исходниками.
Возможно, но заголовки с исходниками (те libstdc++-devel) настолько же старые, насколько и gcc.
Я все равно вас не понял. G++, Clang++, MSVC поддерживают. Что еще нужно?
> Я все равно вас не понял. G++, Clang++, MSVC поддерживают. Что еще
> нужно?Возьмите виртуалку с RHEL6/7 и скопимпилируете ваш код с помощью штатных g++ или clang и сразу все поймете. Если лень ставить, можно в AWS взять free tier с RHEL.
Версии компиляторов, которые это поддерживают - да, они вообще говоря существуют. Но чтобы это заработало на сервере, вам придется тащить туда свежий компилятор и рантайм. И в стандартные репы ваш такой пакет никто не включит.
> компиляторов и libstdc++ с поддержкой этих стандартов в продакшене вы не встретитеКакой-то у вас замшелый продакшн. Поддержка regex появилась в gcc 4.9, который вышел в 2015.
В 2014-м
И все же, подобные штуки стоило писать на системном языке, а не пайтоне.
В linux'е пайтон системный язык. Для венды он инороден, в линуксах же последние лет 15-20 он системный. Используется не реже чем bash.А вообще, чем языком молоть, если не согласен, возьми и напиши.
> в линуксах же последние лет 15-20Как будешь объяснять что у меня его нету? При этом полноценный десктоп на C, C++, Qt.
И что это за дистрибутив, если не секрет?
Арч 'я у мамы конструктор'.Питона у него нет для того чтобы писать в интернете что у него нет питона.
И сабж ему не нужен принципиально.
> Питона у него нет для того чтобы писать в интернете что у
> него нет питона.У меня на половине дебианов тоже питона нет. Потому что тормозное глюкавое гуано, разваливающееся при каждом втором серьезном апдейте системы и жрущее 25 мегов RSS на отрисовку несчастного значка принтера - лично меня не прет. Конечно есть куда расти, можно значок на электроне переписать, глядишь и до 200 метров догонится, конечно.
>Как будешь объяснять что у меня его нету?Могу только предположить, что у тебя не Gentoo.
> В linux'е пайтон системный язык.Какой он на... системный? Это язык скриптомакак, типа тех которые на васике в 80 програмили. Для работы системы это гуидогуано даром не упало.
> Если посмотреть на код
> нужных компиляторов в продакшене вы не встретитеЕсли посмотреть на код, тотпонятно, что это наколеннная утилита написаная абы как за кружкой пива. Что ей делать в подакшене?
Кто бы про продакшон говорил, но не маководы.
> даже регэкспов нетВообще-то есть. И с помощью stl можно сделать всё, было бы желание. Для такого простого проекта stl хватило бы с головой.
> А код чуть менее чем полностью состоит из парзинга всякого разного в /proc, /sys и иже с ними
Пфф. Я простейший их парсер в 10 строк на чистом C++ писал без всяких регексп.
> небезопасных операций с указателями и прочего
В C++ это и не нужно будет. А насчёт того что питон (то есть сам интерпретатор, который ещё и компилировать в нативный код может, duh) не имеет уязвимостей насмешил, конечно. Глянь как-нибудь в их багтрекер.
>> даже регэкспов нет (я знаю, что в распоследнем стандарте теоретически есть, но компиляторов и libstdc++ с поддержкой этих стандартов в продакшене вы не встретитеКакая махровая чушь. GCC поддерживает C++11 уже около 7-ми лет точно (c 4.3.x если не ошибаюсь). Что у вас за продакшн такой ?
>>> даже регэкспов нет (я знаю, что в распоследнем стандарте теоретически есть, но компиляторов и 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.
Монстр boost ради regex это одна маленькая библиотека, которая линкуется статически
> Монстр boost ради regex это одна маленькая библиотека, которая линкуется статическиНу, некоторым не нравится, что это доступно только в составе 150+ МБ комплекта библиотек. Я, в целом, не против; главное с C++11 regexp осторожнее, тк реально очень много где не заработает.
Вот и я думаю, надо было писать на Rust.
О нет, уж лучше Python, хоть маргинальщина. Этого Rust нет в системе у ещё гораздо большего числа пользователей, чем Python.
> О нет, уж лучше Python, хоть маргинальщина. Этого Rust нет в системе
> у ещё гораздо большего числа пользователей, чем Python.А он в системе и ненужен для запуска, это же не Python :) Rust же компилируемый, будет просто бинарик.
На e2k mike@ уже завез Rust? Нет и не будет в ближайшее время.
А чем он плох? Простой и очень удобный язык. Или ты хочешь, чтобы у демона, предотвращающего нехватку ОЗУ, постоянно текло это самое ОЗУ?
> Почему питон то? Если так хочется удобства (т.е. не C), то плюсцов бы хватило.В такой штуке объективно достаточно гольного си с libc в зависимостях. Ну это если не халтурить. Заодно так минимум мест где она вообще может обломаться. Что для программы занимающейся сабжем наверное аргумент. Потому что если многомеговый интерпретер бидона повиснет где-то в недрах по причине того что у него не удался какой-то malloc, то что это не скрипт лопухнулся а рантайм - это будет довольно слабое утешение.
Но, понятное дело что питонисты о таких интимных особенностях системного программирования - как свиньи об апельсинах.
Эта тулза мне нужна.29 выпуск федоры течёт не отображает какой процесс не освобождает память.
Возьмите lavaps :)
earlyloom, nohang, oomd (https://www.opennet.me/opennews/art.shtml?num=48994)
Астрологи объявили полугодие юзерспейсных заменителей ООМ?Интересно, мне одному такая формулировка режет глаз?
> Предохранение от убийства невинных процессов … возможное массовое убийство процессовВместо:
> "Предохранения от принудительного завершения непричастных процессов … возможное массовое завершение процессов"
>
Предлагаю следующую:
Предотвращение геноцида процессов не замеченных в причастности к жадности памяти и излишней геперактивности в дисковом пространстве.
People for ethical treatment of digital entities. Stop killing them!
Все это похоже на жуткие костыли.
По-моему в FSF киллеров объявили вне закона, и вот опять...
Прочитал заголовок---^^, подумал "новая игрушка поттера". Ан нет.> Астрологи объявили полугодие юзерспейсных заменителей ООМ?
//Ага. Про это уже пошутили, надо держаться. Держаться.
а для докера эта тулза имеет смысл? вот с oom падает контейнер, какой профит предоставляет данная утилита, не вижу рабочей ситуации.
такой, что контейнер будет перезапущен не тогда, когда памяти уже нет, почти все страницы с кодом выгружены на диск, а отзывчивость системы потеряна, а когда сильно плохо еще не стало, и деградация отзывчивости не будет существенной
Почему на python, а не на nodejs?
в node.js был npm leftpad, а пихон это "искуственный дата майнинк дип лёрнинк бик дата интелект" с нескучным синтаксисом
Это сарказм?
Радуйся, что не на Electron.
Зачем мелочиться, надо сразу на electron.
заменить python на electron ещё ни кто не успел предложить?
Походу линю нужен особый сигнал OOM, сообщающий процессу, что если он сейчас немедленно не освободит память, то его прибьют. Всё лишь бы баг 12309 не фиксить.
За...ли вы уже со своим 12309, не смешно уже, придумайте шутку посвежее.
Да, не смешно, потому что сколь бы не говорили о том, что 12309 давно исправлен (раза три уже говорили, что "ну вот теперь точно пофиксили"), он до сих поп проявляется и имеет место быть.
> Да, не смешно, потому что сколь бы не говорили о том, что
> 12309 давно исправлен (раза три уже говорили, что "ну вот теперь
> точно пофиксили"), он до сих поп проявляется и имеет место быть.цитата с лурка: http://lurkmore.to/12309#.D0.9D.D0.B0_.D1.81.D0.B0.D0.BC.D0....
перевожу - виндовз крякнет чавкой с высокой вероятностью и работа виндовзусера закончится "как всегда" - перезапуском мсявого творения
и да - забивать память вской уйней и быдлопрограммами - это в крови виндовзусеров ;)
> Да, не смешно, потому что сколь бы не говорили о том, что
> 12309 давно исправлен (раза три уже говорили, что "ну вот теперь
> точно пофиксили"), он до сих поп проявляется и имеет место быть.До некоторых так за столько лет никак не дойдет что разные тормоза разныз конфигураций, ВНЕЗАПНО могут быть РАЗНЫМИ багами, по РАЗНЫМ причинам. Поэтому они как полные дауны (хотя почему "как") требуют починить баг. Который давно починен и закрыт. А написать новый баг, с описанием своей конфиги и проблем - умишка, определенно, не хватает.
...а у разработчиков бага видимо нет. Иначе они бы давно его прихлопнули. Кстати как-то так разрабатывают вообще любой софт. Фиксинг багов в винде ничем особо не отличается, кроме того что вас подинамят через 5 линий саппорта рассказывающих про то что мышку надо почистить и своп дефрагментнуть. А если у вас что-то не то, доказывать этим ботам что либо задолбаетесь. А когда через год сношений они наконец переведут вас на настоящих разработчиков, окажется что починить это в вашей винде - нельзя. Но, может быть, в следующей версии, через пару годков и починим, конечно. Такая интересная награда за такую долботню получается. Это кстати реально виденный пример из жизни, на примере большущей корпорации. И если так можно динамить даже их - то уж домашним юзером можно и вовсе подтереться, плюс-минус 1 юзерь по сравнению с плюс-минус 1 корп клиентом такого масштаба вообще ни о чем.
> До некоторых так за столько лет никак не дойдет что разные тормоза
> разныз конфигураций, ВНЕЗАПНО могут быть РАЗНЫМИ багами, по РАЗНЫМ причинам.До некоторых за столько лет никак не дойдет, что 12309 давно стало собирательным обозначением.
Тогда почему вы пишите комментарии в интернете, а не фиксите баг
И процесс, получив такой сигнал, начинает лихорадочно шариться по своему адресному пространству выискивая что бы такого освободить, тем самым только увеличивая интенсивность пейджинга.
Bug 12309 - Status: CLOSED CODE_FIX ;)
Зачем оно? kernel oom handler'а мало?
Вроде неоднократно везде писали, что он слишком слоупочный и ненастраиваемый.
Что значит ненастраиваемый? Есть oom_adj, есть memory cgroups.
> Вроде неоднократно везде писали, что он слишком слоупочныйЕсли своп убрать нафиг или перенести в zram (эмулировать оперативку винчом слоупочно хоть там как) - более-менее нормальный становится. Хрустеть будет разве что на paging бинарников на диске, но это относительно немного. А на SSD так никто и не заметит, там быстро. Так что система тупанет несколько секунд да грохнет offender'а. Чаще всего по делу при том. А вес таки настраивается. И если кто ценный, можно настроить ему вес пониже и его постараются не убивать, кроме совсем уж ж@пных ситуаций.
Ну и написать такой тул на питоне - это просто глум над здравым смыслом.
Глянул.
Какой-то трэш и каша.
Комментарии и сообщения в перемешку на английском и на русском.
Весь код свален в одну кучу:
https://github.com/hakavlad/nohang/blob/master/nohang
И да, ни одного теста не увидел.
Пожалуй, я бы побоялся такое запускать, даже если бы оно мне было нужно.Но справедливости ради хочу похвалить за старание.
Надеюсь, следующие проекты будут отличаться в лучшую сторону.
Ну если ты не понимаешь что-то это не значит что написано плохо. Писать юникс-демоны - задача сложная. Код сложный потому что тема сложная.Linux, nohang, X.Org Server... у всех этих наших проектов высок порог вхождения, мы пишем системные вещи.
Код там не сложный, но его качество оставляет желать лучшего.
> Весь код свален в одну кучу:Там всего 1.5k строк, включая комменты и пустые строки, кои по моему в коде используются излишне часто. Если бы там было 5-10k можно было бы поныть, что слишком много в одном файле, а так...
Это уже очень много. Есть принцип единой ответственности, который явно нарушается.
> Это уже очень много. Есть принцип единой ответственности, который явно нарушается.Знаешь, прежде чем сувать эти принципы куда-нибудь, надо посмотреть насколько они применимы. Я бы рекомендовал тебе открыть учебник снова, и перечитать его _внимательно_, обращая особое внимание на границы применимости принципов и на то, какие проблемы эти принципы призваны решать, и соответственно когда следование этим принципам осмысленно. То есть, я понимаю, что для сдачи экзамена ты заучивал наизусть названия и формулировки принципа. Но в реальной жизни, важнее границы применимости, чем названия.
># found experimentally
>zram_disksize_factor = 0.0042Магические константы, забытые комменатрии, отсутствие какой-либо структуры. Код требует шлифовки.
Вообще его бы переписать на Go, работал бы быстрее и память меньше кушал.
Считаю текущий вариант прототипом и в продакшене такое бы использовать не стал.
Советую Алексею привести код в порядок, добавить тесты и бенчмарки.
>># found experimentally
>>zram_disksize_factor = 0.0042
> Магические константы, забытые комменатрии, отсутствие какой-либо структуры. Код требует
> шлифовки.Я к любому коду могу придраться, и сказать ой, фу, тут не то, а здесь не так. К любому. Но я, в отличие от некоторых, не склонен хвастаться этим, я не считаю это сколь-нибудь значимым свойством моей личности.
> Вообще его бы переписать на Go, работал бы быстрее и память меньше
> кушал.Перепиши, тебе никто не мешает.
> Считаю текущий вариант прототипом и в продакшене такое бы использовать не стал.
Чтобы заиметь такое весомое мнение вовсе не обязательно было читать код, достаточно было заголовка новости, в нём чётко указано, что версия софтины 0.1.
> Советую Алексею привести код в порядок, добавить тесты и бенчмарки.
Надеюсь, что Алексей пошлёт тебя с твоими советами по известному адресу. Я всегда подобных советчиков посылаю, следуя заветам Торвальдса: либо код на бочку, либо засуньте свои советы себе туда, куда солнышко не заглядывает. Слишком уж много советчиков развелось в интернете.
> в нём чётко указано, что версия софтины 0.1.это много или мало?
если там было бы написано что версия софтины 345.0 (а не 0.1) -- это говорило бы о чём-то другом?
>> в нём чётко указано, что версия софтины 0.1.
> это много или мало?
> если там было бы написано что версия софтины 345.0 (а не 0.1)
> -- это говорило бы о чём-то другом?Да.
Это такой способ сделать тег. Поставил первый попавшийся тег, v0.1 показался нормальным.
Человек знакомый с версионированием сделал бы 0.0.1-alpha.
Т.к. это самая настоящая альфа.
> Это такой способ сделать тег. Поставил первый попавшийся тег, v0.1 показался нормальным.
> Человек знакомый с версионированием сделал бы 0.0.1-alpha.
> Т.к. это самая настоящая альфа.Бла-бла-бла. Ещё один начитавшийся учебников.
Как много тебе известно примеров программ, которые бы стояли в продакшне с версией меньше чем 0.5? Вот совершенно не важно, какой схемы версионирования придерживаются разработчики, лишь бы версия была бы меньше, чем 0.5, и стояла бы в продакшне.
Я не понимаю о чём спор? О том, что номер версии не несёт никакой информации? Если так, то вы ничего не понимаете в информации. Открой Thinking Bayes (в гугле находится легко), и найдите там задачку про номер поезда. Суть её в следующем: мы, проходя мимо ж/д путей, увидели локомотив принадлежащий компании X, на этом локомотиве был порядковый номер, допустим, 37. Вопрос: сколько всего локомотивов у компании X? Если тебе кажется, что самый точный ответ на этот вопрос "не меньше 37", то я повторю свой совет: открой Thinking Bayes и почитай, причём в этом случае лучше сначала и до конца. А прочитав, осознай, что голова человека всегда thinking bayes, просто в большинстве случаев не используя формул, распределений вероятностей и python'а, а на голом автоматизме, нейроны в голове сплетены таким образом. Школьное образование и в первую очередь школьная математика внушают нам что всё это туфта, и логика -- единственный вид мышления, в реальности же логика вообще не мышление, а лишь "unit-testing" для мышления, с ограниченной сферой применимости. В реальности мозги работают не так, как представляли себе древние греки.
https://greenteapress.com/wp/think-bayes/ если про эту книгу - то название несколько другое ;)
> Бла-бла-бла. Ещё один начитавшийся учебников.Пора кому-то повзрослеть. Учебники написаны на основе реального опыта других людей.
Они написаны людьми, которые давно прошли стадию "совершенно не важно, какой схемы версионирования придерживаются разработчики, лишь бы версия была бы меньше, чем 0.5, и стояла бы в продакшне", наломали дров и набили шишек, поняли, что они делали не так и постарались закрепить это в форме учебников.
Да, современное поколение любит х**к-х**к и в продакшен и пофиг что там. Большинство из таких не задерживается на работе больше года и прыгает на другую "галеру".
А потом за ними приходят люди, которые делают все по учебнику. Делают долго и занудно, после чего все "просто работает". Обычно после этих "школяров" разного рода OOMKillers не требуются. У них память не течет, поскольку все сделано по учебнику, и системы масштабируются автоматически, поскольку опять же все сделано по учебнику.
Вобщем, я не заинтересован в продолжении этой дискуссии. Вам нужен опыт. Получите его, начнете меня понимать.
>> Бла-бла-бла. Ещё один начитавшийся учебников.
> Пора кому-то повзрослеть.Да, несомненно.
> Учебники написаны на основе реального опыта других людей.
Но учебник -- это не опыт. Даже если это хороший учебник, то чтение его не заменяет опыта. Учебник, да и вообще всякие образовательные курсы, в том числе и в/о из вуза -- это лишь база, фундамент на котором можно строить свой опыт. Сам по себе фундамент без опыта бесполезен. И таймлайн примерно такой: человек читает учебники в вузе, после этого он приходит работать. Года три он работает следуя принципам из учебников, и после этого он становится хорошим специалистом. А после этого, _некоторые_ могут пойти дальше, поняв что _любой_ абсолютно принцип, и не только в программировании, _любой_ абсолютно теоретический закон имеет границы применимости. Что любая теория имеет границы применимости, и что, по-хорошему, начинать изучать любую теорию следует с изучения границ применимости. И если человек, заявляющий, что он знает какой-то принцип, не может сходу привести примеров ситуации, когда этот принцип неприменим, то этот человек не знает этого принципа.
> Они написаны людьми, которые давно прошли стадию "совершенно не важно, какой схемы
> версионирования придерживаются разработчики, лишь бы версия была бы меньше, чем 0.5,
> и стояла бы в продакшне", наломали дров и набили шишек, поняли,
> что они делали не так и постарались закрепить это в форме
> учебников.То есть примера ты привести не можешь? Будешь разводить демагогию, вставать в красивую позу "я владею сакральным знанием недоступным посвящённым, поэтому даже обосновывать слов своих не буду, и не заинтересован в продолжении дискуссии", и вообще всячески пытаться свалить из дискуссии с видом победителя? Ну-ну. Продолжай в том же духе.
Торвальдс уже давно не тот: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... ;-)
> Торвальдс уже давно не тот: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
> ;-)Вот к чему ты это сказал? Во-первых, не то чтоб давно, во-вторых, мне-то что? Если Торвальдс принимает Code of Conduct, меня это разве к чему-то обязывает? Или заветы Торвальдса перестали быть заветами Торвальдса?
> Если Торвальдс принимает Code of Conduct, меня это разве к чему-то обязывает?нет, если ты не собираешься присылать ему патчи. Если патч, исправляющий критическую ошибку в ядре, будет содержать коммент вида "афтар - макака, убейте его кто-нибудь", его могут выкинуть и забить на исправления.
Но потреблятелей эта проблема, действительно, не должна беспокоить, вы ведь никаких патчей никому не присылаете?
Ты о чём вообще, родный? Ты тред читал? Я сказал о том, что я следую завету Торвальдса: либо код на бочку, либо до свидания. При чём здесь потребляти, отправление патчей _торвальдсу_, маты в комментах и CoC? Твоя больная тема? Увидев её упоминание никак не можешь сдержаться и не высказаться? Против этого я могу предложить копинг стратегию: купи подушку, и каждый раз столкнувшись с упоминанием этой темы, кричи в подушку, пока не отпустит. Подушка заглушит звуки, и соседи тебя не убьют тогда за нарушение тишины и спокойствия.
Коллеги, прям озадачили.
> Ты о чём вообще, родный? Ты тред читал? Я сказал о том,
> что я следую завету Торвальдса: либо код на бочку,ты топ-топ менеджер линукса или сравнимого по размеру проекта? (Санитары! Этого в палату к Наполеону и Цезарю) Нет? Тогда какой тебе код, кто его тебе понесет?
А если ты свой код на _чужую_ бочку - то вот теперь привыкай правильно именовать в нем переменные, без расовой дискриминации, и правильно комментировать, не оскорбляя альтернативно-одаренных.
Иначе его просто выбросят в помойку не читая, а тебя зобанят.
Если код из одной строчки и занял пол-часа на ее поиск - то, конечно, вполне можно соблюсти. А потом удивляемся, чего это независимых коммитеров даже в ядро, где полно совсем простых и тривиальных мест, полтора процента, остальные - корпорации.
>> Ты о чём вообще, родный? Ты тред читал? Я сказал о том,
>> что я следую завету Торвальдса: либо код на бочку,
> ты топ-топ менеджер линукса или сравнимого по размеру проекта?Нет, но и тем не менее я советую даже разработчикам небольших и даже прям скажем маленьких проектов типа NoHang поступать также. Советчиков посылать далеко и надолго.
> Тогда какой тебе код, кто его тебе понесет?
Не знаю кто, но советы точно не нужны.
> А если ты свой код на _чужую_ бочку - то вот теперь
> привыкай правильно именовать в нем переменные, без расовой дискриминации, и правильно
> комментировать, не оскорбляя альтернативно-одаренных.Ты тупой? Простите за мой французский, вырвалось. Речь идёт о советчиках и коде. Советчиков надо посылать, с теми же кто принёс код можно работать. При чём здесь "правильно именовать переменные", "расовая дискриминация", "правильные комментарии", "оскорбление альтернативно-одарённых"? Я ещё раз повторю совет, чтобы справится с эмоциями при столкновении с болезненной для тебя темы, возьми подушку и прокричись в неё. И да, другой совет тоже повторю: перечитай тред.
>zram_disksize_factor = 0.0042Описание есть в начале файла.
>забытые комменатрии
Где?
>отсутствие какой-либо структуры
Структура есть, код разделен на разделы, разделенные строками ############################, и разделы прокомментированы.
>Вообще его бы переписать на Go, работал бы быстрее и память меньше кушал.
Уже. Старт дан. https://github.com/hakavlad/nofreeze
>Считаю текущий вариант прототипом
как вам угодно. Тем не менее, прототип прекрасно работает.
Вот целый кусок забытых комментариев
https://github.com/hakavlad/nohang/blob/master/nohang#L934Я не хочу придираться к деталям. Просто бросилось в глаза.
У вас хорошая идея, продолжайте ее развивать.
Это прям свежий коммит, не от автора. Будет почищено вскоре. Ничего не забыто.
Говнокод ещё тот# НА МЕСТЕ!!!
if 'swap_min_warnings' in config_dict:
swap_min_warnings = config_dict['swap_min_warnings']
Что Вас смутило в этом участке кода?
> Что Вас смутило в этом участке кода?Ну вот меня например такой комент в коде смущает. Видя такое я как-то сразу прикидываю что и остальное каКчество кода оправдает самые смелые ожидания.
> Комментарии и сообщения в перемешку на английском и на русском.Это ты еще код bitmessage читать не пробовал. Сразу видно - крутой про огреб крутую идею и подумал как же ее реализовать, если прогать не умеешь? Ну увидел бэйсик или что там вместо него теперь и накодил как умел. Заодно и програмить поучился как раз.
О том что проект надо майнтайнить, в входных данных может быть левак, а огроменный рантайм писаный как курица лапой неважно годится для системного програмизма - такому гению от софтостроя никто никогда не рассказывал конечно. Поэтому он презрительно смотрит на остальных - весь мир у его ног, падите ниц, жалкие червяки! Ведь этот голимый погонщик слонов наконец чего-то смог. Правда, как слон устроен он понятия не имеет, да и повадки он знает лишь целых 5 минут. Так что если слон вдруг взбрыкнет, плюс-минус пара раздавленых зрителей сущая фигня.
Решение несуществующей проблемы.
Намного логичнее выставить лимиты памяти в cgroups тем процессам, которые ее могут схавать. Да, браузеру.
>Решение несуществующей проблемы.Проблема есть, look at https://www.reddit.com/r/linux/comments/56r4xj/why_are_low_m.../
>Намного логичнее выставить лимиты памяти в cgroups тем процессам, которые ее могут схавать. Да, браузеру.
Nohang ни к чему вас не обязывает. Делайте так, как считаете нужным.
Это не проблема, а вопрос неопытного пользователя.
На который ему ответили. В том числе указав, что если есть предположения о том, что потребуется завершать в первую очередь, то можно предупредить проблему с помощью cgroups.Да, ситуация нехватки памяти в принципе не может быть обработана приемлемо. Если бы это было вдруг возможно, мы бы могли обходиться меньшим количеством памяти.
OOM - это аварийная процедура, цель которой сохранить работоспособность ядра. Она не должна быть комфортной для приложений в юзерспейсе. Нужно так конфигурировать систему, чтобы память не заполнялась полностью. Для этого нужно быть инженером, а не макакой. Но это уже оффтопик.
*лицоладонь*можно настроить и vm-подсистему так, чтобы не загонялась до неюзабельного состояния. а если памяти не хватает, то конечно какие-то приложения будут прибиваться, этого не избежать. главное, что это не будет мешать работоспособности остальных приложений
и будет эпично, если сам этот nohang подвесит систему))
> а если памяти не хватает, то конечно какие-то приложения будут прибиваться, этого не избежатьпросто некоторые свято верят, что любую проблему можно решить, если прибивать процессы в правильном порядке
>> а если памяти не хватает, то конечно какие-то приложения будут прибиваться, этого не избежать
> просто некоторые свято верят, что любую проблему можно решить, если прибивать процессы
> в правильном порядкеsystemd что ли?
я вот только одного вкурить не могу - в чём разница между убитым процессом (из-за ООМ) и процессом который никогда не выполнится (то есть не использовать данное ПО, которое течет)?
Вот уж типично линуксячий подход - создать технологию которая будет килять процессы для освобождения памяти, а потом создать тулзу которая будет мешать этой технологии которая киляет процессы для освобождения памяти.Если процесс стал потреблять ОЗУ - он это сделал не зря, значит ему так нужно. Что будет если mysqld с криво настроенным innodb_buffer_pool_size получит SIGTERM? Он резко выгрузит все таблицы, кэши и тд ? Сомневаюсь. А значит получит SIGKILL и будет то же самое что и просто с OOM но при этом на серваке не будет стоять левое пихоновое поделие. А раз так, то зачем ставить это на сервер ?
Короче что только не придумают, лишь бы не сделать
fallocate -l 2G /anti_oom;mkswap /anti_oom;swapon /anti_oom
> Короче что только не придумают, лишь бы не сделатьfallocate -l 2G /anti_oom;mkswap /anti_oom;swapon /anti_oom
Когда упрётесь в производительность например SAN - поймёте, почему не надо так делать.
Впрочем, это не отменяет того, что ядрёного механизма OOM вкупе с cgroups для контроля за oom-ситуациями более, чем достаточно.
> Когда упрётесь в производительность например SANПереполнение памяти обычно бывает по двум причинам:
1. Владелец железки криворукий олень и установил несовместимое количество софта\железного ОЗУ на девайс. Ну например купил ВПСку шоб подешевше, с гигабайтом мозгов, и заставил ее обрабатывать веб на 1000 коннектов в секунду и на apache. Тогда его своп ДОЛЖЕН юзаться активно, и все это рано или поздно упрется в производительность. То же самое можно сделать на дорогом оборудовании, просто в других масштабах, суть не изменится.
2. Случайный всплеск. Ну вот поставили вы гигабайт ОЗУ на вашу ВПСку, все настроили тоненько тоненько, отлично работает, но раз в неделю ваш плагин на Вордпрессе делает бэкап, и тогда нужны дополнительные пару мегабайт ОЗУ на час.
В первом случае владелец железки сам себе злобный буратино, и его не спасут никакие Nohang'и даже свопы: ему надо либо умерять аппетит софта к железу, либо апгрейдить железо к аппетиту софта.
Во втором случае никакой просадки скорости не будет, пушо своп будет временной мерой для непродолжительной операции.
1) да
2) см. п.1
За исключением свопа в п.1 - как только скрипт у хостера заметит аномальную дисковую активность от непрерывно юзаемого свопа, он сразу же нерегламентированный IOPS порежет.
Понимаете ли, на линуксе совершенно отвратительные механизмы управления памятью. И если будет своп, то если ты откроешь firefox, а в нём девтулзы, то выльется это в то, что сначала выжрется вся оператива, а потом вместо оперативы система начнёт юзать своп и всё встанет колом. А всё из-за того, что часть памяти должна быть зарезервирована и не свопиться никогда. Память ядра и ядерных модулей никогда не должна свопится, иначе оно будет лагать, а с ним и всё остальное, причём запросы будут копиться, и придётся делать резет. Память дисплейного сервера никогда не должна свопиться, иначе будут проблемы с управлением. Память оконного менеджера никогда не должна свопиться по тем же причинам, а ещё надо писать нормальные оконные менеджеры, легковесные и с аппаратным курсором, а не то говно, что сейчас. Память юзерспейс программ может свопиться, но не агррессивно, память должна делиться на "горячую" и "холодную" и свопить можно только холодную.Просто разрабы зажрались на проспонсированных корпорациями машинах. А надо бы им поработать на 1м гиге.
Ну да, ну да. LGBT-шники из MoFo жрут память тоннами, а виноват линукс. И пишет нам об этом многолетний хакер ядёр и VM-ов, не иначе.
Firefox так себя ведет не важно под какой ОС. Из всех браузеров включая Edge. Именно Firefox сейчас жрет больше всего ОЗУ и нагружает CPU ради пресвятого JS.Самый банальный пример: https://www.twitch.tv/videos/340281255?t=36m20s
Как уже заметили,жрёт на всех ОС, а колом всё встаёт шт этого только на Лине.
> Как уже соврали,жрёт на всех ОС, а колом всё встаёт шт этого только на Лине.fixed
Чем-то же нужно мотивировать продажу 32+гб ноутбуков.
Поделия JetBrains на виртуалке с 4гб озу уже моментально пишут в swap после открытия Hello World.
IDE под JVM лучше вообще не использовать.
> Если процесс стал потреблять ОЗУ - он это сделал не зря, значит
> ему так нужно. Что будет если mysqld с криво настроенным innodb_buffer_pool_size
> получит SIGTERM? Он резко выгрузит все таблицы, кэши и тд ?А что будет, если ядру потребуется память и оно не сможет ее себе выкроить, сэр не подумал? Конечно офигенно что пошедший вразнос мускуль выживет, но что он будет делать если умерло уже ядро, которое себе под свои нужды память выкраивать не смогло? :)
Если вдруг интересно как это выглядит: берешь роутер мыльницу, у половины из них conntrack, который структуры ядра настроен неверно и может стрескать больше памяти чем реально запаяно. Пускаешь торенты в много потоков. Смотришь что случается с ядром и всем остальным, когда с памятью душно, но забрать нельзя, потому что ее жрут структуры ядра (conntrack, не обеспеченный фактической памятью в сконфигуреном объеме). Хочешь такое же на десктопе? :) Точно? :)
Какой дурдом. Пишем watchdog для контроля потребления ресурса на языке который сам любит пожрать этого ресурса. Напоминает государственную систему управления - нужно больше чиновников контролирующих потребление государственных средств!Что только не сделают что бы cgroups + cgrulesengd не изучать...
PS
ps -C cgrulesengd -o rss
RSS
1712
А летом было вот это: https://www.opennet.me/opennews/art.shtml?num=48994 от фейсбука =)
Такое вот хреновое лето... (с)
>> Демон написан на языке Python, потребляет около 10 MiB VmRSS и настраивается с помощью файла конфигурации (/etc/nohang/nohang.conf)Подозреваю если его переписать на C/C++/Go/Rust/whatever он будет занимать 1 Мб памяти максимум?
Feel free to implement?
Больше. Earlyoom на C занимает 2 МБ.
>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.
> Больше. Earlyoom на C занимает 2 МБ.У питона один только интерпретатор нынче занимает заметно больше. Это при том что программу вообще выполнять не начали даже. А ей тоже что-то надо. Хотя питонисты конечно же цифры мастерски подгоняют - но системные штуки интересны тем что там если кого-то и можно на...ть то разве что самого себя.
Если его переписать на С, то, думаю, он будет занимать не более сотни килобайт.У Rust бинарник, призванный анализировать лог почтового сервера и собранный с ключом --release занимает на диске порядка 400 Кб, а если собрать отладочную версию, то порядка 1.3Мб. При этом дебажная версия обрабатывает 500 Мб mail.log примерно за 2 минуты, а релизная примерно за 10 секунд. Я хз, как им удалось так затормозить дебажную версию, до этого ни в одном языке таких тормозов не было. И это не ошибка в алгоритме, это именно тормоза кода, так как --release работает быстро.
У Go бинарник на диске весит порядка 2Мб, если сделать ему strip, то от несколько худеет, но при этом это статическая версия, не имеющая никаких зависимостей.
Издевательство. Могу на Голанг сиатически слинкованный бинарник запилить и весить будет мегабайт
Кстати, https://github.com/hakavlad/nofreeze
> Кстати, https://github.com/hakavlad/nofreeze
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--
}
мощно!
Вот ведь как бывает: один аноним не поленился заглянуть в г-нокод, а другие заберут в продакшын. Программа как раз на должном уровне. :)yoba, yoba, yoba!
Очень хорошая и нужная вещь!!! Совместно с ulatencyd можно выжать максимум с компа!!!
Вместо того, чтобы расширить функционал ООМ, запилили ненужную прослойку. Всегда так. Вместо того, чтобы обновить ifconfig - объявили ее deprecated и написали сразу веер новых фуфлокоманд.
Linux-way как он есть
> Вместо того, чтобы расширить функционал ООМ, запилили ненужную прослойку. Всегда так. Вместо
> того, чтобы обновить ifconfig - объявили ее deprecated и написали сразу
> веер новых фуфлокоманд.
> Linux-way как он естьУ вас какой-то баттхерт личного характера на тему устаревания ifconfig? Е-мае, больше 15 лет как iproute2 в ядре а ifconfig не более чем обертка, он раньше 2000 года появился точно. Где-то с ядра 2.2 еще. Можно было за этот срок и научиться пользоватся ip, не?
А по поводу linux-way - ну тут решили так, а что такого? Все равно стандарта никакого на ifconfig/route нет. Их синтаксис в линуксе, фряхе и солярисе разный, возможности тоже разные.
> Все равно стандарта никакого на ifconfig/route нет. Их синтаксис в линуксе,
> фряхе и солярисе разный, возможности тоже разные.то есть собственно, ровно до того места, где они одинаковые - кривой враппер, который еще в 2000м грозились выкинуть, эту самую совместимость вполне обеспечивает. Ну вдруг забрел админ bsd386 из криокамеры, и ему к ней непременно надо по ip подключиться, чтоб обратно залезть - на это хватит и его умений и того ifconfig.
(на самом деле там не так все солнечно - это два разных ядерных интерфейса, первый тоже для совместимости, используется, но крайне редко по делу, а второй теоретически может быть не вкомпилен в ядро)