Непонятное, выборочное, поведение... Этакие томоза, хотя не скажу, что это точное определение... Суть в следующем: берем Хромиум, или Гугл Хром (который точно к сборкам пакетов в Альте отношения не имеет). Открываем вкладке... В Альте вкладки начинают падать от силы на 20-й... В Росе можно открыть несколько сотен, и все будет ОК. Дело не в браузере. Точно... Хром, в Альте не собирают... Лимиты такие-же как в Росе, и увеличение их (как сове овал Ардрей Черепанов, дело не спасает... Или вот, Вайн, в том числе сторонний, из POL-а, неважно какой версии... Ставим клиент Батлы, из него ставим Дьяблу... Клиент под час ставится, игра также, игра и запускается также долго... В Росе-же почти как на Винде... При этом производительность игры запущенной на Альте, имхо, сравнима с Росиной... Очередной, сиречь, "выборочный тормоз" непонятной природы... Скажем другое не "тормозит"... Не музыка, не видео... Чуть позже видео приатачу... Проблема лишь в Альте... Не в Росе, не в Бунте ее не ... В чем ее природа непонятно... В чем-то общесистемном... В патчах ядра?.. Glib?.. Еще чем?.. Не знаю... Посему вешаю на обум... При этом, раньше, как минимум в Кентавре, как минимум в первып годы до выхода восьмой Винды, такого не было... По мне более чем критическая проблема, ибо непонятно где, и как такое еще выскочит...
https://yadi.sk/i/tYqr0L2X36iDAL Вот видео установки батлы... В Реальном времени, под конец отрубилось из-за нехватки места на смарте... Длится около получаса, еще столько-же, если не дольше, продолжало ставится после отруба... Это откровенно ненормально...
Грузился с разными ядрами... SDF, UDF, и всякой "экзотикой"... Но проблему это не исправило...
glib это не тот Glib, которым пользуются ваши графические приложения. Перевешиваю на пакет, который принято использовать в случаях, когда нет идей, на что лучше повесить баг.
(В ответ на комментарий №3) > Перевешиваю на пакет, который принято использовать в случаях, когда нет идей, > на что лучше повесить баг. ОК.. Про такие тонкости буду знать. :) По поводу же сабжа, то ситуация с вкладками хорошо на ridus.ru видна, коли что, например, коли там ссылки, во вкладках, открывать...
Это про лимит на кол-во процессов на пользователя, скорее всего. Попробуйте-ка в /etc/security/limits.d/50-defaults.conf поднять * soft nproc с 512 до 2048 и посмотреть, поможет ли; если да -- перевешивайте на pam.
(В ответ на комментарий №5) > Это про лимит на кол-во процессов на пользователя, скорее всего. > > Попробуйте-ка в /etc/security/limits.d/50-defaults.conf поднять * soft nproc с > 512 до 2048 и посмотреть, поможет ли; если да -- перевешивайте на pam. Простите за задержку... Как руки дошли... Сделал. Причем выставил 4096 (как, для данной позиции, в подобном файле Росы)... Никакого эффекта. Как минимум заметного без ядерного микроскопа... Подмена на Росиный (так лимиты по другому выставлены) также ничего не дали... Аналогично, в общем, с предложенными, в свое время, Андреем Черепановым (в беседе через личку форума), изменениями /etc/security/limits.conf и /etc/chromium/default (которые, конфиги в дефолтном для Альта виде, вообще, в целом, соответствуют Росиным)... Вотс... Фиг его зна в чем причина такой аномальщины... Но pam если и вносит свою долю, то явно минимальную...
Кстати говоря... Мне вот что в голову пришло... Оба примера с явнозамеченными проблемами (хромированные браузеры, и близардовая софта и игры) это интернет приблуды, пускай и разноговида, формы, и расцветки... Посему, "сетивизмы", разные, виноваты не могут быть?.. Скажем той-же батле могут быть проблемы с "рекламными картинками", ссылками на новости из клиента, и прочее подобное... В Росе их (этих проблем) нет... Вот мне, сейчас, и, внезапно, пришло в голову следующие... Может что-то из сетивизмов и рядом с ними прыгающим (там сертиыикатами-шмертиыикатами, и т. п.) поломали-перепатчили? Ну или, наоборот, давно не обновляли, и оно протухло и глючит столкнувшись с изменившимися внешними реалиями?.. Но pam, боюсь, точно не шибко причем...
(В ответ на комментарий №7) > Но pam, боюсь, точно не шибко причем... Покажите-ка вывод команды ulimit -a от этого пользователя.
(В ответ на комментарий №8) > (В ответ на комментарий №7) > > Но pam, боюсь, точно не шибко причем... > Покажите-ка вывод команды ulimit -a от этого пользователя. core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 47962 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 1024 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
(В ответ на комментарий №9) > > > Но pam, боюсь, точно не шибко причем... > > Покажите-ка вывод команды ulimit -a от этого пользователя. > max user processes (-u) 1024 Это именно про pam_limits. (В ответ на комментарий №5) > Это про лимит на кол-во процессов на пользователя, скорее всего. Собственно, стоило сразу запросить этот вывод -- теперь видно точно. > Попробуйте-ка в /etc/security/limits.d/50-defaults.conf поднять * soft nproc > с 512 до 2048 и посмотреть, поможет ли; если да -- перевешивайте на pam. И ещё "* hard nproc" -- он-то ограничивает жёстко ту же величину.
(В ответ на комментарий №10) > И ещё "* hard nproc" -- он-то ограничивает жёстко ту же величину. Поднял. Вот доказательство: [andrey@comp-core-i7-603a30 ~]$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 47962 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 4096 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited И... Правильно. Никакого эффекта. Как минимум заметного без ядерного микроскопа. Либо есть еще "хитрые процессы"... Гляну еще с unlimited (для "гарантированной надежности результата"), конечно... Но, боюсь, эффект будет тот-же...
Так обещанный unlimited. core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 47962 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Во общем вы меня поняли... Как, честно говоря, уже и ожидалось, никаких "улучшений ситуации" не замечено... В чем причина фиг его зна... Но pam, походу, не шибко при лелах... Либо есть еще какие "хитрые лимиты"... Проблема только на Альте... В других дистрах все нормально... Было нормально, повторяю, и на Кентавре (как минимум в первые годы, до выхода Windows 8). В туже Дьяблу играл на ура... И никаких проблем и аномальных дикостей не было... В чем проблема фиг его зна... В чем-то общесистемном точно. Но в чем непонятно (может в glib, может в "сетевизмах, может еще в чем)"... Выставление лимитов проблему не решают...
ulimit тут правда не при чём. попробуйте так: apt-get install tuned systemctl start tuned systemctl enable tuned tuned-adm profile desktop
А что за конфигурация системы ? ядро, железо ? присоединяйте system-report
Created attachment 6943 [details] Системный рапорт (В ответ на комментарий №13) > ulimit тут правда не при чём. > попробуйте так: > apt-get install tuned > systemctl start tuned > systemctl enable tuned > tuned-adm profile desktop Сделал. Никаких улучшений. Системный рапорт в атаче. Мои идеи о том, что это может быть, выше... Но, однозначно, что-то серьезно слолмали в общесистемном. Ибо софт не виноват точно (смотрим выше). Возможно стоит сравнить, детально, первые кентавры (если сохранились архивы образов и репов того времени (первые годы Кентавра до выхода W8, когда точно все работало нормально...)) и нынешнее...
В Росе на SSD планировщик bfq. У вас (вы Андрей с конем на аватарке?) SSD?
И попробуйте сравнивать su - sysprof в двух дистрибутивах на одинаовых операциях.
