-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High CPU usage (on newer Linux kernels?) #26851
Comments
Are you sure it's due to kernel? Telegram uses CPU for rendering (it's based on QtWidgets, only media viewer has GL code) and there are lots of animating parts appeared during times, especially if you have emoji/sticker selector opened all the time (#25952). |
@ilya-fedin Well, I'm sure because the software base is the same on both installations. It's a rolling distro, both HDDs are identical. The only difference is the kernel version. I also don't use emoji selector and it's never opened. |
I mean the older installation likely has an older tdesktop that doesn't have those animations supported. Those animations aren't only in the emoji selector, they could be in chats and even in chat list. You can disable various animations in battery saving options and see whether it helps. |
@ilya-fedin I check and update Telegram manually via Settings on both installations (not from repositories). |
@ilya-fedin It's up-to-date on both installations. I've tried the previous version too (4.9.9) but it's the same. |
Ah, indeed. I'm highly doubt it's due to kernel though (and then it's undebuggable, at least there's no one here who have respective experience), can you try disable animations in battery saving? So far all reports about CPU usage were due to animations even if reporters were saying they're sure it's not. |
@ilya-fedin Everything is disabled since I don't like animations and stuff like that. |
Well, I just don't know what else to blame actually. I'm lost. |
@ilya-fedin It happened before (high CPU usage), but it was long ago already. It either tried to download all history or something, thus giving CPU a bad time. |
@ilya-fedin Oh! I waited for a minute or two and the CPU is now normal. So, we have something already. The CPU is high for a couple of minutes (like it was several versions ago) and comes back to normal. |
Does 100% CPU usage goes for a long time? If yes, you can send SIGABRT to the process and it would generate a crash dump where it's possible to see what it does at each thread at the moment. Don't forget to enable beta for the crash reporter and copy crash ID before sending the crash report. |
@ilya-fedin Well, I closed Telegram and opened again. It's normal now. It really tried to download something from the history I guess, but couldn't. If I closed it midway it gave high CPU usage again after starting it for a second or third time. But now, after letting it "do something" in the background, it's now normal on new restarts. Strange. |
So, I guess, it was a profile issue. I also cleaned my temporary storage via Advanced settings. This happens from time to time with other programs like Firefox etc. I'm not sure who's fault this is. I'll close the issue. |
@ilya-fedin Though it works I see a lot of segfaults in dmesg when closing Telegram, like this:
|
Yeah, there's memory corruption somewhere on quit so it crashes randomly in allocator... |
@AngryPhantom Maybe it was initial emoji generation in the background? Theyre cached once ready. Although two minutes is a bit much for that. |
@ilya-fedin
|
@john-preston It could have been one minute, it just seemed really long. Probably you're right about emoji caches or something. Anyway, it seems okay now. |
These logs with codes tell nothing to me |
I guess he meant it should be multiple seconds |
Well, it didn't load CPU on another installation at all. |
Ok, you can try to clear the "/home/satellite/.local/share/TelegramDesktop/tdata/emoji" folder (it should have multiple "cache_XX_Y" files) and then launch the app again and see if it again burns the CPU while filling up this cache and then stops doing that when it is filled again. But on my laptop even on a big interface scale i takes around 3 seconds to build up the cache. Taking one thread only, so having less than 10% of CPU usage. |
@john-preston Yeah, that's it! Emoji cache is the culprit for some reason. After cleaning, it took a minute and 15 seconds to rebuild the cache, loading the CPU at 100%. |
wow, that's harsh.. I'm surprised it works more or less ok otherwise, given the difference in this emoji caching performance for my case and yours All it's doing is opens huge webp image (that has thousands of 72x72 emoji images) and scales smoothly them one by one to required size, writing back much-less-but-still-huge images with full emoji atlases to the disk as cached copies. This is how they work, I'm not sure this is going to be somehow changed anytime soon. |
@john-preston Thank you very much for the info. Anyway, I'm glad it works fine after rebuilding the cache. |
Maybe it's due to HDD rather than SSD? |
@ilya-fedin You'll be surprised but I'm the one who haven't used SSD yet :) I have a pretty old machine: 4 GB RAM, AMD Athlon II X2 245 CPU and several HDDs. |
You closed the issue on your own, so GitHub should let you to reopen it. And then you can give the issue a better naming given that it's not related to kernel after all. |
@ilya-fedin Yes, I know. I closed the issue because it resolved itself somehow. Let's just chalk it up to some random bug and that's all. If it occurs again or persists in the nearest future I'll investigate it more thoroughly and create a more relevant issue name. |
Well, then it's just the amount of computation it takes to cache the emoji. This is expected to happen once each time I update the supported emoji internal, it happens once every new Unicode standard is released and all four emoji sets that are used in TDesktop are updated to that standard. They add some new emoji and the cache is rebuilt when a new version is installed. So this will happen later from time to time, approximately once a year or so. |
@john-preston Oh, didn't know that. Then the puzzle is solved! Thank you very much again. |
Steps to reproduce
I'm experiencing a very high CPU usage on Arch Linux. I'm not sure if it's connected with newer kernels (6.5.2 currently) but it's like constantly 100% of any of my two CPU cores.
Yesterday I did a fresh install of Arch on another HDD (a clean and fresh system, to test newer kernels etc.). I didn't even expect there could be such an issue.
I also have an older installation with an LTS 5.15 kernel on another HDD, and there is no problem. The CPU is idle.
P.S. I have conky on my desktop so I instantly notice odd system behavior. You can also start htop and then Telegram and see it yourself.
P.P.S. I have disabled Hardware acceleration and OpenGL rendering in the Settings. But it doesn't fix the issue if I enable them.
Am I the only one with this issue?
TIA
SOLVED and CLOSED (see below).
Expected behaviour
Normal CPU usage
Actual behaviour
100% CPU usage
Operating system
Arch Linux
Version of Telegram Desktop
(4.9.9 or 4.10.0)
Installation source
Static binary from official website
Crash ID
No response
Logs
SOLVED: This can be an expected behavior when a new emoji set cache is being updated.
The text was updated successfully, but these errors were encountered: