LINUX.ORG.RU

Почему гномощел такой лагучий?

 , , ,


0

1

Сравниваю исключительно с unity7 которая не казалась мне никогда образцом отзывчивости. Но, время идёт, старушка ветшает, решил вот попробовать свежий гном в исполнении той же убунты(19.10).

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

В юнити я могу переключаться между окнами и чё-то делать в терминале когда у меня уже своп с ssd подходит к концу в демке которую показывал @hakavlad тут намедни, т.е. при tail /dev/zero. В связке с oomd рабочее окружение остаётся операбельным(ну не считая мелких ~50-100ms фризов время от времени). В том же конфиге - шелль фризится ещё пока zram’овский swap не кончился, при этом - музло играет нормально, и vtty тоже ведёт себя отзывчиво, т.е. косяк именно в самом окружении, даже после переключения в конкретное окно - там отклик вполне себе.

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

В общем может я чего не доставил? Как сиё подускорить можно то?

★★★★★

Ответ на: комментарий от pon4ik

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

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

Гном3 - результат нарастающей идиократии.

anonymous
()

В NVIDIA X Server Settings включено Sync to VBlank, в настройках композитора тоже включено, и в игре тоже включено, а в настройках иксов включена тройная буферизация и FreeSync. И только после этого тиринг всё-таки удалось победить! Но откуда лаги?

ZenitharChampion ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

А чего тебе не хватило?

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от LongLiveUbuntu

gThumb, как ни странно, сейчас фичастее gwenview. Но вот средства записи dvd - печалька, т.к. нельзя записать проект с готовыми .vob файлами.

grem ★★★★★
()
Ответ на: комментарий от neocrust

Ты путаешь тёплое с мягким.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от hakavlad

Он на плюсах, мне похакать проще будет если вдруг чё. Ну и он заработал из коробки и лучше чем earlyroom(там дебильный триггер, за те 10мс которые он спит может пол свопа сбежать).

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от grem

Я скорее про переключение между приложениями, ну и в наутилус да, всё можно делать с клавы и это даже не вызывает боли.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от WitcherGeralt

меня вымораживают убогие apt с dpkg

Ты тоже из этих, которые каждый байт берегут и воспламеняются от любой лишней зависимости? Или ты сборщик пакетов, и тебя deb унижает? Иначе с т.з. юзера необъяснима эта фобия. Хочется спросить: а где неубогие пакетники? Школопакман что ли, или может сиящий красными глазами nix? Лол.

anonymous
()
Ответ на: комментарий от anonymous

Нет, когда я собирал пакеты меня унижал скорее rpm.

У тебя всё смешалось, люди, кони, а я говорил про ПМ. Zypper — one love.

WitcherGeralt ★★
()
Ответ на: комментарий от anonymous

Ты тоже из этих

Не конкретно из этих, но я тоже ценю прекрасное и не люблю убогое.

WitcherGeralt ★★
()
Ответ на: комментарий от pon4ik

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

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

grem ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

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

Типичный синдром утенка.

Polugnom ★★★★★
()
Ответ на: комментарий от grem

Хм. Давай начнём издалека - как часто ты закрываешь открытые приложения? Скажем браузер?

Сколько окон браузера у тебя обычно активно? А терминала?

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

Какой типовой аптайм у твоей сессии?

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

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

Открыт браузер, как правило 1. Второй для других домочадцев.

Терминал 1 с несколькими, до 5, вкладок: переключение между ними по shift+стрелка; изменение полиции вкладки ctrl+shit+стрелка.

Рабочая активность в рамках одной задачи: 4-5 приложений.

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

grem ★★★★★
()
Ответ на: комментарий от pon4ik

он заработал из коробки

А ничего, что он всю сессию убивает при корректирующем действиии через SIGKILL? earlyoom действует намного аккуратнее.

за те 10мс которые он спит может пол свопа сбежать)

Начнем с того, что у oomd минимальный интервал вообще 1000ms. Во-вторых, он грузит при таком интервале процессор как не в себя - https://github.com/facebookincubator/oomd/issues/79

Ваши аргументы слегка абсурдны, за исключением «Он на плюсах, мне похакать проще». Да и earlyoom хакать нетрудно - он простой и на Си. Да и хакать там особо нечего - разве что вшитые дефолты поправить.

за те 10мс которые он спит может пол свопа сбежать)

Он обычно 100 мс спит - это минимальный интервал проверок. В любом случае этого достаточно для прибития.

hakavlad ★★★
()
Ответ на: комментарий от hakavlad

Ты бы хоть почитал доку что ли для начала… Он прибивает сессию целиком только по-умолчанию, в пакете уже из коробки десктопный конфиг. Earlyroom - полит состояние (читает количество доступной памяти раз в сколько-то там раз в секунду), а oomd на свежих ядрах получает событие через специальный механизм (уже не помню деталей, выбирал сравнительно давно, пару недель назад что-ли).

Это почему я вообще пошёл искать альтернативу earlyroom, который позволял системе повисеть до прихода настоящего oom.

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

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от grem

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

Я предпочитаю окна потому, что по ним проще искать, при этом можно искать между разными приложениями, т.е. если я ищу по названию проекта, то у меня в поиск попадёт и нужное окно браузера, и связанный терминал, ну и любое другое что работает сейчас с файлами этого проекта. В большинстве случаев у меня тоже около 5 приложений запущенно (браузер, терминал, почта/календарь, im, заметочки и музычка), но вот окон у первых двух - минимум 2 (работа/неработа). Могло сложиться впечатление, что я пользуюсь поиском регулярно - это не так, я пользуюсь поиском, когда приходится делать несколько длительных задач параллельно.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

Ты бы хоть почитал доку что ли для начала…

Глупости какие, нормальные люди сразу переходят к практике.

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

Десктопный конфиг отличается только тем, что мониторит user.slice. С десктопным конфигом убивается вся session.scope - это by design:

seems like oomd kills all processes in memhog.scope, not only fattest process, it is not good for desktop

Yeah that’s by design. The smallest granularity oomd will operate on is a cgroup. Doing per-process is kind of a mess, especially when multiple teams own different services on a system. It’s much easier to delegate a cgroup tree than to try and manage individual processes everywhere.

https://github.com/facebookincubator/oomd/issues/61#issuecomment-520641352

Смотри https://imgur.com/a/FSOtqPm - с десктопным конфигом oomd прибил всю сессию.

См также https://github.com/facebookincubator/oomd/issues/90#issuecomment-530836227

См также https://github.com/facebookincubator/oomd/issues/80 - oomd fails to see the problem if SwapTotal=0 and MemAvailable=0

Earlyroom - полит состояние (читает количество доступной памяти раз в сколько-то там раз в секунду), а oomd на свежих ядрах получает событие через специальный механизм

Они оба читают /proc/meminfo. oomd также читает memory.pressure файла, и на ядрах 5.2+ делает это через специальный механизм, польза от котрого - экономия процессора. Но даже при этой экономии он гручит проц в сотни раз больше, чем earlyoom. Nohang тоже может читать PSI файлы, но при этом не грузит процессор как сумасшедший.

earlyroom, который позволял системе повисеть до прихода настоящего oom.

Прошу дать инфу, как я могу это воспроизвести. Опишите, паожалуйста, воспроизводимую конфигурацию и нагрузку, при которой ядерный киллер сработал бы раньше, чем earlyoom. Или что вы имеете в виду под настоящим oom и как это воспроизвести.

anonymous
()

шелль фризится ещё пока zram’овский swap не кончился

Два момента по поводу претензий к earlyoom.

  1. Фриз при полупустом свопе. PSI позволяет детектить конкуренцию за mem/io и применять корректирующие действия. Для этого подходят oomd, nohang и psi-monitor (95 строк на Си, включен по дефолту в Endless OS) и еще печально известный low-memory-monitor (славится своей агрессивностью, устраивает массовые расстрелы и автор считает это нормальным - https://gitlab.freedesktop.org/hadess/low-memory-monitor/issues/8). Использование киллера с детекцией по ПСИ позволяет быстро пресекать длинные лаги.

  2. Zram интересен тем, что при большом disksize и плохой сжимаемости данных может случиться ЭТО: устройство zram может заполнить под 90% памяти - это обычно точка зависания. Но при этом своп может быть полупустым - и earlyoom при этом будет бездействовать, так как реагирует только на уровни MemAvailable & SwapFree.

С обоими пунктами может совладать nohang - он может реагировать на уровень mem_used_total при использовании zram, если включить это в конфиге. И умеет работать с пси, конфиг для этого достаточно гибкий.

anonymous
()
Ответ на: комментарий от pon4ik

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

По умолчанию как раз и идет десктопный конфиг, других конфигов не предлагается. И да, oomd убивает только cgroup целиком, в том числе по умолчанию - с десктопным конфигом.

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

anonymous
()
Ответ на: комментарий от pon4ik

за те 10мс которые он спит может пол свопа сбежать

Скорость сбегания свопа на SSD до 700 M/s, на zram я видел максимальную скорость до 1700 MiB/s при запуске многопоточного stress - это 170 метров за 100 ms - это максимальная скорость. Обычно же нагрузки намного ниже и соответственно скорость сбегания во много раз ниже.

Скорость исчерпания доступной памяти есть в настройках nohang - можно настроить периодическую печать доступной памяти и скорости исчерпания памяти и свопа:

print_mem_check_results = True
min_mem_report_interval = 0

– с такими настройками nohang будет распечатывать результат каждой проверки доступной памяти.

Исходя из предполагаемых максимальных скоростей исчерпания памяти и свопа выставляется интенсивность мониторинга:

fill_rate_mem  = 4000
fill_rate_swap = 1500
  • вместо фиксированного интервала проверок мы можем реже мониторить состояние памяти для экономии процессорного времени если ее много свободной, и по мере исчерпания интервал уменьшается.
anonymous
()
Ответ на: комментарий от anonymous

Пни меня после 20-00 по мск, я перепроверю. Про oom в соседней tty видел ругань oomkiller спустя минут 15 подвисона.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от hakavlad
cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/dm-1                               partition       8237052 289760  -2
/dev/zram0                              partition       4194300 3528    32767
/dev/zram1                              partition       4194300 3680    32767
/dev/zram2                              partition       4194300 3520    32767
/dev/zram3                              partition       4194300 3700    32767
tail /dev/zero
Dec 05 20:40:42 laptop kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/user@1000.service,task=tail,pid=27099,uid=1000
Dec 05 20:40:42 laptop kernel: Out of memory: Killed process 27099 (tail) total-vm:26308824kB, anon-rss:5733112kB, file-rss:4kB, shmem-rss:0kB
Dec 05 20:40:44 laptop kernel: oom_reaper: reaped process 27099 (tail), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

А oomd оказывается тупо не завёлся. Чего было под другим конфигом мне проверять лень. Могу только сказать, что своп и железо там тоже самое, а earlyroom я вырубил и всё стало намного лучше.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

Завёл в текущей системе oomd - он не приходит раньше жнеца. Попробовал earlyroom - он приходит. Конфигурять oomd дальше, пока нет желания.

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от hakavlad

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

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

как бы мне стриггирить ситуацию когда заданное количество памяти занято?

https://github.com/hakavlad/nohang-extra

Там лежит скрипт i-memhog - интерактивный пожиратель памяти. Может отъедать заданное число гигабайт. Может останавливаться при наличии заданного остатка SwapFree+MemAvailable. Можно регулировать скорость пожирания. Можно регулировать сжимаемость данных для тестов zram. Можно включать игнорирование SIGTERM. Снабжен интерактивным меню, вводи циферки для выбора нужной опции. Скачай репу и из репы запускай i-memhog:

$ ./i-memhog
anonymous
()
Ответ на: комментарий от pon4ik

В той же репе лежит скрипт mm - мониторит общее состояние памяти, в том числе есть поле сжатия zram и поле общего объема устройств zram в памяти. Можно запускать одновременно с i-memhog для удобного мониторинга в том числе состояния zram и свопов. Снабжен также детектором фризов - бегающим плюсиком.

anonymous
()
Ответ на: комментарий от anonymous

Почему - это вопрос. Что именно - с earlyroom дольше вырубало хвост, после того, как я его отключил, система фризилась максимум на секунду и как раз при полном исчерапании всех swap. «Фризилась» - понятно, что дюже субъективное понятие, гномощель уже на 15ом Gb молчит практически наглухо(забавное совпадение, как только дело доходит до свопа на диск…).

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

earlyroom дольше вырубало хвост

Удивительные истории. tail не обрабатывает SIGTERM, который получает от earlyoom и реагирует на сигнал очень быстро (без свопа память процесса обнуляется за миллисекунду, со свопом процесс может периодически впадать в состояние D и дольше реагировать на любые сигналы). Время смерти процесса печатается в логах earlyoom - это доли секунды без свопа и до нескольких секунд если ушло в своп и съело много гигабайт. Возможно, ядерный OOMK просто убивает быстрее, если действительно стриггернут. - А с этим как раз проблема, если мы пожираем память реальными приложениями типа браузеров, а не хвостовой синтетикой, которая является образцом того, как ядерный OOMK действительно работает.

Смотри кейс Ташкинова https://lkml.org/lkml/2019/8/4/15 - в этих условиях ядерного ООМ автор не дождался, но если бы был запущен earlyoom, то имел бы полное отсутствие фризов.

после того, как я его отключил, система фризилась максимум на секунду

А насколько фризилась с включенным earlyoom? Уверен ли, что это связано именно с earlyoom? Делаешь ли выводы лишь по единичным опытам? Сам по себе earlyoom создает околонулевую нагрузку от убивает преступника раньше ядра. Какие же дополнительные тормоза он может создавать?

hakavlad ★★★
()
Ответ на: комментарий от hakavlad

Фризилась на несколько минут.

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

pon4ik ★★★★★
() автор топика
Ответ на: комментарий от pon4ik

Фризилась на несколько минут.

Звучит как баг, достойный отдельного issue и требующий расследования.

Вар 1: как-то связано с zram. - earlyoom может не срабатывать в некоторых случаях при исчерпании памяти при работе со zram.

Вар 2. какое-то приложение с максимальным oom_score, которому earlyoom просылает SIGTERM, как-то аномально обрабатывает SIGTERM, например начинает туда-сюда гонять memory/io.

Весьма вероятен первый вариант.

Nohang имеет встроенные средства диагностики состояния памяти, в том числе позволяет логировать размер zram устройства (и реагировать на превышение его размера, в отличие от earlyoom и oomd). Проблемы с двумя киллерами - отличный повод попробовать еще один киллер.

hakavlad ★★★
()

Мда, не зря я с ЛОРа свалил, раз такие детские вопросы задают люди с 5 звёздами, игрули мля.

anonymous
()

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

Правда, оно выглядит как говно теперь и дефолтный шрифт какой-то всратый (не ШГ, просто УГ).

WitcherGeralt ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.