Обнаружение перегрузки процессорных ядер

[Гурман]

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

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

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

Если кому-то не понятно о чем идет речь (по реакции я вижу, что не понятно...) - надо представлять эту задачу, как электронную схему, собираемую пользователем. Если пользователь создал положительную обратную связь, взяв выход цепочки из трех (или четырех, или десяти...) усилителей и замкнул его на неинвертирующий вход первого усилителя цепочки - при попадании на вход любого сигнала (на самом деле сразу при включении) схема "возбудится" и превратится в генератор, выдающий на частоте собственных колебаний некий периодический сигнал с амплитудой, почти равной питающему напряжению выходного усилителя. А может быть - пользователю именно это и нужно! Может быть, кроме этой очевидной обратной связи (которую программно можно обнаружить), один из усилителей пользовтель вводит в режим ограничения - и вся схема будет генерировать, но с управляемой амплитудой. Это видно пользователю, но это в принципе невозможно обнаружить программно. Зато можно дополнительными средствами обнаружить факт возбуждения, и выключить схему в такой ситуации. Вот и мне нужно обнаруживать факт перегрузки процессора (что является результатом паразитного "возбуждения"), а не переполнение очередей, установку соединений и т.д... Поскольку и переполнение очередей, и установка ЛЮБЫХ соединений могут быть вполне легальными и к перегрузке процессора не приведут.

То есть, никаких обходных путей нет. Нужно определять факт перегрузки процессора своими нитями. Больше ничего не подходит. Я уже просил - не уходить от этого вопроса. Это только бессмысленная трата времени.

[Гурман]

кстати а не задумывались использовать какую то RTOS для вашего приложения? например Qnx или VxWorks? Под Qnx точно есть Qt.

В Т.З. две ОС пока прописаны - Windows и Linux. QNX возможно в будущем. Всё. Больше ни шагу в сторону.

Както странно у вас должно работать приложение... в определенной ситуации когда нагрузка будет извне, оно просто не сможет работать вообще.

В реальности, если процессор перегружен посторонними задачами - и не должно работать. Ибо это не имеет смысла по сути задачи. Должно тревогу орать... Но если СВОИ нити перегрузили процессор - приложение должно иметь возможность это определить, и остановить эти нити (выдать алерт, сделать запись в лог и т.д.).

[Bepec]

Вы в верхнем +1 сообщении сами написали, что хотите невозможного.
Вы хотите дать возможность сознательно сделать зацикливание, но при это избежать зацикливания. Вы уж определитесь чего вы хотите.

PS самый простой пример - пользователь может создать 50 таких рекурсивных генераторов и у вас на любом компе загрузка будет под 100%, но при этом приложение должно работать в штатном режиме.

[Гурман]

Вы в верхнем +1 сообщении сами написали, что хотите невозможного.
Вы хотите дать возможность сознательно сделать зацикливание, но при это избежать зацикливания. Вы уж определитесь чего вы хотите.

Вы невнимательно читали. Я НИГДЕ не писал, что хочу избежать зацикливания - потому, что я этого НЕ хочу. Еще раз: зацикливание - НОРМАЛЬНАЯ ситуация. Но в результате ошибки пользователя зацикливание МОЖЕТ приводить к перегрузкам. Я с самого начала четко написал чего я хочу, повторю еще раз - определения ситуации перегрузки процессора этим же самым приложением. Здесь нет ничего про зацикливание. Зацикливание я вижу только у тех, кто не могут понять задачу - зацикливание на попытках решить проблему, которой нет, и которая не была сформулирована...

PS самый простой пример - пользователь может создать 50 таких рекурсивных генераторов и у вас на любом компе загрузка будет под 100%, но при этом приложение должно работать в штатном режиме.

Нет. Надо остановить "генераторы", пока процесор не освободится настолько, чтобы интерфейс стал достаточно реактивен, выдать сообщение об этом, сделать запись в лог. В расширенной диагностике показать, какие именно соединения привели к такой ситуации.

Всё, мне надоело повторять одно и то же.  Тему закрывать не буду, может кто-то поймет, о чем идет речь, и обсуждение свернет на обозначенную проблему. Но и реагировать на оффтопик больше не буду. Кроме ссылки xokc всё остальное было сплошным оффтопиком.

[Igors]

Кроме ссылки xokc всё остальное было сплошным оффтопиком.

Если Вы ввели свой термин "перегрузка процессора" никак его не определив, то напрасно Вы рассчитываете на содержательный разговор, все и будет "вокруг да около". Так что фырканье лучше оставить при себе.

Лично я под "перегрузом" понимаю "оверхед", причем солидный, когда нитки вместо полезной работы заняты напр переключениями контекста. Классический пример - создано слишком много ниток. Напр утилита Activity Monitor это прекрасно показывает. Если так то не вижу что обсуждать на форуме - ищите подходящие утилиты для своих платформ и не морочьте голову с доморощенными терминами. Если не так, то поясните какой смысл Вы вкладываете в этот термин, и лучше без нажима, не надо сорить большими жирными буквами.

Это не имеет смысла. Я уже три раза написал - я и так ...

А может не стоит без раздумий отвергать мысль которая мне кажется вполне здравой. Попробуйте забить очередь напр миллионом сигналов - и Вы получите отличные тормоза (уже на контейнере очереди). Обратный пример - с очередями все норм, но прет оверхед. Как это может случиться? По-моему никак. Напрашивается отслеживать динамику очереди - напр ага, неуклонно растет. А факт оверхеда - ну это уже "все случилось" и хз чем вызвано.

Хотя... чего это я лезу со своими "сплошными оффтопиками"?   Все, умолкаю

[Bepec]

оффтоп:
Вы не учитываете важную деталь. Даже при загрузке 100% процессорного времени приложение может отзываться нормально. Просто использоваться будет именно 100%
У процессора нет понятия "перегрузки", он работает спокойно и на 100% на всех ядрах, а торможение интерфейса - это уже забота программы и ОС.

У вас я вижу лишь вариант ограничить потребление программы. Не оверхед (его невозможно определить, по вышеизложенной причине), а именно потребление. Допустим более 70% мощностей программа жрёт - останавливаем и сообщение пользователю.

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

[Гурман]

оффтоп:
Вы не учитываете важную деталь. Даже при загрузке 100% процессорного времени приложение может отзываться нормально. Просто использоваться будет именно 100%
У процессора нет понятия "перегрузки", он работает спокойно и на 100% на всех ядрах, а торможение интерфейса - это уже забота программы и ОС.

У вас я вижу лишь вариант ограничить потребление программы. Не оверхед (его невозможно определить, по вышеизложенной причине), а именно потребление. Допустим более 70% мощностей программа жрёт - останавливаем и сообщение пользователю.

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

Пусть будет оверхед - это слово калька с английского overhead, что по сути означает перегрузку. Странно, что термин не понятен, он весьма древний. При некоторых действиях пользователя, которые невозможно запретить, возникает повышенное потребление ресурса процессора, которое снижает реактивность интерфейса до критической - приложением становится невозможно управлять. Это надо обнаруживать и снижать нагрузку на процессор. Изначально я начал тему, чтобы обсудить возможные варианты реализации этого обнаружения.

[Bepec]

Ну тут смотрите сами, задача опускается до "обнаружить замирание интерфейса".

То есть нам нужно замерять производительность отрисовки и системы доставки event'ов.

Вполне достаточно будет считать paintEvent в секунду допустим, или же посылать самому себе сообщения через QEvent. При нормальной работе промежуток между посылом и приёмом события будет минимальным. При увеличении промежутка бить тревогу и отрубать работу.


PS хотя сомнения имеются по paintEvent'u, там вроде может и не посылаться перерисовка при статичном интерфейсе.

[Гурман]

Это уже ближе к телу. Правда, мне не ясно, как считать paintEvent для всех элементов интерфейса, у меня их множество. Приложение может открыть более десятка окон на двух мониторах, а вообще их количество виртуально не ограничено - что пользователь захочет, то он и откроет. Какие плагины поставит, такие и будут окна открываться. В множестве случаев я не наследую классы этих окон. Впрочем, есть пара окон, которые обязательны, и которые наследуют QMainWindow. Достаточно ли будет отслеживать их паинты? Насколько я знаю, перерисовка в Qt производится только когда меняется содержимое окна, или его перекрытие, или по нему проходит курсор. Но курсор еще должен до него доехать... То есть, если курсор вне моих окон, и в них ничего не меняется - то о перегрузке-оверхеде узнать не получится. Нужен какой-то другой способ.

[Bepec]

По поводу paintEvent:
1) я говорил о сомнениях.
2) достаточно у одного окна отслеживать, ведь по сути мы проверяет систему евентов, а не отрисовку.

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

[Гурман]

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

А она точно парализована? У её нити нет повышенного приоритета?

[Bepec]

Собственно почему интерфейс отрисовывается - потому что через очередь событий приходит сообщение QEvent::Paint.
Почему интерфейс не отрисовывается или отрисовывается с задержкой - сообщение не доходит или доходит с задержкой.
Вывод - работа очереди событий парализована.

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

Как то так.

[Гурман]

Собственно почему интерфейс отрисовывается - потому что через очередь событий приходит сообщение QEvent::Paint.
Почему интерфейс не отрисовывается или отрисовывается с задержкой - сообщение не доходит или доходит с задержкой.
Вывод - работа очереди событий парализована.

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

Как то так.

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

То есть, надо пробовать...

[Bepec]

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

Отрисовка и доставка сообщения о её необходимости отличаются по времени в разы.

PS кстати тоже как вариант замерять время отрисовки для надёжности, но пока я в сомнениях о необходимости такой меры.

[Гурман]

up

Вернулся к этому вопросу. Попробовал для начала замерять время доставки обычных сигналов, и определять ситуацию, когда это время значительно увеличивается. Создал вариант, при котором интерфейс приложения вообще не откликается, и не перерисовывается. На 4-х ядерном процессоре загрузка всего 35-45%. То есть, компьютер работает, Веники живые, но само это приложение можно только прибить - на close главного окна оно реагирует, но больше ни на что. В этой ситуации даже не получается определить время доставки сигналов - они замерзают, никуда не доходят, любые попытки получить отладочную трассировку не имеют успеха.

Делал так - приемник соединен с передатчиком через QueuedConnection и крутит у себя нить, которая шлет сигналы, нагружающие процессор. Нить синхронизируется семафорами, этот код был ранее отлажен, и хорошо работает. Передатчик с такой же нитью посылает через очередь этому приемнику вместе с полезными данными (в тестовом режиме это были пары QString, то есть, довольно объемные данные) временной штамп (в миллисекундах в виде qint64), приемник получает штамп, и если разница текущего времени (QDateTime::currentMSecsSinceEpoch()) и штампа больше 1 секунды, то приемник глушит свою нить. При одной такой паре передатчик-приемник это работает. Но если создать 2-3 таких параллельно работающих соединения, то приемники просто перестают успевать обрабатывать сигналы. И явно передатчики тормозят и не успевают быстро посылать. При этом видно, что занятая память очень медленно растет - то есть, очереди наполняются, но не очищаются. Возможно, что сигнал об остановке таки был послан нити, но он тоже застрял.

Есть ли смысл проверять с помощью QEvent? Его механизм передачи существенно отличается от сигналов? Есть гарантия доставки QEvent при таком замерзании приложения, как описано? Можно ли доставлять QEvent с высоким приоритетом, чтобы обойти замерзшие очереди? Я не использовал формирование QEvent, обходился только обработкой сформированных системно.