User profile images loading slowly, failing to load

Not sure if something you changed with the fuzzy image loading is being applied to user profile pictures, but I’ve noticed that after upgrading to 2.2.0.beta7 quite a few user images are either failing to load entirely (leaving just an empty white space) or are loading very, very slowly.

As seen here: https://share.otf.ca/

5 Likes

Never mind, I can’t seem to reproduce the issue. :man_shrugging:

Happened to me too, then recovered. You weren’t going crazy :slight_smile:

Same issue with me

Installed

[v2.2.0.beta7 +12]

(https://github.com/discourse/discourse/compare/b089ac1537d47624fe690eacc14106c16138a3ae...tests-passed)

3 Likes

Hmmm I noticed a couple issues upon upgrading and saw this in the error logs:

‘hijack user_avatars show’ is still running after 90 seconds on db default, this process may need to be restarted!

I wonder if this is related…either a bug or just a background process that takes a really long time?

https://meta.discourse.org/t/2-2-0-beta7-upgrade-errors-posts-not-getting-marked-as-read-admin-dashboard-not-loading/105602

I’m having the same issue right now having just updated. Presuming and hoping it will go away by itself. Caching and all that.

Is it just me or do they look loads better?

1 Like

Ok it fixed itself :+1:

Hmm clearer??

1 Like

I’m also getting the 'hijack user_avatars show' is still running after 90 seconds on db default, this process may need to be restarted!

rebuilding from the command line made this problem go away for me… I left it for a few hours and it did not go away on its own.

This is not clearing up on it’s own for me. I did a rebuild and that did not help either. Here is the backtrace…

/var/www/discourse/vendor/bundle/ruby/2.5.0/gems/logster-1.3.4/lib/logster/logger.rb:101:in `add_with_opts' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/logster-1.3.4/lib/logster/logger.rb:52:in `add' /usr/local/lib/ruby/2.5.0/logger.rb:545:in `error' /var/www/discourse/lib/scheduler/defer.rb:92:in `block (2 levels) in do_work' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/message_bus-2.2.0.pre.1/lib/message_bus/timer_thread.rb:110:in `do_work' /var/www/discourse/vendor/bundle/ruby/2.5.0/gems/message_bus-2.2.0.pre.1/lib/message_bus/timer_thread.rb:38:in `block in initialize'

This issue should auto correct itself after a bit, we needed to rebuild all resized avatars so it could take a while to happen.

6 Likes

Thanks Sam. This does seem to be improving (but not yet finished) on our site. Just taking much longer than I’d think it would to rebuild avatars. Like, several hours for just a couple thousand users. That’s w/ the $10/mo Digital Ocean droplet…looks like it’s maxed out our CPU for going on 5 hours :sweat_smile:. Not sure if that’s about in line w/ what you’d expect, just FYI.

4 Likes

High CPU is very unlikely to be Avatar related, there was another change that was committed:

This can eat up the entire sidekiq queue for a while. It will clear up but depending on your post count it may take a bit.

9 Likes

Would it be a good idea to add this kind of events when you release the new beta version posts from #feature:announcements so that nobody will go OMG my forum iz now broken!!! PANIC!!! ?

Something like
Deploy attention:

  • because of <commit here>, after you upgrade your discourse all posts containing images will be rebaked so your forum will be a little slow for a while.
  • because of <meta post here>, after you upgrade avatars will be a little bit slow to show but it will go away in a few hours.
3 Likes

Yeah @jomaxro can add a note to next beta (which is when this officially lands) informing people to expect high CPU usage for a few hours after this upgrade due to image re-optimization.

I tweaked this today a fair bit to avoid queue starvation and issues where avatar resizing was taking way too long, but you should expect a reasonable CPU jump temporarily while stuff is catching up.

We basically needed to go to every post with images and rebake, then resize all the images. Plus resize all the avatars.

We did this cause our new algorithm for resizing is far more efficient. Plus you get retina image support and “fuzzy” image while it loads on old posts.

9 Likes

We have over 500,000 uploaded images that need to be reprocessed, so we’re looking at about 2 months of reprocessing. I’ll need to be very careful when deploying this change, I’m not too excited about it, tbh.

5 Likes

If you must you can run a 1 liner to disable the rebake

Great! Can you share that with me please?

I see the convert task is working away in htop still after 24 hours, but making progress. Is there any way to know how much longer this will take? Is there a way to de-prioritize the task so my site is not brought to its knees while this is going on? Quite a painful upgrade.

4 Likes