I've got a WP database with approx. 10k+ posts. Everytime a user saves / posts (insert or update query), apache server CPU spikes to 100% and MySQL spikes to 100% CPU usage, eventually crashing. I'm assuming the culprit here is MySQL, however there are zero errors in the log and there are no relative slow query log. The wp_posts table is myisam based and not innodb (using full text search). Could this be a configuration issue with myisam?
Specs:
Wordpress: 3.4.2
Server: Amazon EC2 Small Instance (1.7gb ram, 40% free)
Thanks,
Mike
Issue determined: It was a plugin. Make sure you always test out your plugins!
Related
I’m trying to determine a MySQL / Web server bottleneck.
I have three servers. A Web server running Nginx, a remote MySQL server with my Wordpress DB and another remote MySQL server storing our data.
The bottleneck I’m trying to find is between my second MySQL server storing our data and my Web server.
We have a page that has three DataTables on it (three separate queries). It’s loading very slowly, if it does all. Occasionally I’ll get a gateway time out error.
I don’t think the queries themselves are the issue. From DataGrip all three average between 200-500ms. Currently the queries aren’t indexed as I’ve been told the plugin cannot take advantage of indexes, but I might try anyways.
Hardware and Setup:
My MySQL server is an AWS R6G.Large, 2 cores and 16gb ram, SSD of 150 IOPS and 128 MB throughput. innodb_page_size is 32, buffer_pool_size is 11000M, innodb_buffer_pool_instances is 10 and innodb_log_file_size is 1G
Web server is an AWS C6G.Xlarge, 4 cores and 8gb ram, SSD of 150 IOPS and 128 MB throughput. Uses FPM and Opcache.
I’ve tried monitoring using TOP on both servers, but to be honest I’m not sure I have knowledge to properly utilize the information.
I’d really like to determine if it’s hardware or software, somehow, and if it’s hardware is there a way to isolate? I have no problem increasing hardware if that’s actually the problem.
I’m not sure if this is allowed on Stack, but I figure it might be easier to know what’s going on if I record my screen with TOP running on both servers. I added a video to my public Google Drive. The video has both my MySQL server (on the top) and Web server (Nginx, on the bottom). What I did was load the page (3sec mark in video) and recorded the outcome. The video is 1:05, which how long it took for the last table to appear. The video was recorded while my site was in maintenance, so no other IP / traffic could reach either server.
My google drive link:
https://drive.google.com/drive/folders/1NtdE1Z4875i1Xx2Wy2EXGgknt9yuY1IN?usp=sharing
Hopefully someone can help.
Aimee
we're using MySql on CloudSql for quite some time now.
Obviously, we started with Mysql 5 but after a long wait and the final release of Mysql8 we decided to upgrade our database server.
As the title promotes, we now see a strange behavior of our memory utilization.
As you can see here it constantly fills up until server max resources are reached and then restarts and start filling up again.
I mean there could be an issue with one of our services but before the upgrade our memory consumption looked like this:
So you can see, memory consumption was more or less constant.
Furthermore, we increased resources when we upgraded to mysql8 and switched from db-n1-standard-1 to db-n1-standard-2, to have more available resources when data grows up.
Does anyone knows this behavior? Is there a change in Mysql5 to 8? I didn't find any information about it. Just found some notes that it's normal that Mysql takes as much memory as it can get. But I'm still wondering why it didn't on Mysql5.
Some more details on the configuration:
We're using read replica for HA
Binarylogs activated
Slow Query log enabled with FILE output.
Everything else is default CloudSql Configuration.
Any help is much appreciated.
Best regards,
Chris
Indeed, it seems that MySQL 8 is consuming more memory than MySQL 5. As shown in some tests performed by the author of the article MySQL 8 and MySQL 5.7 Memory Consumption on Small Devices
, the memory used by the version 8 in same VM settings is considerably higher than on versions 5, including both resident and virtual memories - even though these are tests in small VMs, it's a good indication that this occurs in bigger configurations as well.
So, yes, it seems that, as you mentioned, it's normal that Mysql takes as much memory as it can get, but that indeed, MySQL 8 is consuming more memory than the 5 one.
i am running a wordpress website with on VULTR VPS 1GB RAM SSD,
my website has 20000+ posts and now its even slow on 4GB RAM VPS i think this is just for max mysql load right? im just noob in programming, please figure this out for me , how to load my website faster with this 20000+ posts or what to configure in the server ?
You provided very little info so it's impossible to diagnose the problem.
First you should monitor the system: CPU, memory, I/O and check if any of these are close to the limits.
Second you should monitor the database: have you access to the DB server? have you access to any monitoring facilities?
If the performance decreased when the post increased it's possible that the problem is the DB but you must understand what: a missing index? an outdated statistic?
Anyway nothing can be said without a proper monitoring
1GB RAM -- that is tiny by today's standards.
Check for swapping. That is a killer for MySQL.
Which "Engine" are your tables? (Do SHOW CREATE TABLE for a typical table.)
If ENGINE=MyISAM, look in my.cnf for key_buffer_size; it should be something like 50M. (400M for 4GB of RAM)
If ENGINE=InnoDB, look in my.cnf for innodb_buffer_pool_size; it should be something like 150M (1200M for 4GB of RAM) and key_buffer_size should be about 10M.
If your settings are significantly smaller than those, that is likely to be the problem. To double check the settings, do (from phpmyadmin, mysql commandline tool, or wherever):
SHOW VARIABLES LIKE '%buffer%';
I have a wordpress 3.5.1 site that's getting a little bit of traffic (80 concurrent visitors, ~5 clicks/pageviews per second). The site runs fine until it spikes to ~85 visitors. There are usually 4 admins logged in at the same time. The site has 8 custom post types--Posts has 3500 posts, and Press Releases (a custom post type) has 13000 posts. All of this is paginated on the site, so there are never more than 20 posts showing on any one page.
The only plugins I'm using are wp-pagenavi and w3totalcache.
I set WP_DEBUG_LOG to true and logged the errors. The main error I'm getting (besides various notices and warnings unrelated to this issue) is mysql has reached the max_user_connections limit.
My current max_user_connections is set to 75. I tried to set it higher, but the cpu can't handle the load (4 Quad Core CPUs at 2.17GHz each and 4GB of RAM).
What could be causing so many connections?
I've viewed the mysql processes running when the errors happened and there are many connections that say "SLEEPING" or "SLEEP" (probably 15-20). I also noticed via the process logs that httpd is restarting quite often during the peak traffic times.
Any ideas on how to resolve the issue?
NOTE: Please do not respond if your answer is to check my wp-config.php file and make sure my username, password, and host are correct. This is NOT the issue. The site works fine under normal traffic.
The database server is dropping out due to high loads. What's in the error logs? What's the size of the database? Have you used mysqltuner.pl to check the query load and caching settings for the MySQL server in my.cnf? https://github.com/rackerhacker/MySQLTuner-perl
WordPress can really bog down the database with many post/page revisions. Delete them with a plugin http://wordpress.org/extend/plugins/revision-control/ I've dropped databases to 10% of their original size with a resulting huge increase in performance.
Recently we changed app server of our rails website from mongrel to passenger [with REE and Rails 2.3.8]. The production setup has 6 machines pointing to a single mysql server and a memcache server. Before each machine had 5 mongrel instance. Now we have 45 passenger instance as the RAM in each machine is 16GB with 2, 4 core cpu. Once we deployed this passenger set up in production. the Website became so slow. and all the request starting to queue up. And eventually we had to roll back.
Now we suspect that the cause should be the increased load to the Mysql server. As before there where only 30 mysql connection and now we have 275 connection. The mysql server has the similar set up as our website machine. bUt all the configs were left to the defaul limit. The buffer_pool_size is only 8 mb though we have 16GB ram. and number of Concurrent threads is 8.
Will this increased simultaneous connection to mysql would have caused mysql to respond slowly than when we had only 30 connections? If so, how can we make mysql perform better with 275 simultaneous connection in place.
Any advice greatly appreciated.
UPDATE:
More information on the mysql server:
RAM : 16GB CPU: two processors each having 4 cores
Tables are innoDB. with only default innodb config values.
Thanks
An idle MySQL connection uses up a stack and a network buffer on the server. That is worth about 200 KB of memory and zero CPU.
In a database using InnoDB only, you should edit /etc/sysctl.conf to include vm.swappiness = 0 to delay swapping out processes as long as possible. You should then increase innodb_buffer_pool_size to about 80% of the systems memory assuming a dedicated database server machine. Make sure the box does not swap, that is, VSIZE should not exceed system RAM.
innodb_thread_concurrency can be set to 0 (unlimited) or 32 to 64, if you are a bit paranoid, assuming MySQL 5.5. The limit is lower in 5.1, and around 4-8 in MySQL 5.0. It is not recommended to use such outdated versions of MySQL in a machine with 8 or 16 cores, there are huge improvements wrt to concurrency in MySQL 5.5 with InnoDB 1.1.
The variable thread_concurrency has no meaning inside a current Linux. It is used to call pthread_setconcurrency() in Linux, which does nothing. It used to have a function in older Solaris/SunOS.
Without further information, the cause for your performance problems cannot be determined with any security, but the above general advice may help. More general advice geared at my limited experience with Ruby can be found in http://mysqldump.azundris.com/archives/72-Rubyisms.html That article is the summary of a consulting job I once did for an early version of a very popular Facebook application.
UPDATE:
According to http://pastebin.com/pT3r6A9q , you are running 5.0.45-community-log, which is awfully old and does not perform well under concurrent load. Use a current 5.5 build, it should perform way better than what you have there.
Also, fix the innodb_buffer_pool_size. You are going nowhere with only 8M of pool here.
While you are at it, innodb_file_per_table should be ON.
Do not switch on innodb_flush_log_at_trx_commit = 2 without understanding what that means, but it may help you temporarily, depending on your persistence requirements. It is not a permanent solution to your problems in any way, though.
If you have any substantial kind of writes going on, you need to review the innodb_log_file_size and innodb_log_buffer_size as well.
If that installation is earning money, you dearly need professional help. I am no longer doing this as a profession, but I can recommend people. Contact me outside of Stack Overflow if you want.
UPDATE:
According to your processlist, you have very many queries in state Sending data. MySQL is in this state when a query is being executed, that is, the main interior Join Loop/Query Execution loop is busy. SHOW ENGINE INNODB STATUS\G will show you something like
...
--------------
ROW OPERATIONS
--------------
3 queries inside InnoDB, 0 queries in queue
...
If that number is larger than say 4-8 (inside InnoDB), 5.0.x is going to have trouble. 5.5.x will perform a lot better here.
Regarding the my.cnf: See my previous comments on your InnoDB. See also my comments on thread_concurrency (without innodb_ prefix):
# On Linux, this does exactly nothing.
thread_concurrency = 8
You are missing all innodb configuration at all. Assuming that you ARE using innodb tables, you are not performing well, no matter what you do.
As far as I know, it's unlikely that merely maintaining/opening the connections would be the problem. Are you seeing this issue even when the site is idle?
I'd try http://www.quest.com/spotlight-on-mysql/ or similar to see if it's really your database that's the bottleneck here.
In the past, I've seen basic networking craziness lead to behaviour similar to what you describe - someone had set up the new machines with an incorrect submask.
Have you looked at any of the machine statistics on the database server? Memory/CPU/disk IO stats? Is the database server struggling?