Bug 32964

Summary: Непонятные, выборочные, "тормоза"
Product: Sisyphus Reporter: unihorn <unihorn>
Component: altlinux-releaseAssignee: Dmitry V. Levin <ldv>
Status: NEW --- QA Contact: qa-sisyphus
Severity: critical    
Priority: P3 CC: m, mike, rider
Version: unstable   
Hardware: all   
OS: Linux   
URL: https://lists.altlinux.org/pipermail/devel/2016-December/202159.html
Attachments:
Description Flags
Системный рапорт none

Description unihorn 2017-01-03 19:04:10 MSK
Непонятное, выборочное, поведение... Этакие томоза, хотя не скажу, что это точное определение... Суть в следующем: берем Хромиум, или Гугл Хром (который точно к сборкам пакетов в Альте отношения не имеет). Открываем вкладке... В Альте вкладки начинают падать от силы на 20-й... В Росе можно открыть несколько сотен, и все будет ОК. Дело не в браузере. Точно... Хром, в Альте не собирают... Лимиты такие-же как в Росе, и увеличение их (как сове овал Ардрей Черепанов, дело не спасает...

Или вот, Вайн, в том числе сторонний, из POL-а, неважно какой версии... Ставим клиент Батлы, из него ставим Дьяблу... Клиент под час ставится, игра также, игра и запускается также долго... В Росе-же почти как на Винде... При этом производительность игры запущенной на Альте, имхо, сравнима с Росиной... Очередной, сиречь, "выборочный тормоз" непонятной природы... Скажем другое не "тормозит"... Не музыка, не видео... Чуть позже видео приатачу... Проблема лишь в Альте... Не в Росе, не в Бунте ее не ... В чем ее природа непонятно... В чем-то общесистемном... В патчах ядра?.. Glib?.. Еще чем?.. Не знаю... Посему вешаю на обум... При этом, раньше, как минимум в Кентавре, как минимум в первып годы до выхода восьмой Винды, такого не было...

По мне более чем критическая проблема, ибо непонятно где, и как такое еще выскочит...
Comment 1 unihorn 2017-01-03 19:09:30 MSK
https://yadi.sk/i/tYqr0L2X36iDAL

Вот видео установки батлы... В Реальном времени, под конец отрубилось из-за нехватки места на смарте... Длится около получаса, еще столько-же, если не дольше, продолжало ставится после отруба... Это откровенно ненормально...
Comment 2 unihorn 2017-01-03 19:17:30 MSK
Грузился с разными ядрами... SDF, UDF, и всякой "экзотикой"... Но проблему это не исправило...
Comment 3 Dmitry V. Levin 2017-01-03 19:25:36 MSK
glib это не тот Glib, которым пользуются ваши графические приложения.
Перевешиваю на пакет, который принято использовать в случаях, когда нет идей, на что лучше повесить баг.
Comment 4 unihorn 2017-01-03 19:28:42 MSK
(В ответ на комментарий №3)
> Перевешиваю на пакет, который принято использовать в случаях, когда нет идей,
> на что лучше повесить баг.

ОК.. Про такие тонкости буду знать. :)

По поводу же сабжа, то ситуация с вкладками хорошо на ridus.ru видна, коли что, например, коли там ссылки, во вкладках, открывать...
Comment 5 Michael Shigorin 2017-01-05 10:41:01 MSK
Это про лимит на кол-во процессов на пользователя, скорее всего.

Попробуйте-ка в /etc/security/limits.d/50-defaults.conf поднять * soft nproc с 512 до 2048 и посмотреть, поможет ли; если да -- перевешивайте на pam.
Comment 6 unihorn 2017-01-23 08:38:14 MSK
(В ответ на комментарий №5)
> Это про лимит на кол-во процессов на пользователя, скорее всего.
> 
> Попробуйте-ка в /etc/security/limits.d/50-defaults.conf поднять * soft nproc с
> 512 до 2048 и посмотреть, поможет ли; если да -- перевешивайте на pam.

Простите за задержку... Как руки дошли...

Сделал. Причем выставил 4096 (как, для данной позиции, в подобном файле Росы)...

Никакого эффекта. Как минимум заметного без ядерного микроскопа...

Подмена на Росиный (так лимиты по другому выставлены) также ничего не дали...

Аналогично, в общем, с предложенными, в свое время, Андреем Черепановым (в беседе через личку форума), изменениями /etc/security/limits.conf и /etc/chromium/default (которые, конфиги в дефолтном для Альта виде, вообще, в целом, соответствуют Росиным)...

Вотс... Фиг его зна в чем причина такой аномальщины... Но pam если и вносит свою долю, то явно минимальную...
Comment 7 unihorn 2017-01-23 09:14:40 MSK
Кстати говоря... Мне вот что в голову пришло...

Оба примера с явнозамеченными проблемами (хромированные браузеры, и близардовая софта и игры) это интернет приблуды, пускай и разноговида, формы, и расцветки...

Посему, "сетивизмы", разные, виноваты не могут быть?..

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

В Росе их (этих проблем) нет...

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

Но pam, боюсь, точно не шибко причем...
Comment 8 Michael Shigorin 2017-01-23 13:56:17 MSK
(В ответ на комментарий №7)
> Но pam, боюсь, точно не шибко причем...
Покажите-ка вывод команды ulimit -a от этого пользователя.
Comment 9 unihorn 2017-01-23 18:10:33 MSK
(В ответ на комментарий №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
Comment 10 Michael Shigorin 2017-01-23 20:20:20 MSK
(В ответ на комментарий №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" -- он-то ограничивает жёстко ту же величину.
Comment 11 unihorn 2017-01-24 02:45:45 MSK
(В ответ на комментарий №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 (для "гарантированной надежности результата"), конечно... Но, боюсь, эффект будет тот-же...
Comment 12 unihorn 2017-01-24 03:40:13 MSK
Так обещанный 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, может в "сетевизмах, может еще в чем)"... Выставление лимитов проблему не решают...
Comment 13 Anton Farygin 2017-01-24 07:57:56 MSK
ulimit тут правда не при чём.
попробуйте так:
apt-get install tuned
systemctl start tuned
systemctl enable tuned
tuned-adm profile desktop
Comment 14 Anton Farygin 2017-01-24 07:59:58 MSK
А что за конфигурация системы ? ядро, железо ?
присоединяйте system-report
Comment 15 unihorn 2017-01-24 18:44:12 MSK
Created attachment 6943 [details]
Системный рапорт

(В ответ на комментарий №13)
> ulimit тут правда не при чём.
> попробуйте так:
> apt-get install tuned
> systemctl start tuned
> systemctl enable tuned
> tuned-adm profile desktop

Сделал. Никаких улучшений.

Системный рапорт в атаче.

Мои идеи о том, что это может быть, выше... Но, однозначно, что-то серьезно слолмали в общесистемном. Ибо софт не виноват точно (смотрим выше).

Возможно стоит сравнить, детально, первые кентавры (если сохранились архивы образов и репов того времени (первые годы Кентавра до выхода W8, когда точно все работало нормально...)) и нынешнее...
Comment 16 mikhailnov 2018-10-19 10:35:44 MSK
В Росе на SSD планировщик bfq. У вас (вы Андрей с конем на аватарке?) SSD?
Comment 17 mikhailnov 2018-10-19 10:39:53 MSK
И попробуйте сравнивать
su -
sysprof

в двух дистрибутивах на одинаовых операциях.