MySQL seem take high CPU and Ram


#1

Hello, without any dating mysql take high amount of cpu and ram in many different time in a day, i can publish post/article in 1 hour …

here is the top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

7714 mysql 20 0 1377516 457352 4996 S 225.2 21.8 40:45.10 /usr/sbin/mysqld

7714 mysql 20 0 1377516 460248 4920 S 4.7 21.9 41:17.49 /usr/sbin/mysqld sometime above 200% and some time 20 …

my RAM is 2 Giga

MySQL (10.1.33-MariaDB) on localhost:

port 3306 wait_timeout 600 interactive_timeout 28800 max_used_connections 43 datadir /var/lib/mysql/ socket /var/run/mysqld/mysqld.sock my.cnf [PATH] /etc/mysql/conf.d/my.cnf

here is my tuning-primer.sh

    -- MYSQL PERFORMANCE TUNING PRIMER --
         - By: Matthew Montgomery -

MySQL Version 10.1.33-MariaDB-1~xenial x86_64

Uptime = 0 days 2 hrs 24 min 7 sec Avg. qps = 45 Total Questions = 397689 Threads Connected = 3

Warning: Server has not been running for at least 48hrs. It may not be safe to use these recommendations

To find out more information on how each of these runtime variables effects performance visit: http://dev.mysql.com/doc/refman/10.1/en/server-system-variables.html Visit http://www.mysql.com/products/enterprise/advisors.html for info about MySQL’s Enterprise Monitoring and Advisory Service

SLOW QUERIES The slow query log is NOT enabled. Current long_query_time = 10.000000 sec. You have 0 out of 397703 that take longer than 10.000000 sec. to complete Your long_query_time seems to be fine

BINARY UPDATE LOG The binary update log is NOT enabled. You will not be able to do point in time recovery See http://dev.mysql.com/doc/refman/10.1/en/point-in-time-recovery.html

WORKER THREADS Current thread_cache_size = 100 Current threads_cached = 41 Current threads_per_sec = 0 Historic threads_per_sec = 0 Your thread_cache_size is fine

MAX CONNECTIONS Current max_connections = 100 Current threads_connected = 2 Historic max_used_connections = 43 The number of used connections is 43% of the configured maximum. Your max_connections variable seems to be fine.

No InnoDB Support Enabled!

MEMORY USAGE Max Memory Ever Allocated : 979 M Configured Max Per-thread Buffers : 753 M Configured Max Global Buffers : 656 M Configured Max Memory Limit : 1.37 G Physical Memory : 2.00 G Max memory limit seem to be within acceptable norms

KEY BUFFER Current MyISAM index space = 15 M Current key_buffer_size = 128 M Key cache miss rate is 1 : 899 Key buffer free ratio = 78 % Your key_buffer_size seems to be fine

QUERY CACHE Query cache is enabled Current query_cache_size = 256 M Current query_cache_used = 69 M Current query_cache_limit = 2 M Current Query cache Memory fill ratio = 27.12 % Current query_cache_min_res_unit = 4 K MySQL won’t cache query results that are larger than query_cache_limit in size

SORT OPERATIONS Current sort_buffer_size = 4 M Current read_rnd_buffer_size = 1 M Sort buffer seems to be fine

JOINS /usr/local/bin/tuning-primer.sh: 401: local: 2097152: bad variable name

I installed wpsc site

I need to know what is the wrong and what is the best for me

Regards, `


#4

Hello, you can try to use phpymyadmin to see what queries are using so much resources. But are your databases running only with MyISAM storage ?

Have you tried another caching system than --wpfc ?


#5

I used InnoDB Engin, I switch to wpsc soon I was used wpfc I switched to wpsc to get best performance on mysql but still the same any other advice regards,


#6

please help me


#7
  • Whats your traffic stats?

  • Have you tried wpredis?

  • Have you touched my.cnf according to tuning-primer suggestions?


#8

traffic stat 4k to 6k visitor perday 10k - 20k views perday

  • Now I work with wpsc [WP Super Cache ] I tried wpfc before it … *my.cnf looks fine ** the server was work for more than 2 years with the same setting fine, now my both server having performance issue

regards,


#9

NO I didn’t try it


#10

Any slow queries identified already?


#11

No slow queries at all


#12

No slow queries + Default installation that was running fine for ~2 years + Biggest traffic compared to the previous 2 years + Same routine done on WordPress (percentage of posts etc)

=

Time for ugprade.


#13