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
Very slow after the latest 2023.05 update #13373
Comments
Checking the processes:
Nothing extreme |
Do you have any php fatals in your php error log? |
This is the log for the PHP https://paste.yunohost.org/febabileto I do not see any. |
Looking at the CPU it seems to spike up a lot. Close to 98% and we have tens of |
I will have to postpone this for a week or so. I need to do a presentation in 2 days and Friendica is one of the things I talk about, so I need to have a properly working Friendica. Thus I reverted back to an old friendica that works. As soon as I can I will do the update again and update this post. If there is anyone who can give me more tips that'd be lovely. THanks! |
I probably can´t help you :( But i experienced exactly the same behavior some Months ago when my Instance ran into a Post with some thousand activities. Actually i have some endless loops on my instance - but that shouldn´t be you problem because i don´t see php process reach max_memory and terminatet in your logs. Probably it is some Post your instance catched thats weird. I hope dev´s can help :) |
This is very interesting indeed....now that I know it happened to others too, it is something that perhaps we should detect as a bug somewhere. I will test it again in detail in a week or two. Thanks a lot for the comments! |
When you check in a week or so, please look at your ram - in both of my cases the ram got exhaustet very fast. |
Thanks! My RAM is doing fine, maybe the RAM that Friendica uses is limited? idk but we will check. |
I have installed it again. Same issues. Even if I should have a different feed of posts in my Network tab. For other accounts of mine that only follow a few people, the Network tab is fast. But for my account takes around 30 seconds. If I filter the feeds by groups, the "friends" group where I have most of my contact, takes many minutes to load.... I tested it with Tokodon, so basically an app, and everything loads super fast. So, same server, but different "interfaces". What does this say? I wonder if there are ways to try and improve the loading speeds for Friendica in general. |
It's tricky because highly customized queries (like on circles) are inherently more costly. I'm not sure why your network tab is slower, the number of follow shouldn't be an issue. Are you following accounts that mainly have long threads with dozens of replies? This would slow down the network tab significantly, as the page limit is only for top-level posts, after that we have to independently fetch the individual conversations' children. Try reducing the number of posts per page in your settings, it should make the network tab significantly faster. I know it did for me. |
Have you activated the slow query log for your SQL server? |
Oh yeah I had 40. Now 10 and it is a lot faster. Thank you. I wonder tho what is different now since before the update all loaded fine....
Not really...
No. But I am looking into it now. Thank you! |
This is what I am seeing:
More here https://paste.trom.tf/timezineza.yaml |
There it is, it shouldn't be that slow, but you can see it had to examine 31 million rows. @annando Index issue? |
It can't be an index issue, since it is running on other machines really fast. It would be an idea to have a look into the query using |
Would you mind telling me how to look into that? Also why would this only happen for the Network tab? I noticed it is even worse for the admin/federation. The rest is super fast... |
Please perform the following query manually using a MySQL client (either command line or GUI):
And report the full result. |
Thanks. Here:
|
Thanks, nothing looks wrong in this execution plan, it's using indices (or "keys") at every step, but maybe @annando has better insight. |
I can't have a deeper look, I'm still at work. I know that MariaDB has got different optimizers. Somewhere here in the issues someone tested and found out that using the old optimizer does help. I can't search for that issue in the moment. |
Perhaps this is the one you are referring to #11119 - I am doing Possibly this #11465 Trying stuff. |
I got a lot of
The process finished but no improvement. I will try to improve with the old mariadb optimize method if I managed to figure out how :D |
No, I meant the setting for the query optimizer. The query optimizer is the part of the SQL engine that tries to improve the query and decides which index to use: For an explanation see here: https://use-the-index-luke.com/sql/glossary/query-optimizer-query-planner There are different versions of the optimizer out there. I know that there is an issue, where someone found a switch that helped. But I don't find the issue at the moment. |
I think it is fixed now. Based on this comment #11465 (comment) Basically I edited the file
Now it seems to load in less than 4 seconds. Which is fantastic. I wonder if I need all of those variables in the database conf file, but so far so good. I will wait a bit then I can close this or maybe you can recommend me (us) better values for the conf file. I see others complain about the same issue - https://social.trom.tf/display/b42a482c-1164-fa3b-b83d-e9b342023432 |
Remove
In case you have services like Gitea or Facilmaps. It will kill them. So far Friendica is so fast it never has been so fast :D |
I am experiencing the same issue and this seems to fix it for me too. Still I'd like to learn the reason for the slowdown and how/what exactly fixes it. |
I am also curious how these configs will affect other services since these are the settings for the entire mariadb.... |
I guess you can boil down the changes to these two lines:
|
I have tested this, and it is not sufficient! It could be that there are two separate issues though, let me explain: When I first experienced the slowdown, I checked Firefoxes Web Dev Console to discover that a lot of images (jpegs, pngs) took about 1000-2000ms to load each. I attributed this to the avatar images and enabled the file based avatar cache. Long image load times where now gone, but I now had extremely long timeouts from JQuery trying to load something local (see attached image) As stated above, applying the mariadb config from #13373 (comment) Related question - where is the avatar cache supposed to be. I could not find the files and am therefore not sure it is really working. How to check? This might help to uncover the root of the issue because a non-working avatar cache would likely add to the long load times. |
@oe4dns whatever causes your problems, I guess that (like you already said) this is a separate issue, so I suggest to split it into separate issues. Putting too much into a single issues often causes long and clogged issues where at the end no one really knows if all issues have been solved. |
This is exactly what I am trying to do because I am definitely also having the very issue discussed here. So I have to somehow exclude the other one from interfering with my tests. |
I guess we can trial and error and see what values fix the issue. Since my instance has over a thousand users and I use it daily I can only do it late at night. Maybe @oe4dns you can test it? |
Well yes, I already did. And discovered the fact that I might have two separate issues. So I am currently trying to isolate them before I can do more testing |
Ah sorry ok I see. I will look further into this. |
I will also do so, in the evening |
I have now separated the two issues (mainly by disabling the file-based avatar cache, but that is another story) I can already report that only switching to the old optimizer does not help. Applying all other configuration changes without the optimizer settings also does not work. So the optimizer is indeed part of the issue. More testing will follow. |
I had a lot of trouble with the default settings for the query optimizer in the past. And those settings helped a lot to get better query plans with much faster execution. |
After after more testing I think I have found the culprit - or better the config option that speeds up reloads. Contrary to my former reports, switching to the old optimizer does not help! This has been a wrong observation caused by the fact that even if the correct config settings are made, the first reload is still slow. Subsequent reloads are much snappier. This is what I have now added to my
As you can see I reduced the buffer pool from 48G to 16G which still seems to be enough. I did not test other values. No other changes were necessary on my server to speed up the reloads. But only after the first reload which is still slow - I think it is filling the buffer at first load but this is just a guess. Commenting out this line leads to slow page loads again - this is reproducible. Please test. Maybe there can be a conclusion/solution for future friendica releases too. |
Well now let me ruin the party. For me only having
Does the job...everything is so fast is unbelievable. No other settings in the config does the job but this....
So yah....there we go. For me is different :D |
What is your mariadb version? I am running version 10.11 on Debian bookworm. In #13373 (comment) it was stated that there were performance issues with the query optimzier up to version 10.5 of mariadb - so maybe there's a reason. And regarding the innodb_buffer_pool_size - I am running a pretty low end system here - If you're on bigger hardware, maybe the cache is not an issue for you. These could be two different reasons with the same outcome - slow network page loads |
MariaDB version 10.5.19 |
Looks suspicious ;-) |
Yeah idk but the difference in speed is unbelievable with just those settings. It is almost instant.... Our server has an AMD EPYC 7282 16-Core Processor and 64GB of RAM. |
In my case setting the buffer size does not make it instant - reloads take a few seconds. But nowhere close to minutes as before. It is a dualcore vserver with 8G RAM. Switching to the old query optimiser settings does not improve it further. I missed this in my first tests, because the first reload still was slow. I'm pretty convinced that we have two issues here
Maybe this helps some of the devs to figure out what changed in 2023.5 that lead to these issues. There could even be a common cause. |
For me this is fixed. I will close. Please open a new issue if you need so. I think it makes sense. If not let me know and I will reopen. |
This is something so weird and I still do not understand it.
Context.
This is our instance https://social.trom.tf . Our database is around 30GB in size. We use a daemon for Friendica with these configs:
/etc/mysql/mariadb.conf.d/50-server.cnf
/etc/php/8.2/fpm/pool.d/friendica.conf
/etc/nginx/conf.d/social.trom.tf.d/friendica.conf
Basically I tried increasing the values for these. At times I got these logs for PHP FPM:
I increased these values now I do not seem to get these errors, for now, but nothing else improved.
Server stats:
The weird part is this: it is ONLY slow (takes minutes to load) if I try to access my own https://social.trom.tf/network - regardless what sub-sections I choose like (last posts, starred, etc.). The rest of the Friendica loads very fast. If I use other profiles where I have a lot less stuff in my newsfeed it loads faster, but still much slower than before.
I am baffled I do not know what more to try. My server should be capable o handling all of this, has plenty of resources.
I tried to optimize the database with
mysqloptimize -p friendica
and I get this:It gets stuck for a long time at
friendica.config
and seems to not continue.... And I get504 Gateway Time-out nginx
for the main url...Even more weird, before the update everything worked well for me and other people but for one friend it was again super slow when accessing the Network page. We also had a similar issue before, see #10916 - but now none of the fixes there seem to work.
Looking at the Network with an Inspector does not seem to point to anything suspicious:
I am baffled....
The text was updated successfully, but these errors were encountered: