vasek |
|
Темы:
48
Сообщения:
11340
Участник с: 17 февраля 2013
|
kurychМожет я плохо объяснил ........ я запускаю из юнита сам сервис через strace ......... и намного больше информации - видно куда лезет и сколько времени на что уходит ... PS ......... возможно это и не правильно ...... но ничего другого до сих пор не находил ...... это обсуждение у нас впервые .....
Ошибки не исчезают с опытом - они просто умнеют
|
vasek |
|
Темы:
48
Сообщения:
11340
Участник с: 17 февраля 2013
|
indeviralЗаметил у себя - время запуска сервиса не постоянно и меняется в интервале 1,5 — 4с (например, сегодняшние данные — 2.955s, 1.507s) …..... решил проверить, почему меняется и выявил (использовал strace) — например, для случая загрузки с временем 2,5с ….... 2с уходит на два timeout в системном вызове ppoll (по 1с два раза — timeout установлен в 1с) UPD …. ppoll() позволяет приложению безопасно ждать, пока файловый дескриптор не станет готов или пока не будет получен сигнал, т. е. завершается если истекло установленное время ожидания и нет готовых файловых дескрипторов PS … интересно отметить статистику по системному вызову open- всего вызовов — 872 - из них пустых (лезет в несуществующие файлы) — 238 - наибольшее обращение к файлу /dev/snd/controlC0 — 365 И что интересно, этот файл как раз и являлся причиной timeout (система не дождалась данного дескриптора) PSS ... это я к тому, что достаточно 10 timeout и получим 10с задержки ...
Ошибки не исчезают с опытом - они просто умнеют
|
indeviral |
|
Темы:
38
Сообщения:
3196
Участник с: 10 августа 2013
|
vasekПричиной этого мракобессия скорее всего является вот это /etc/pulse/default.pa Мутноватая система загрузки модулей... Надо попробовать поубирать лишнее, должно помочь. p.s. особенно понравился вот этот модуль ### Automatically augment property information from .desktop files p.p.s ничего это не даёт, оставил только два модуля время уменьшилось на ~1-1.5 сек
Ошибки в тексте-неповторимый стиль автора©
|
Haron_Prime |
|
Темы:
28
Сообщения:
2109
Участник с: 08 июня 2014
|
indeviralещё два дня назад поотключал всё, без чего пульс нормально запускается и выводит звук я бы не сказал, что что-то сильно изменилось
из всех оставил только
P.S> отключил вдобавок
В общем, всё это как мёртвому припарки! Пульс - вещь в себе, как и другое творение того же автора ;) |
indeviral |
|
Темы:
38
Сообщения:
3196
Участник с: 10 августа 2013
|
[pulseaudio] (alsa-lib)utils.c: could not open configuration file /usr/share/alsa/ucm/HDA Intel PCH/HDA Intel PCH.confМожет надо не pulse а alsa ковырять)))
Ошибки в тексте-неповторимый стиль автора©
|
Haron_Prime |
|
Темы:
28
Сообщения:
2109
Участник с: 08 июня 2014
|
P.P.S> поотключал вообще практически всё - оставил только то, без чего он работать вообще отказывается
indeviral у меня ничего подобного нет
|
Haron_Prime |
|
Темы:
28
Сообщения:
2109
Участник с: 08 июня 2014
|
Запустил у себя с strace - ничего, подобного этомуvasekне обнаружил! Ни одного вхождения ppoll Вот весь выхлоп, если кому интересно зато "No such file or directory" - аж 104 вхождения (((( хрень какая-то... |
Haron_Prime |
|
Темы:
28
Сообщения:
2109
Участник с: 08 июня 2014
|
хотя время заметно уменьшилось
|
vasek |
|
Темы:
48
Сообщения:
11340
Участник с: 17 февраля 2013
|
Haron_PrimeСудя по строке execve("/bin/pulseaudio", ["pulseaudio"], [/* 47 vars */]) = 0 и времени загрузки Haron_PrimeПредположу, что загрузка сервиса была не совсем правильная ...
Ошибки не исчезают с опытом - они просто умнеют
|
vasek |
|
Темы:
48
Сообщения:
11340
Участник с: 17 февраля 2013
|
Прошу не ругаться за писанину, но решил описать как я делал … пошел простым путем, не стал редактировать системные файлы … правильно это или нет, не знаю. Для того и пишу, чтобы узнать на этот счет мнение спецов по systemd, чтобы учесть замечания на будущее $ systemctl --user edit --full pulseaudio.service строку …. ExecStart=/usr/bin/pulseaudio --daemonize=no … приводим к виду ExecStart=/usr/bin/strace -fr -o /home/<USER...>/pulse_user.log /usr/bin/pulseaudio --daemonize=no Вместо <USER...> ….. прописать свое …. Сохраняемся …...... (имя файла не менять, сохранять так, как предложат) $ sudo systemctl daemon-reload В итоге всего этого появится файл /home/<USER>/.config/systemd/user/pulseaudio.service Проверяем $ systemctl --user cat pulseaudio.service | grep ExecStart .......... проверяем правильность изменения (или обычным способом $ cat ~/.config/systemd/user/pulseaudio.service | grep ExecStart ) Если все нормально ….... reboot В конце загрузки DE/WM будет наблюдаться задержка ~ 100с (это время задержки нужно будет отфильровать из лога) … причину этого не разбирал, но на анализ это не влияет ... Смотрим/проверяем $ systemctl status --user pulseaudio.service Должно быть два процесса 599 /usr/bin/strace -fr -o /home/<USER...>/pulse_user.log /usr/bin/pulseaudio --daemonize=no 601 /usr/bin/pulseaudio --daemonize=no $ systemd-analyze blame --user … в этом выводе pulseaudio.service не будет И главное смотрим наличие самого лога ….... ~/pulse_user.log Если все нормально, возвращаем все на место ... $ rm /home/<UESER...>r/.config/systemd/user/pulseaudio.service $ sudo systemctl daemon-reload reboot …..... перегрузка может занять ~ 90с …. ждите ….. Смотрим/проверяем, что все в порядке …. $ systemd-analyze blame --user …...... 1.674s pulseaudio.service $ systemctl --user status pulseaudio.service АНАЛИЗ ~/pulse_user.log Как уже писал из лога нужно отсечь (в самом конце) записи, обусловленные задержкой загрузки Если посмотреть общее время загрузки сервиса, то увидим большое значение $ cat ~/pulse_user.log | awk '{ SUM += $2 } END {print SUM}' 93.4936 Открываем лог и находим последний системный вызов open, точнее open("/run/user/1000/orcexec PS ... по идее, вроде бы, можно/нужно отсечь и еще, т.е. подняться чуть чуть выше, .... но на анализ это не влияет ... 1-ый столбец — PID , 2-ой столбец — время вызова (с)Все строки, что находятся после close (закрытие открытого дескриптора — у меня 31) удаляем ... Сохраняем (для надежности можно сохранить как … , чтобы остался первичный лог) Смотрим общее время $ cat ~/pulse_user.log | awk '{ SUM += $2 } END {print SUM}' 2.36987 Ну а дальше ищем место, где вызов занимает много времени … Для начала делаем предположение, что причина в timeout …. Смотрим есть ли вызовы ppoll $ cat ~/pulse_user.log | grep ppoll | wc -l 9 Имеются …..... аж 9 шт. …..... вот и посмотрим что там … Конечно, лучше посмотреть каждый вызов ppoll и внимательнее ….... но мы спешим, а потому ищем по слову Timeout …... $ cat ~/pulse_user.log | grep Timeout 2861 0.975852 <... ppoll resumed> ) = 0 (Timeout) 2862 0.996905 <... ppoll resumed> ) = 0 (Timeout) …... вот они 2с …... UPD … если внимательнее присмотреться к ppoll, то увидим, что данный вызов наблюдается при смене/переходе PID …...... Но это данные моего анализа ….... у кого то они будут другие …. как и сама причина ... Как писал выше, нет 100% уверенности в правильности данного способа - нигде об этом не написано, все пришлось сочинять Отработал способ несколько раз, исключив все ошибки ...... вроде сюрпризов быть не должно ... PSS ... забыл отметить, что так можно определить только место задержки, а не не сам источник первопричины ...
Ошибки не исчезают с опытом - они просто умнеют
|