High CPU load #3640
Comments
|
Same problem on i7/macOS Sierra/tdesktop 1.1.10 |
|
I can reproduce this problem too on Ubuntu 16.04 (laptop) |
|
I had the same problem here, i7 desktop, and a laptop, both with Fedora 25. |
|
I've noticed this too on Ubuntu, even more so when someone is typing a message/just posted it seems to spike up. Which is especially problematic when gaming. |
|
Same here. |
|
Is there a way we could help the developers debug the issue? It seems like it's not OS or build specific.. |
|
@kmare Is Sticker/GIF panel enabled? Is something playing? Are there any GIFs on screen? What if you defocus the app? |
|
@stek29 No, the sticker/gif panel is hidden, nothing is playing, no gifs on scree. Moving the focus off the app won't help either. The only way to kill all these QThreads is to quit the app and restart it. So yeah, unfortunately I still haven't figured out what's causing the spawning of all these QThreads causing the high cpu load. At this moment, it looks so random as it could happen after a few minutes or a day. |
|
I was basically facing the same issue of high cpu load, as high as 140% on mac osx sierra with latest telegram desktop update (1.1.10 as of now) but I've had this issue on previous versions too, after digging for a little bit I found out that my local storage has caused an integer overflow (2244). |
|
@silverfoxy that's actually interesting. I checked my local storage and it seems fine though. So I guess, at least in my case, it has to be something else. Thank you for reporting that though! |
|
same problem in ubuntu 14.04 and 16.04. |
|
Same here on Debian (Sid) 32bit on a Thinkpad T42p, Telegram takes more and more and more CPU after a (short) while. Tracing the process does not show much more than endless calls to This is a relatively recent problem, it started about a month ago. Earlier versions did not show this behaviour. |
|
I attached a running Telegram process to Then I happened to move the pointer over that #%#¤&/%/%/ smiley button which I'd rather ditch yesterday than today. The blasted popup appeared again with a hoard of moving GIF images. I clicked outside of it to get rid of the dreaded things and had a look at the trace. 5 new threads had been launched and the trace was going wild, suddenly Telegram was hogging 25% CPU. Mind, the popup was gone, no moving images in sight, all peace and quiet on the surface. Below the surface it seems some QThreads were busy doing something anyway, something which took a lot of CPU. Then I switched the horrible emjoistickergif popup to the 'emoji' tab and closed it. The CPU hoarding stopped. Switched back to the moving misery, closed popup, NO CPU HOARDING. Switched back and forth a few times, sometimes it started hoarding CPU, other times it didn't. The interesting observation is that I never got any hoarding problems when the popup was set to 'emoji' or 'stickers' but did get it when the thing was set to 'gifs'. |
|
@Yetangitu thank you for "discovering" that! I'll take a look at that too and see if this is what is causing the 100% CPU load with telegram spawning all these QThreads. |
|
I can confirm what @Yetangitu said! It really works! So basically, as soon as you see the CPU load going up cause of telegram, just click on the emoji/stickers/gifs icon once, click on it again and the telegram CPU load will go back to where it should be idling! If anyone else could confirm, please do so. Hopefully the developers will find a solution. |
|
From my observations it is enough to make sure that the popup is not set to 'gifs' before it is closed to avoid Telegram hogging the CPU. I have not seen any hogging since doing this. |
|
Same on High Sierra Mac OS, but 1.1.13alpha takes much less resources. |
|
@sstyle Please try the current version, v1.2.6. |
|
This is just Telegram using your computers resources to create the first batch of TelegramCoin, the new cryptocurrency. Nothing to be worried about. |
|
@pizzadude Nice. So we can close this thread ) |
|
happened to me just now steps to reproduce: mac 10.13.3 i hope telegram didnt start using our PCs for Gram mining 🤔 |
|
Same problem and I'm trying to fix it. Try turning off all notifications. So far I think it's not going crazy anymore. |
|
I am using v1.2.6. What I saw that if telegram runs, CPU load is very high, it consumes 70% of CPU time. The only way to stop this is to minimize telegram window. If you just switch to other app, but leave it on screen, even if it's completely overlayed by another window, it won't help, only minimization helps. Host OS: OS X 10.12.6 |
|
On Linux (Debian 10.3), the Telegram process is constantly polling, even though the UI is not animated and no message is sent nor received, as can be seen with this strace output: $ strace -p `pidof Telegram`
strace: Process 25205 attached
restart_syscall(<... resuming interrupted poll ...>) = 0
recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18, events=POLLIN}], 6, 8) = 0 (Timeout)
recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18, events=POLLIN}], 6, 7) = 0 (Timeout)
recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18, events=POLLIN}], 6, 8) = 0 (Timeout)
recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18, events=POLLIN}], 6, 7) = 0 (Timeout)
<...>
recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18, events=POLLIN}], 6, 7) = 0 (Timeout)
recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18, events=POLLIN}], 6, 8) = 0 (Timeout)
recvmsg(17, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN}, {fd=12, events=POLLIN}, {fd=14, events=POLLIN}, {fd=17, events=POLLIN}, {fd=18, events=POLLIN}], 6, 7) = 0 (Timeout)
recvmsg(17, ^Cstrace: Process 25205 detached
<detached ...> |
|
@loicmolinari due to the nature of this ticket it's not really monitored, but if you can write up clear reproduction steps and open up a new ticket, that'll have better chances |
|
FIX IT |
While I agree with the idea that it would be good to fix bugs, I disagree with the way the demand is stated. Did you forget the magic word? |
|
in this situation on amount of "please" would help, as @loicmolinari still needs to provide repro steps |
Still, it would improve the discourse for no cost at all. I don't know whether @loicmolinari gets paid to work on this project but - this being GH - I generally assume most people around here are volunteers. When I volunteer to do something I tend to dislike being commanded to FIX SOMETHING... |
|
i've released so much open source and my experience says: don't make a fuss of it unless it is targeted harrassment, as the fuss always tends to be bigger than the event itself. :) |
He just wrote a comment with strace as an affected user, isn't it? o_O |
Let's rewrite the whole animation engine, do a good deed for everyone! |
|
Hey there! This issue will be automatically closed in 7 days if there would be no activity. We therefore assume that the user has lost interest or resolved the problem on their own. Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue. Thanks! |
Mate, no one is going to play nice, people begged for years and no one did stuff, if you are 3rd rate dev looking to beef up your student CV and half-assedly do it then do people a favour and don't. A professional organisation will take it under its wing. |
A race condition in the animation manager can let a dangling timerEvent() callback fired at a high frequency (>120 FPS) in the main loop even though there is no active animations. An update of the animation manager returns directly when there is no active animations. If there is at least a single active animation, it stops the timer and schedules a new update before updating animations. Depending on the Integration implementation, the scheduling call can be postponed after the current update. The actual postponed call unconditionally schedules an update by starting the timer. The issue is that in the mean time the last remaining animation could have been removed and when the timer callback would be fired, the update would return directly (since there is no active animations) without being able to stop. The explanation above ignores the updateQueued() cases of the postponed call for simplicity. These cases do not result in infinite updates like the timer case but still imply one useless (invoked) update. This fix adds a condition in the postponed call ensuring there is at least a single active animation before processing. telegramdesktop/tdesktop#3640 telegramdesktop/tdesktop#4854
A race condition in the animation manager can let a dangling timerEvent() callback fired at a high frequency (>120 FPS) in the main loop even though there is no active animations. An update of the animation manager returns directly when there is no active animations. If there is at least a single active animation, it stops the timer and schedules a new update before updating animations. Depending on the Integration implementation, the scheduling call can be postponed after the current update. The actual postponed call unconditionally schedules an update by starting the timer. The issue is that in the mean time the last remaining animation could have been removed and when the timer callback would be fired, the update would return directly (since there is no active animations) without being able to stop. The explanation above ignores the updateQueued() cases of the postponed call for simplicity. These cases do not result in infinite updates like the timer case but still imply one useless (invoked) update. This fix adds a condition in the postponed call ensuring there is at least a single active animation before processing. telegramdesktop/tdesktop#3640 telegramdesktop/tdesktop#4854
A race condition in the animation manager can let a dangling timerEvent() callback fired at a high frequency (>120 FPS) in the main loop even though there is no active animations. An update of the animation manager returns directly when there is no active animations. If there is at least a single active animation, it stops the timer and schedules a new update before updating animations. Depending on the Integration implementation, the scheduling call can be postponed after the current update. The actual postponed call unconditionally schedules an update by starting the timer. The issue is that in the mean time the last remaining animation could have been removed and when the timer callback would be fired, the update would return directly (since there is no active animations) without being able to stop. The explanation above ignores the updateQueued() cases of the postponed call for simplicity. These cases do not result in infinite updates like the timer case but still imply one useless (invoked) update. This fix adds a condition in the postponed call ensuring there is at least a single active animation before processing. telegramdesktop/tdesktop#3640 telegramdesktop/tdesktop#4854
A race condition in the animations manager can leave a dangling timerEvent() callback firing at a high frequency (>120 FPS) in the main loop even though there is no active animations. An update of the animations manager returns directly when there is no active animations. If there is at least one active animation, it stops the timer and schedules a new update before updating animations. Depending on the Integration implementation, the scheduling call can be postponed after the current update. The actual postponed call unconditionally schedules an update by starting the timer. The issue is that in the meantime the last remaining animation could have been removed and, when the timer callback would be fired, the update would return directly (since there is no active animations) without being able to stop. The explanation above ignores the updateQueued() cases of the postponed call for simplicity. These cases do not result in infinite updates like the timer case but still imply one useless (invoked) update. This fix adds a condition in the postponed call ensuring there is at least one active animation before processing. telegramdesktop/tdesktop#3640 telegramdesktop/tdesktop#4854 telegramdesktop/tdesktop#5436
A race condition in the animations manager can leave a dangling timerEvent() callback firing at a high frequency (>120 FPS) in the main loop even though there is no active animations. An update of the animations manager returns directly when there is no active animations. If there is at least one active animation, it stops the timer and schedules a new update before updating animations. Depending on the Integration implementation, the scheduling call can be postponed after the current update. The actual postponed call unconditionally schedules an update by starting the timer. The issue is that in the meantime the last remaining animation could have been removed and, when the timer callback would be fired, the update would return directly (since there is no active animations) without being able to stop. The explanation above ignores the updateQueued() cases of the postponed call for simplicity. These cases do not result in infinite updates like the timer case but still imply one useless (invoked) update. This fix adds a condition in the postponed call ensuring there is at least one active animation before processing. telegramdesktop/tdesktop#3640 telegramdesktop/tdesktop#4854 telegramdesktop/tdesktop#5436
A race condition in the animations manager can leave a dangling timerEvent() callback firing at a high frequency (>120 FPS) in the main loop even though there is no active animations. An update of the animations manager returns directly when there is no active animations. If there is at least one active animation, it stops the timer and schedules a new update before updating animations. Depending on the Integration implementation, the scheduling call can be postponed after the current update. The actual postponed call unconditionally schedules an update by starting the timer. The issue is that in the meantime the last remaining animation could have been removed and, when the timer callback would be fired, the update would return directly (since there is no active animations) without being able to stop. The explanation above ignores the updateQueued() cases of the postponed call for simplicity. These cases do not result in infinite updates like the timer case but still imply one useless (invoked) update. This fix adds a condition in the postponed call ensuring there is at least one active animation before processing. telegramdesktop/tdesktop#3640 telegramdesktop/tdesktop#4854 telegramdesktop/tdesktop#5436
|
Hi, I am having 70% High CPU Load on MacOS Big Sur. I think it might because I joined too many groups. Is there a built-in cpu usage tool in telegram so that I knew which group is using the highest CPU, then I can leave that group? Thanks a lot. |
|
I had the same problem here, i5 a laptop, with Big Sur 11.2.3 |
Uninstall this app and install |
|
@sgon00 It is official Telegram app for macOS, everyone can download it here: https://macos.telegram.org/ |
Yeah, I knew. But it's a different project so I feel it's not polite to introduce it in this project. :) |
|
@sgon00 Thanks. I've posted for everyone who reads here, it's just there is no way to reply without a mention using the GitHubBot. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
and others
Steps to reproduce
Expected behaviour
It shouldn't spend all that CPU load
Actual behaviour
It just consumes CPU time till the program is restarted
Configuration
Operating system:
Fedora Linux 25 on one i7 laptop and one i5 desktop. Same thing on an Ubuntu 16.04 laptop.
Version of Telegram Desktop:
1.1.11 (previous versions too. IIRC 1.0 was ok)
Used theme:
Any theme
Logs:
Insert logs here (if necessary)running: top -H -p will return:
top - 19:57:37 up 4 days, 21:42, 1 user, load average: 0.83, 1.34, 1.37
Threads: 20 total, 1 running, 19 sleeping, 0 stopped, 0 zombie
%Cpu(s): 9.3 us, 0.7 sy, 0.0 ni, 89.0 id, 0.1 wa, 0.5 hi, 0.3 si, 0.0 st
KiB Mem : 16291228 total, 3390260 free, 5596580 used, 7304388 buff/cache
KiB Swap: 8191996 total, 8191996 free, 0 used. 8155060 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5470 smee 20 0 2686276 653620 100172 S 10.3 4.0 8:19.68 QThread
13349 smee 20 0 2686276 653620 100172 S 9.0 4.0 7:38.81 QThread
13346 smee 20 0 2686276 653620 100172 S 7.7 4.0 6:25.81 QThread
5471 smee 20 0 2686276 653620 100172 S 6.7 4.0 5:41.01 QThread
5482 smee 20 0 2686276 653620 100172 S 6.0 4.0 5:39.49 QThread
13348 smee 20 0 2686276 653620 100172 S 4.7 4.0 3:56.05 QThread
4829 smee 20 0 2686276 653620 100172 R 4.0 4.0 4:22.86 QThread
13347 smee 20 0 2686276 653620 100172 S 3.7 4.0 3:12.62 QThread
27411 smee 20 0 2686276 653620 100172 S 1.7 4.0 22:55.85 Telegram
27412 smee 20 0 2686276 653620 100172 S 0.0 4.0 0:33.49 QXcbEventReader
27413 smee 20 0 2686276 653620 100172 S 0.0 4.0 0:06.78 QDBusConnection
27415 smee 20 0 2686276 653620 100172 S 0.0 4.0 0:13.68 Qt bearer threa
27416 smee 20 0 2686276 653620 100172 S 0.0 4.0 0:00.00 gmain
27417 smee 20 0 2686276 653620 100172 S 0.0 4.0 0:00.08 gdbus
27432 smee 20 0 2686276 653620 100172 S 0.0 4.0 0:00.20 QThread
27433 smee 20 0 2686276 653620 100172 S 0.0 4.0 0:01.95 QThread
27434 smee 20 0 2686276 653620 100172 S 0.0 4.0 0:00.00 QThread
27436 smee 20 0 2686276 653620 100172 S 0.0 4.0 0:06.02 MTP::internal::
4205 smee 20 0 2686276 653620 100172 S 0.0 4.0 0:00.00 Qt HTTP thread
27321 smee 20 0 2686276 653620 100172 S 0.0 4.0 0:00.00 Qt HTTP thread
The text was updated successfully, but these errors were encountered: