It's hard to recommend a bunch of specific things since the problem could be one of many different issues. You could try running top in a terminal while steam is running and see if the CPU usage or memory consumption of Steam changes significantly. There are various profilers you could use, like Zoom, but the output would be complex. strace might show a lot of activity, but it will always show quite a few things so knowing what's significant is hard. It will most likely mean that we'll need to find a repro here at Valve, and that can be difficult when it's configuration-specific.
One other thing: if you exit Steam after the slowdown does the computer go back to regular performance?
If I remember correctly, it does. The last time I had this issue (today), it was bad enough that I had to hard reset. I've done some strace-ing (-o -ff -r -v -x -T options) without activating products, and I would willing to do it again while activating products. If there are any specific options you would like me to run it with, I can do that too. For the greater good!
Side note: I tried to use strace+ (adds stack calls), but it kept throwing errors at me.
I don't think you need -v as I don't expect the problem to be related to the calls it affects, but the other options are great. It might be as simple as a memory leak (we have other bugs open on leaks and we have not been able to pin down a repro) so just watching top may show growth in memory (or it'll show excessive CPU use).
Thanks for giving it a try.
Awesome. I'll get back to you on those. If I could get strace+ working, would that be even better? Or would the added functionality not be that useful for you guys?
Also, would you prefer it all in one file (-f) or have the child processes in separate files (-ff)?
I don't think we need stacks as there shouldn't be a lot of symbols in the shipped binaries. There shouldn't really be a lot of child processes unless you start games, so just go with -f for simplicity.
Well I decided to do an strace with just -f and got a file about 1.5gb in size. All I did was activate a key and put a game in my inventory into my library. And just now, I decided to test and see what the output (file-wise) would be for -ff and got about 130 pid-specific files, just from connecting to my account, etc (full window hadn't even popped up yet). What do?
I would forget about strace for the moment and just see if you see trends in top's memory and CPU usage numbers.
Did a sort to get the calls taking the longest and got this:
0.268265 futex(0x9b3e764, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000061>
0.269557 close(3) = 0 <0.000059>
0.276991 futex(0x9b3e764, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000148>
0.279587 futex(0xacb34bc, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000058>
0.280430 semop(458755, {{0, -1, IPC_NOWAIT}}, 1) = -1 EAGAIN (Resource temporarily unavailable) <0.106797>
0.292761 futex(0x9b3e764, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000055>
0.335466 futex(0x9a4340c, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000064>
0.474691 mprotect(0xb1f5b000, 18800640, PROT_READ|PROT_EXEC) = 0 <0.000150>
1.108035 futex(0x9a4340c, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000053>
1.340111 semop(458755, {{0, -1, IPC_NOWAIT}}, 1) = -1 EAGAIN (Resource temporarily unavailable) <0.000062>
And when I searched for the exact line of that last semop, I found a huge block of semops and nanosleeps. Does this help in any way, or is this normal?
I also used LZMA to get the 1.5gb file down to a manageable 80mb. It'll still explode out to 1.5gb for whoever has/wants to dig through it, but transferring will be easier, at least. Just if you want it, that is.
I also have a perf.data file that's about 90mb, if you want that.
I won't be able to look at this for a week, but thank you very much for gathering the data.
From: David Nivens
Sent: 3/8/2013 9:43 AM
To: ValveSoftware/steam-for-linux
Cc: Drew Bliss
Subject: Re: [steam-for-linux] Activate a Product causes slow down (#2111)
Did a sort to get the calls taking the longest and got this:
0.268265 futex(0x9b3e764, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000061>
0.269557 close(3) = 0 <0.000059>
0.276991 futex(0x9b3e764, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000148>
0.279587 futex(0xacb34bc, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000058>
0.280430 semop(458755, {{0, -1, IPC_NOWAIT}}, 1) = -1 EAGAIN (Resource temporarily unavailable) <0.106797>
0.292761 futex(0x9b3e764, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000055>
0.335466 futex(0x9a4340c, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000064>
0.474691 mprotect(0xb1f5b000, 18800640, PROT_READ|PROT_EXEC) = 0 <0.000150>
1.108035 futex(0x9a4340c, FUTEX_WAKE_PRIVATE, 1) = 0 <0.000053>
1.340111 semop(458755, {{0, -1, IPC_NOWAIT}}, 1) = -1 EAGAIN (Resource temporarily unavailable) <0.000062>
And when I searched for the exact line of that last semop, I found a huge block of semops and nanosleeps. Does this help in any way, or is this normal?
—
Reply to this email directly or view it on GitHubhttps://github.com/ValveSoftware/steam-for-linux/issues/2111#issuecomment-14629661.
I've been taking a look and the semop/nanosleep stuff is most likely the culprit. Unfortunately it is also in some code from an older content system that's being phased out and so is not being actively worked on so there's no easy fix.
If you have more keys to redeem, as a confirmation can you look at the output of 'top' when you redeem and see if steam's usage goes to 100%? The semop/nanosleep is most likely causing a thread to spin and use all of your CPU and you'll see that in top. This is purely optional as, sadly, it won't make a fix come more quickly.
Well, I topd it and I noticed that whenever Steam isn't visible on my screen, CPU floats around 4-5% and MEM around 30%. But whenever I bring it up to the foreground, CPU shoots up to about 30-35%. And whenever I force it to redraw in some way (hovering over or clicking on a menu item, it sometimes shoots up to even 80%CPU. But once I minimize it or put it in the background, it goes back down to that original 5%. When I do the activation, it shoots up all the way, but that may only be because of all the redrawing being done. Not sure if this is Steam specific, DE specific, or computer specific (as I have no proper graphics card, it being a netbook).
I've been keeping top always visible, and I've noticed that the MEM doesn't change as much as I had originally thought.
When doing activation and it went to 100% did it stay there indefinitely?
If I remember correctly, it went back down (to the "foreground CPU") after finishing the activation.
You're no longer seeing the original problem, then? It's expected that activity will increase during activation and decrease after.
Seems that way...
When I activate keys from bundles (Humble Bundle, IndieGala, etc), usually done all at once, Steam (and the rest of my computer) slows down. This doesn't just happen while the activation window is open. It continues even after the window has been closed, even if no games are downloading. I have noticed this on my desktop, but especially on my netbook. On my desktop, it is manageable, but since Steam already runs poorly on my netbook (I mainly use it to activate products when I'm away from my desktop), it causes my netbook to freeze up entirely. If there is some command I can run (or program I can install) that will give you guys a better look at what is happening, I'm up for it. I have a few more keys I need to activate still, so I'll wait on a response.