Здравствуйте, ononim, Вы писали:
O>Что касается проблемы с недостатком памяти, то небольшой ликбез — в винде есть тулзы, т.н. driver verifier и app verifier. То есть, в винде драйвера все тестируются на работу в условиях когда произвольный ExAllocatePool зафэйлится. Есть ли такое в линуксе?
Ну в линуксе есть ltptest, который в том числе тестирует outofmemory, и много других тестов. Конкретно с багом фриза при нехватке памяти я сам сталкивался пару раз на десктопе ubuntu. При желании можно исправить на разными способами, если это нужно, в том числе опциями sysctl или другими oom-killer пакетами, без патчей ядра. Если тебе это мешает, разбирайся, ищи конечную причину и исправляй. Либо плати микрософту, если сам не умеешь или не хочешь.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Masterspline, Вы писали:
M>Я про "рабочиЕ столы" (множественное число). Зачем ты делаешь вид, что не понимаешь, о чем я? У меня они называются "Virtual Desktops", как их называют в винде не в курсе. Стратегия докопаться до второстепенной херни и делать умный вид — классика жанра балабола.
РабочиЕ столы — это не то же самое, что виртуальные рабочие столы, которые вообще никакого отношения к созданию яплыков не имеют. Ты всё время уходишь от проблемы в обсуждение своих частных вопросов, которые к теме топика не имеют отношения. По делу не сказано же ни слова. KDE, Chrome, отслеживание потребления памяти — это всё не имеет отношения к тому, что дефолтный десктоп на многих дистрибувах просто зависает надолго (или навсегда) при нехватке памяти. Скажи хоть что-то по делу и никто не будет докапываться. "У меня всё работает" — это не по делу.
M>>А, ну я именно такое и описывал. Немощный ноут, мало памяти, компилируем что-то... До сих пор не понимаю, зачем программисты используют ноут для комиляции (мало памяти, мало ядер, ядра слабые)
N>Это говорит лишь об ограниченности твоего опыта. Не все программисты сидят за столом с мощным системником и кучей мониторов. Иногда приходится работать с тем, что есть и там, где придётся.
Десктоп раза в 2 дешевле ноута, раза в 2 быстрее, оперативки в 2 раза больше (и она тоже быстрее) и раз в 100 надежнее. Скорость работы проца и памяти, а также количество ядер и размер памяти — именно те параметры, которые ускоряют компиляцию. А теперь давай ты оценишь, соотношение разработчиков, которые используют ноут для разработки потому что хочется и тех, кому по-другому никак (причем раз в год съездить на конференцию или в командировку не канают за "никак").
И еще я хочу услышать пример, когда приходится РАБОТАТЬ "с тем, что есть и там, где придётся".
M>>С похожим я сталкивался на слабом десктопе, когда при компиляции не хватало памяти (линковщик чего-то большого типа Chromium работает долго и жрет память и в какой-то момент линковщики из разных потоков начинают работать одновременно и уходят в swap). Но у меня система не зависала, а тормозила. При этом срабатывал и Ctrl+C и kill из другой вкладки консоли (с тормозами, но без зависания). После чего я уменьшал "-j" и компилировал заново (в любом случае, оно работает долго, поэтому в фоне). Т.е. ситуация довольно просто разрешалась.
N>Да, ситуация разрешалась, но она не должна была возникнуть. Никто не говорит, что она неразрешима, плохо, что она в принципе есть. Ну и ты плохо читал: swap не спасает.
Так она и не возникла бы, если бы ты знал, сколько потоков компиляции потянет твой ноут. Про swap вообще не понял. Я говорил, что его нельзя отключать, а не что он спасет. Если система ушла в активный swap — она будет тормозить и ей либо нужно дать памяти (завершив ненужные процессы, chrome, например), либо запустить с меньшей параллельностью.
Здравствуйте, Nuzhny, Вы писали:
N>Это говорит лишь об ограниченности твоего опыта. Не все программисты сидят за столом с мощным системником и кучей мониторов. Иногда приходится работать с тем, что есть и там, где придётся.
В таком случае помогает Remote Desktop. Используешь "что придется", работая при этом с мощным железом.
Здравствуйте, Masterspline, Вы писали:
M>И еще я хочу услышать пример, когда приходится РАБОТАТЬ "с тем, что есть и там, где придётся".
В командировке, в отпуске, на кухне в съёмной квартире, в кафе, в коворкинге. Где угодно, короче. Ноутов у меня дома 4 штуки разных, из-за полукочевого образа жизни последних лет системник неудобен. Таких как я довольного много знаю лично.
M>Так она и не возникла бы, если бы ты знал, сколько потоков компиляции потянет твой ноут. Про swap вообще не понял. Я говорил, что его нельзя отключать, а не что он спасет. Если система ушла в активный swap — она будет тормозить и ей либо нужно дать памяти (завершив ненужные процессы, chrome, например), либо запустить с меньшей параллельностью.
Чтобы узнать, сколько тянет, надо запустить и узнать. Смекалка! Мало какие проекты указывают в документации объём оперативной памяти, потребляемый конкретным компилятором при сборке. Собирал когда-нибудь проекты с большим объёмом шаблонной магии на плюсах? PCL один из таких проектов.
Кроме того, есть проекты, которые могут потреблять память при сборке в зависимости от того, что конкретно ты собираешь. Например, dlib при сборке проекта с нейросетью потребляет память пропорционально сложности нейросети. И пока ты сборку не запустишь, от не узнаешь, сколько там памяти надо.
Мир он большой и разнообразный, случаи бывают всякие.
O>>Что касается проблемы с недостатком памяти, то небольшой ликбез — в винде есть тулзы, т.н. driver verifier и app verifier. То есть, в винде драйвера все тестируются на работу в условиях когда произвольный ExAllocatePool зафэйлится. Есть ли такое в линуксе? lpd>Ну в линуксе есть ltptest, который в том числе тестирует outofmemory, и много других тестов.
"to confirm the behavior of the Linux kernel as well as glibc."
Я так понимаю для гуи никто таких тестов не делает. Потому что ведь если гуй завис, его же всегда можно рестартануть по ssh
lpd>Конкретно с багом фриза при нехватке памяти я сам сталкивался пару раз на десктопе ubuntu. При желании можно исправить на разными способами, если это нужно, в том числе опциями sysctl или другими oom-killer пакетами, без патчей ядра. Если тебе это мешает, разбирайся, ищи конечную причину и исправляй. Либо плати микрософту, если сам не умеешь или не хочешь.
Ну, вот в этом мировосприятии и беда линукса. И счастье, кстати, тоже.
Как много веселых ребят, и все делают велосипед...
M>>Я про "рабочиЕ столы" (множественное число). Зачем ты делаешь вид, что не понимаешь, о чем я? У меня они называются "Virtual Desktops", как их называют в винде не в курсе. Стратегия докопаться до второстепенной херни и делать умный вид — классика жанра балабола.
N>РабочиЕ столы — это не то же самое, что виртуальные рабочие столы
К чему это вообще? И какая между ними разница? И этот человек пишет, что я общаюсь не по делу... Кстати, там я отвечал на конкретные претензии к Ubuntu.
> Ты всё время уходишь от проблемы в обсуждение своих частных вопросов, которые к теме топика не имеют отношения. По делу не сказано же ни слова. KDE, Chrome, отслеживание потребления памяти — это всё не имеет отношения к тому, что дефолтный десктоп на многих дистрибувах просто зависает надолго (или навсегда) при нехватке памяти. Скажи хоть что-то по делу и никто не будет докапываться. "У меня всё работает" — это не по делу.
Давай я перечислю то, что уже сказал:
Используй приличную машину (средний десктоп или дорогущий ноут, если тебе очень нужна мобильность).
Удали из Desktop Environment все, что мешает (жрет память, проц) — это не сложно, 2-3 настройки, которые легко нагуглить (относится как к винде, так и Linux).
Если памяти мало — знай, сколько ее остается с твоими инструментами разработки и сколько потоков компиляции потянет твоя машина. При достаточном количестве памяти это вообще не важно, make -j$CPU_COUNT будет работать как надо (разве что попадется крайняя экзотика с ветвистыми шаблонами или линковкой нескольких chrome параллельно).
Когда возникают сложности (довольно редко) — находи причину (гугл и форумы в помощь).
Нытье на форуме не поможет — тебя никто жалеть не станет, и героем ты не будешь выглядеть, скорее неудачником-неосилятором.
Научишь логиниться в консоль и находить, кто жрет ресурсы (Ctrl+Alt+F1 -> login -> pssword -> ps afxl, top, vmstat, kill). Это на крайний случай, потому что консоль в графике гораздо дольше будет выходить из swap, чем запуск программ без графики (потому что с диска придется считать меньше). vmstat 2 позволит узнать причину тормозов (нехватка памяти -> ативный swap, уперлись в CPU -> (us+sy) равен количеству процессоров * 100%, уперлись в ввод/вывод -> будет большой wa). top и ps afxl покажет какой конкретно процесс тормозит и его PID, kill -9 $PID очистит систему от тормоза).
А теперь расскажи, что из этого не по делу и чего я до этого не говорил (кроме последнего).
А также расскажи причину зависания твоего ноута при активном свапе. Потому что сейчас для меня это выглядит, как ты не разобрался в чем причина и стал во всем винить Linux. Я очень внимательно слушаю новую и полезную для себя информацию и готов признать, где я был не прав. Но я не хочу случать очередную пачку стереотипов от людей, которые не разбираются в вопросе или сказки от велосипедистов, оправдывающих userspace OOM killer.
Впрочем, если ты хочешь, чтобы у тебя ОС сама всегда работала идеально, при этом не хочешь разбираться (даже поверхностно) с настройками DE и этой OS, даже несмотря на то, что ты разрабатываешь под эту самую OS, то мне это не интересно. И не думаю, что какая-то OS тебя спасет (у всех будут недочеты, которые нужно исправлять). И уж точно нытье тут не поможет.
Я не понимаю людей, которые разбираются с фреймворками, настройками компиляторов, IDE, но отказываются вникать в работу и настройку OS и DE под которые разрабатывают soft.
> "У меня всё работает" — это не по делу.
А, ну, да, т.е. если я не допускаю нехватки памяти, а когда у меня система уходит в swap и тормозит, я с этим справляюсь — это "не по делу".
А твои рассказы, что все должно работать само, а когда что-то не работает — во всем Linux виноват. Это, конечно, более конструктивная позиция, исключительно "по делу".
M>>И еще я хочу услышать пример, когда приходится РАБОТАТЬ "с тем, что есть и там, где придётся".
N>В командировке, в отпуске, на кухне в съёмной квартире, в кафе, в коворкинге. Где угодно, короче. Ноутов у меня дома 4 штуки разных, из-за полукочевого образа жизни последних лет системник неудобен. Таких как я довольного много знаю лично.
В командировки, обычно, ездят редко, тут можно завести отдельный ноут, как и для выступления на конференциях. Средний, без излишеств. Однако, сам проект должен лежать на сервере и компиляция делаться удаленно (про такой вариант в Клен я уже писал, IMHO, его специально сделали для разработчиков, которые не могут расстаться с немощным ноутом и плачут, как все медленно работает).
В отпуске работать? Я бы попросил зарплату раза 2 выше. Да и тут подходит вариант "командировка".
На съемной квартире. Это когда в комнате с десктопом кто-то спит? Опять же удаленная разработка на среднем ноуте. Иначе не вижу причин для стационарной машины — при переезде разницы не будет.
В кафе. Ну тут вообще проще дойти до места с удобным столом, стулом, монитором, системником и интернетом по кабелю.
В коворкинге. Ну, да. Хотя опять же вариант с удаленным сервером и средним ноутом.
И главный вопрос, насколько часто это происходит в реальности? И как часто это действительно необходимо? Почему бы не вести разработку за удобным столом, стулом, монитором, системником и проводным интернетом (я не верю в разработку с ноутом сидя в сортире — это неудобно и неэффективно). Мне так никто и не дал убедительных ответов, потому я считаю, что причина — "так хочется".
M>>Так она и не возникла бы, если бы ты знал, сколько потоков компиляции потянет твой ноут. Про swap вообще не понял. Я говорил, что его нельзя отключать, а не что он спасет. Если система ушла в активный swap — она будет тормозить и ей либо нужно дать памяти (завершив ненужные процессы, chrome, например), либо запустить с меньшей параллельностью.
N>Чтобы узнать, сколько тянет, надо запустить и узнать. Смекалка! Мало какие проекты указывают в документации объём оперативной памяти, потребляемый конкретным компилятором при сборке. Собирал когда-нибудь проекты с большим объёмом шаблонной магии на плюсах? PCL один из таких проектов. N>Кроме того, есть проекты, которые могут потреблять память при сборке в зависимости от того, что конкретно ты собираешь. Например, dlib при сборке проекта с нейросетью потребляет память пропорционально сложности нейросети. И пока ты сборку не запустишь, от не узнаешь, сколько там памяти надо. N>Мир он большой и разнообразный, случаи бывают всякие.
Если ты запускаешь компиляцию первый раз или тебе попался неудачный проект, который особо активно жрет память — ты уйдешь в swap. Но это экзотика, произойдет раз в год, ты с ней справишься и пойдешь дальше. В остальных случаях все сборки примерно одинаковы, т.е. ты будешь знать, сколько обычно потоков потянет твоя машина из предыдущего опыта. И как и говорил, это актуально, только при нехватке памяти. Возьми нормальный десткоп и ты с таким вообще не столкнешься. Так что больше похоже на ССЗБ и раскидывание известной субстанции по всем интернетам. Для меня это выглядит так: "Я пользуюсь немощным ноутом, у меня все тормозит, но я все равно им пользуюсь, а иногда уходит в своп и я не знаю, что с этим делать, поэтому иду на форум и рассказываю, какой плохой этот ваш Linux. Грохнуть из консоли я ничего не могу, потому что не умею и вообще, все должно работать само!" Я не против ноутов, я против нытья.
Если у тебя необычная сборка, которая непредсказуемо потребляет память и прошлый опыт тебе не поможет — тут неприятность. Но как я уже сказал, у меня в таких случаях система тормозила, но не вешалась. И пока я не услышу убедительное объяснение, почему она должна повиснуть, я их не воспринимаю всерьез. Особенно от людей, которые с глубиной понимания ситуации "во всем Linux виноват".
P.S. Я тут подумал, что ситуация с "зависанием" может возникнуть, когда запускаешь большую сборку из IDE типа clion. Там сначала IDE уйдет в swap, потом компиляция тоже уйдет в swap и чтобы ее остановить, нужно нажать что-то в IDE. Но IDE довольно большой и из swap он будет доставаться долго, затем долго реагировать на остановку сборки... Я всегда запускал длительные сборки из консоли, а там Ctrl+C отработает (как управление луноходом, но отработает, причем даже из GUI консоли). А kill из консоли (Ctrl+Alt+F1) отработает еще быстрее (разработчик, пользующийся только GUI про это не знает, конечно). Так что, возможно, мне не понять проблем таких разработчиков.
lpd>>Конкретно с багом фриза при нехватке памяти я сам сталкивался пару раз на десктопе ubuntu. При желании можно исправить на разными способами, если это нужно, в том числе опциями sysctl или другими oom-killer пакетами, без патчей ядра. Если тебе это мешает, разбирайся, ищи конечную причину и исправляй. Либо плати микрософту, если сам не умеешь или не хочешь. O>Ну, вот в этом мировосприятии и беда линукса. И счастье, кстати, тоже.
В чем беда, Брат. Расскажи. Если человек сам хочет разобраться и обращается за помощью — ему помогают, даже если он совсем новичок и сам не понимает, что хочет. А если не хочет разбираться — да зачем он такой нужен?
lpd>>>Конкретно с багом фриза при нехватке памяти я сам сталкивался пару раз на десктопе ubuntu. При желании можно исправить на разными способами, если это нужно, в том числе опциями sysctl или другими oom-killer пакетами, без патчей ядра. Если тебе это мешает, разбирайся, ищи конечную причину и исправляй. Либо плати микрософту, если сам не умеешь или не хочешь. O>>Ну, вот в этом мировосприятии и беда линукса. И счастье, кстати, тоже. M>В чем беда, Брат. Расскажи.
Беда в том что можно сделать так чтоб не приходилось разбираться, но не делают. Потому что: M>Если человек сам хочет разобраться и обращается за помощью — ему помогают, даже если он совсем новичок и сам не понимает, что хочет. А если не хочет разбираться — да зачем он такой нужен?
Как много веселых ребят, и все делают велосипед...
N>>Если есть интернет, то да.
Б>Он есть везде. Трудно представить работу программиста без интернета.
Я так понимаю, тут человек описывает широко распространенную ситуацию, когда разработчика отправляют в командировку на секретный военный объект, и он сидя в ракетной шахте без интернета со слабым ноутбуком пересобирает весь проект целиком, потому что протокол запуска стратегических ракет доступен только по месту. При этом нет никакой возможности дойти нормального рабочего места с интернетом. Такое у каждого случается минимум раз в неделю.
O>Беда в том что можно сделать так чтоб не приходилось разбираться, но не делают. Потому что: M>>Если человек сам хочет разобраться и обращается за помощью — ему помогают, даже если он совсем новичок и сам не понимает, что хочет. А если не хочет разбираться — да зачем он такой нужен?
Ну, тут, чтобы не скатываться в пустую болтовню, нужна конкретика. Что за задача, как ее можно решать, почему не решили... Я для себя уже понял, что не сталкиваюсь со многими неприятностями потому что сильно по другому организую работу. Поэтому потребности и боль многих разработчиков для меня неизвестны.
Мне тут вот подумалось, а ведь сборку можно запускать с ограничением по памяти через cgroups. Почему бы недовольным разработчикам, которые тут отметились не выяснить, как это делать. А также есть уже упомянутые userspace OOM killers, специально сделанные для предотвращения активного swap (срабатывают до ядерного OOM).
Или может разработчикам Клён feature request написать... Типа запускать компиляцию в отдельной сессии и ограничивать ее память (например, сделать стартер, который создаст сессию, сконфигурирует ограничение по памяти, запустит make и будет следить за активностью swap, если началось — сильнее ограничивать память для всей сессии).
Кстати. Подобная неприятность уже была, но связана не со swap, а CPU и тогда ее решили. Даже Линус отписался, что-то типа теперь я могу запустить компиляцию ядра и у меня не тормозит отрисовка графики. Тогда можно было вручную создавать сессию и запускать там сборку, а планировщик уже мог правильно распределять CPU между сессиями (когда в одной десятки компиляторов, а в другой единственный браузер и он не тормозит, потому что CPU делится на две сессии, а не на процессы и браузер мог получить до 50% CPU). Затем в ядро внесли патч на несколько строк, чтобы он это делал автоматически без ручной манипуляции с cgroups.
Здравствуйте, Masterspline, Вы писали:
M>Ну, и если тебе так не нравится Linux — иди пользуйся, чем нравится. Без тебя, как пользователя Linux, всем станет только лучше.
Вот это правильный подход, и даже объяснять ничего не нужно, а то только получишь больше бессмысленных вбросов.
O>>Беда в том что можно сделать так чтоб не приходилось разбираться, но не делают. Потому что: M>>>Если человек сам хочет разобраться и обращается за помощью — ему помогают, даже если он совсем новичок и сам не понимает, что хочет. А если не хочет разбираться — да зачем он такой нужен? M>Ну, тут, чтобы не скатываться в пустую болтовню, нужна конкретика. Что за задача, как ее можно решать, почему не решили... Я для себя уже понял, что не сталкиваюсь со многими неприятностями потому что сильно по другому организую работу. Поэтому потребности и боль многих разработчиков для меня неизвестны.
Ну вот тут
Конкретно с багом фриза при нехватке памяти я сам сталкивался пару раз на десктопе ubuntu. При желании можно исправить на разными способами, если это нужно, в том числе опциями sysctl или другими oom-killer пакетами, без патчей ядра. Если тебе это мешает, разбирайся, ищи конечную причину и исправляй. Либо плати микрософту, если сам не умеешь или не хочешь.
То есть он признает что проблема существует, но по его и принятому в сообществе мнению — она не достойна быть решенной на уровне дефолтной инсталляции. И он считает это нормальным.
Как много веселых ребят, и все делают велосипед...
Конкретно с багом фриза при нехватке памяти я сам сталкивался пару раз на десктопе ubuntu. При желании можно исправить на разными способами, если это нужно, в том числе опциями sysctl или другими oom-killer пакетами, без патчей ядра. Если тебе это мешает, разбирайся, ищи конечную причину и исправляй. Либо плати микрософту, если сам не умеешь или не хочешь.
O>То есть он признает что проблема существует, но по его и принятому в сообществе мнению — она не достойна быть решенной на уровне дефолтной инсталляции. И он считает это нормальным.
Не все так безнадежно. Лед тронулся. Теперь не только обычные пользователи смогут решить проблему активного swap, но и квалифицированные программисты, разрабатывающие под эту OS на ноутбуке стоимостью в четверть зарплаты смогут довольно быстро устранить фризы автоматически... Главное, чтобы это можно было отключить, если не нужна такая автоматизация.
Здравствуйте, Masterspline, Вы писали
M>Я про "рабочиЕ столы" (множественное число). Зачем ты делаешь вид, что не понимаешь, о чем я? У меня они называются "Virtual Desktops", как их называют в винде не в курсе. Стратегия докопаться до второстепенной херни и делать умный вид — классика жанра балабола.
Для рабочих столов была desktops от Руссиновича и еще несколько программ. Сама поддержка там была очень давно, просто недавно к ней приделали интерфейс "искаропки".
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, velkin, Вы писали:
M>>Ну, и если тебе так не нравится Linux — иди пользуйся, чем нравится. Без тебя, как пользователя Linux, всем станет только лучше.
V>Вот это правильный подход, и даже объяснять ничего не нужно, а то только получишь больше бессмысленных вбросов.
Почему правильный? В жизни иногда приходится делать что-то неприятное, а вы отказываете в праве при этом пожаловаться.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
