New peak traffic and XF has started running really slow or not at all on DO LAMP stack

Glad to hear it's working. Did anybody actually check to see what the problem was, just out of curiosity?
 
I don't know what the issue was. I suspect it was some kind of limit as it was running all fine and fast with loads of ram and cpu left, then all of a sudden once 1k were online pages wouldn't load or very slowly.

Only errors were the ones posted earlier.

Still it probably had several things wrong that were waiting to happen and wanted to move over to nginx anyway so seemed like the right time to do the switch. I didn't have time to troubleshoot.
 
Apache, tuned properly, can pretty much hold its own against Nginx. Nginx is much easier to configure to good performance though so good move :)
 
Why have all that memory doing nothing? Optimize your InnoDB settings to use 80% of your RAM and use query caching.

I use DO with block storage for all images and attachments and don't have any issues but I don't have nearly that many concurrent users. I do use Litespeed as well, which is a very fast alternative to Apache, especially for php setups.

You shouldn't have InnoDB using that much memory on a system with other services such as Apache/Nginx/PHP/Litespeed when expecting many processes. MySQL should only be given the bulk of RAM on a system with very large amounts of RAM, when it's a dedicated MySQL Server, or when MySQL is the primary process running with few other processes such as PHP.

Additionally, turn off the query cache. Do not turn it on, it will increase load during high concurrent usage. The query cache is single threaded and will block other queries while it's being searched. It was meant for performance back in the days when systems didn't have many CPU cores available. It's being deprecated and removed from MySQL. I believe it already has been in MariaDB 10.3+, not sure about MySQL as I don't follow them as closely.
 
You shouldn't have InnoDB using that much memory on a system with other services such as Apache/Nginx/PHP/Litespeed when expecting many processes. MySQL should only be given the bulk of RAM on a system with very large amounts of RAM, when it's a dedicated MySQL Server, or when MySQL is the primary process running with few other processes such as PHP.

Additionally, turn off the query cache. Do not turn it on, it will increase load during high concurrent usage. The query cache is single threaded and will block other queries while it's being searched. It was meant for performance back in the days when systems didn't have many CPU cores available. It's being deprecated and removed from MySQL. I believe it already has been in MariaDB 10.3+, not sure about MySQL as I don't follow them as closely.
Yep you are right, query cache isn't good for high concurrent connections. Has been great on my little site though, didn't know it was being deprecated though, I'll have to research that, thanks. Memory pool would be great though, maybe not such a high setting. It seemed he had moved to high RAM but wasn't taking advantage of any of it.
 
You shouldn't have InnoDB using that much memory on a system with other services such as Apache/Nginx/PHP/Litespeed when expecting many processes. MySQL should only be given the bulk of RAM on a system with very large amounts of RAM, when it's a dedicated MySQL Server, or when MySQL is the primary process running with few other processes such as PHP.

Additionally, turn off the query cache. Do not turn it on, it will increase load during high concurrent usage. The query cache is single threaded and will block other queries while it's being searched. It was meant for performance back in the days when systems didn't have many CPU cores available. It's being deprecated and removed from MySQL. I believe it already has been in MariaDB 10.3+, not sure about MySQL as I don't follow them as closely.
Yep you are right, query cache isn't good for high concurrent connections. Has been great on my little site though, didn't know it was being deprecated though, I'll have to research that, thanks. Memory pool would be great though, maybe not such a high setting. It seemed he had moved to high RAM but wasn't taking advantage of any of it.

The query cache is the devil's spawn. TURN IT OFF. It is only good for read only workloads and definately not high volume constantly changing workloads.

I just checked my my.cnf file and I turned it off in August 2011!
Code:
########################
# Query Cache Settings #
########################
## Turn it off 270811 ##
########################

query_cache_size                = 0
query_cache_type                = off

############################
# End Query Cache Settings #
############################

Thankfully Percona has removed it from their version of MySQL 8 :)
 
The query cache is the devil's spawn. TURN IT OFF. It is only good for read only workloads and definately not high volume constantly changing workloads.
For one of my applications that only updates data overnight, has very low concurrent users with some large data queries on a dedicated DB server with a lot of memory it's fantastic.
 
For one of my applications that only updates data overnight, has very low concurrent users with some large data queries on a dedicated DB server with a lot of memory it's fantastic.
Like I said, for largely read only workloads it is ok. Though the developers have now called time on a single mutex design in a multithreaded world. Good riddance.
 
They were moved to centminmod yesterday, and last night with over 900 online, the server load was 0.2 on a 4GB/2CPU droplet.
Is that normal? Isn't that crazy low for that many concurrent users? Do you mean 900 online in a day?
 
Top Bottom