Всем доброго!
Проект собран под Laz1.6. После запуска проекта htop по его pid показывает:
cpu% = 0,7
mem%=1,6
Спустя примерно 8 часов:
cpu% = 2,0
mem%=1,6
Спустя сутки:
cpu% = 5,7
mem%=1,6
Суть проекта - по таймеру из удаленной БД mySql вытаскивать данные (запрос простой и короткий к одной таблице).
Под Win7 такого эффекта не наблюдается. Волнуюсь.
Linux: проект ест ресурсы процессора?
Модератор: Модераторы
Попробуйте gprof, может поможет.
А проект консоль или gui (gtk2, qt, win32)?
fedan писал(а):А проект консоль или gui (gtk2, qt, win32)?
gtk2
Добавлено спустя 35 минут 54 секунды:
Pavia писал(а):Попробуйте gprof, может поможет.
Я так понимаю, что gprof относится к сборке под Qt, у меня gtk2.
По сути - в приложении тикают два таймера: по одному 4 раза в секунду меняется картинка (показ юзеру, что процесс идет),
по второму - собственно запрос к БД (раз в минуту).
Если таймеры остановить (не разрывая коннект с БД) - CPU%=0, Mem%=0,1.
При запуске таймеров - снова CPU%=8, Mem%=1,7 (приложение живет вторые сутки).
Два таймера едят ресурсы?
Попробовать оставить один таймер с картинкой. Протестировать.
Затем другой.
Затем другой.
таймеры/шмайнеры... А вот что вы с ними делаете?по таймеру из удаленной БД mySql вытаскивать данные
пересмотрите ваш код. Есть вероятность что винда не показывает реалии (или по иному воспринимает).Под Win7 такого эффекта не наблюдается. Волнуюсь.
А реально: что за гадания на кофейной гуще?
fedan писал(а):Попробовать оставить один таймер с картинкой. Протестировать.
Затем другой.
Один таймер с картинкой вообще ничего не ест. Но при плевом запросе к БД на локальной машине сразу CPU%=0.7, при отсутствии запросов к БД держится какое-то время, затем htop показывает CPU%=0.0, CPU%=0.7 попеременно. Через пару часов CPU%=0.0. .
Добавлено спустя 2 минуты 28 секунд:
pupsik писал(а):таймеры/шмайнеры... А вот что вы с ними делаете?
Показываю пользователю результаты запроса к БД.
Добавлено спустя 1 минуту 16 секунд:
pupsik писал(а):пересмотрите ваш код.
Хороший совет, спасибо.
Владимир писал(а):Спустя сутки:
cpu% = 5,7
mem%=1,6
Это не о чем не говорит. Тем более у вас оконное приложение. В период расчетов и вывода на экран пиковая загрузка процессора может доходить и до 100%/200%/300%, среднее по времени как раз лежать в 0%..10%.
подключение к БД на ассинхронном сокете? если да - то даже простой холостой опрос состояния сокета без ожиданий - уже может дать 100%.
как любой длительный for to do - грузит процессор так что вентиляторы разгоняются по максимуму.
olegy123 писал(а):Владимир писал(а):Спустя сутки:
cpu% = 5,7
mem%=1,6
Это не о чем не говорит. Тем более у вас оконное приложение. В период расчетов и вывода на экран пиковая загрузка процессора может доходить и до 100%/200%/300%, среднее по времени как раз лежать в 0%..10%.
подключение к БД на ассинхронном сокете? если да - то даже простой холостой опрос состояния сокета без ожиданий - уже может дать 100%.
как любой длительный for to do - грузит процессор так что вентиляторы разгоняются по максимуму.
В период расчета и вывода - CPU%=1.3, откуда 300% ,?
и нет там цикла...
Похоже, разобрался.
Есть таймер1 - основной, по которому происходит запрос к БД (20 - 300 сек, выбирается пользователем).
Есть таймер2 - 500 мс - для показа пользователю оставшегося времени до очередного запроса к БД.
Таймер1 по OnTimer сообщает Таймеру2 текущий таймаут запросов, и тот начинает новый отсчет времени до очередного запроса.
Отключил таймер2 - все здорово, CPU%=0
Рано обрадовался.
Собрал тестовый проект.
По таймеру раз в секунду на панель вывожу текущее время, в StatusBar - время, оставшееся до некого события.
Вот эти выводы и грузят проц.
Время | CPU% | MEM%
0 час | 0,0 | 0,8
3 час | 0,7 | 0,8
5 час | 1,3 | 0,9
8 час | 1,3 | 0,8
18 час | 2,7 | 1,0
20 час | 3.3 | 1,1
Собрал тестовый проект.
По таймеру раз в секунду на панель вывожу текущее время, в StatusBar - время, оставшееся до некого события.
Вот эти выводы и грузят проц.
Код: Выделить всё
procedure TForm1.Timer1Timer(Sender: TObject);
var //интервал - 1000 мс
dt:TDateTime;
mm,ss:Integer;
begin
dt:=time;
Label1.Caption:=TimeToStr(dt);
ttt:=ttt-1;
mm:=ttt div 60;//минуты
ss:=ttt mod 60;//секунды до ttt=0
StatusBar1.Panels[0].Text:=IntToStr(mm)+' мин '+IntToStr(ss)+' сек';
if ttt=1 then ttt:=200;
end; Время | CPU% | MEM%
0 час | 0,0 | 0,8
3 час | 0,7 | 0,8
5 час | 1,3 | 0,9
8 час | 1,3 | 0,8
18 час | 2,7 | 1,0
20 час | 3.3 | 1,1
Вообще 1 команду процессор всегда выполняет на максимуме шины скорости, т.е загрузка будет в этот момент будет всегда 100%.
Но есть исключения - режимы работы процессора когда он понижает скорость шины, переходит в режим ожидания, заморозки(hibernate) или даже выключает некоторые блоки ради экономии электроэнергии. Это регулируется на уровне ядра процессора или на уровне ядра оси. Оно может быть очень специфично даже на версиях ядра.
Рядовому юзеру сеё не доступно. Кроме как командой sleep/wait или регулированием привилегиями потока среди других потоков.
Поэтому регулировать CPU% - это абсурд.
Вообще CPU% - это среднее значение загрузки процика между двумя измерениями по времени.. т.е если приложение между t0 и t1 занимало 0,7% CPU времени то будет 0,7%. Но можно подсчитать и так - что CPU% -100% был 0,7% от расчетного T-время(допустим 1 минута) .
Рост CPU% - это второстепенный признак проблемы...
Есть задачи которые грузят CPU на все 100% и на долго - как пример та же крипта.
А вот увеличение MEM% может говорить об утечки памяти, и возможно при увеличении памяти растет объем вычислений - отсюда рост CPU%.
Добавлено спустя 13 минут 38 секунд:
3 ядра при 100% - в сумме дает CPU% 300% т.е. время когда целая система потела над задачами в три ядра занимает 300% общего времени CPU.. а могло и 6 ядер по 50%.. а могло 3 ядра по 100% и другие любые 3 ядра по 100%..
На западе продают виртуальные сервера где CPU% имеет ценик. CPU% -10% одна цена, а CPU% -20% уже другая..
Добавлено спустя 14 минут 59 секунд:
Вполне реально что грузит X/Window система. Запросы идут чаще чем скорость обновление на экране. или можно найти проблему даже в SQL движке, вдруг там реализовано "сбор мусора","подсчет сылок" или иного чуда прогрессивного и затратного вычисления. Который может давать рост потребления ресурсов системы.SQL либла вообще может иметь свой thread - который начало берет от общего для приложения и живет своей жизнью - а планировщик в итоге суммирует затраты CPU% и дает общий результат.
Вообще то если хотите разобраться в конец что происходит - вам нужно задействовать профилирование.
Но есть исключения - режимы работы процессора когда он понижает скорость шины, переходит в режим ожидания, заморозки(hibernate) или даже выключает некоторые блоки ради экономии электроэнергии. Это регулируется на уровне ядра процессора или на уровне ядра оси. Оно может быть очень специфично даже на версиях ядра.
Рядовому юзеру сеё не доступно. Кроме как командой sleep/wait или регулированием привилегиями потока среди других потоков.
Поэтому регулировать CPU% - это абсурд.
Вообще CPU% - это среднее значение загрузки процика между двумя измерениями по времени.. т.е если приложение между t0 и t1 занимало 0,7% CPU времени то будет 0,7%. Но можно подсчитать и так - что CPU% -100% был 0,7% от расчетного T-время(допустим 1 минута) .
Рост CPU% - это второстепенный признак проблемы...
Есть задачи которые грузят CPU на все 100% и на долго - как пример та же крипта.
А вот увеличение MEM% может говорить об утечки памяти, и возможно при увеличении памяти растет объем вычислений - отсюда рост CPU%.
Добавлено спустя 13 минут 38 секунд:
Владимир писал(а):откуда 300%
3 ядра при 100% - в сумме дает CPU% 300% т.е. время когда целая система потела над задачами в три ядра занимает 300% общего времени CPU.. а могло и 6 ядер по 50%.. а могло 3 ядра по 100% и другие любые 3 ядра по 100%..
На западе продают виртуальные сервера где CPU% имеет ценик. CPU% -10% одна цена, а CPU% -20% уже другая..
Добавлено спустя 14 минут 59 секунд:
Владимир писал(а):Вот эти выводы и грузят проц.
Вполне реально что грузит X/Window система. Запросы идут чаще чем скорость обновление на экране. или можно найти проблему даже в SQL движке, вдруг там реализовано "сбор мусора","подсчет сылок" или иного чуда прогрессивного и затратного вычисления. Который может давать рост потребления ресурсов системы.SQL либла вообще может иметь свой thread - который начало берет от общего для приложения и живет своей жизнью - а планировщик в итоге суммирует затраты CPU% и дает общий результат.
Вообще то если хотите разобраться в конец что происходит - вам нужно задействовать профилирование.
olegy123 писал(а):
Re: Linux: проект ест ресурсы процессора?
А вот увеличение MEM% может говорить об утечки памяти, и возможно при увеличении памяти растет объем вычислений - отсюда рост CPU%.
Утечка памяти на шести строках простого кода? Где рост объема вычислений? И нет в примере SQL-движка...
Про обновление Х-системы - возможно, но откуда рост?.
Скажу больше - если выводить время в Caption формы, а не в Label и не в StatusBar, то CPU и MEM СУТКАМИ в 0 и 0,8.
само оконное приложение - это не шесть строк, за LCL спрятано много кода, от инициализации X-окна, до создание примитивов. реализации системы сообщений, до MainLoop - что позволяет приложению жить.
Добавлено спустя 2 минуты 4 секунды:
Само Caption - это работа с bitmap-ом и Font. Инициализация, выделение места, загрузка шрифта, рисование на Caption текста, вывод в X.
Добавлено спустя 2 минуты 4 секунды:
Само Caption - это работа с bitmap-ом и Font. Инициализация, выделение места, загрузка шрифта, рисование на Caption текста, вывод в X.
чето мне кажется сама идеология пихания в таймер "тяжелого" кода (хоть это и всего несколько строк, но действий там оййойой сколько происходит и зависить они могут от кучи разных факторов) - неверна.
В таймере надо только "тикать" циферки в переменных, а отрисовку в данном случае производить в онидле, если с момента прошлой отрисовки прошел необходимый интервал времени
ИМХО
В таймере надо только "тикать" циферки в переменных, а отрисовку в данном случае производить в онидле, если с момента прошлой отрисовки прошел необходимый интервал времени
ИМХО
zub писал(а):чето мне кажется сама идеология пихания в таймер "тяжелого" кода (хоть это и всего несколько строк, но действий там оййойой сколько происходит и зависить они могут от кучи разных факторов) - неверна.
Можно, TTimer - это возможность реализовать многопоточное решение, при этом сам TTimer за синхронизирован с приложением. Ничего страшного тут нет.
Idle не решение всех проблем, как background обновление не всегда гуд, оно не многопоточное.. т.е. при тяжелых расчетах в нем - будет фризить все.
Можно выключить части - и опытным путем нащупать проблему, допустим отключить вывод SQL данных, загружать но не выводить. Если будет расти - то проблему искать в уже в реализации получении данных.
Добавлено спустя 7 минут 51 секунду:
Кстати, если запросы идут по TCP - то вполне возможно, это предположение - что сокеты висят. Вы их явно не закрываете, а SQLлибла их не тушит.. по спецификации они вообще могут висеть 2 суток ничего не делая.. До 2х у вас будет рост в памяти. потом нормализируется.. Это как игра - накормить питона..
Но это опять предположение