Jump to content

New VPS and high CPU usage

Featured Replies

Think this might be one to put through as a ticket for the IPS guys themselves as they would then have complete unrstricted access to the server and it would probably take them no time to work through the issues with that kind of access as opposed to me fumbling through it. I'm just concerned that the longer I let it go the potentially the bigger the problem may get and I've shed bucket loads of blood on the site over the past year and really don't want to leave anything to chance at this stage. If there is something I've maybe overlooked please feel free to suggest it in the meantime. Thanks for all your help so far wondering soul and hopefully I'll have some definate good news to post back shortly :)
Cheers
Marko

It may be an issue they see a lot so it might be relatively easy to fix!

Its got me stumped now though so it would be interesting to hear back from you when they have answered. Im just very curious now lol

Will definately post back with whatever details they are able to offer (hopefully AFTER they fix them :) )

OK, so the guys at IPS managed to spot that half my tables were InnoDB and they suggested that our server probably wasn't configured properly for InnoDB and that could be the prob. I asked them to do what they felt would clear the issue and lo and behold I saw much better performance as soon as they changed the InnoDB tables back to MyISAM. Personally, I'm not sure why or how it would make a difference but I can definately see a performance increase and our CPU doesn't shoot through the roof anymore!. Next thing I guess it start working on that my.cfg file and for now thanks Wondering Soul for your input and thanks to IPS for their support :)
Cheers
Marko

Not sure why some of your tables would be set as InnoDB by default, unless you use to use InnoDB of course. Well glad to hear its all sorted out now =]

Just to continue on with my original query ^_^ I'm now noticing a great difference in the site performance although I'm stil getting loads of other errors in the logs such as ...

# MySQL server has gone away
# Lost connection to MySQL server during query
# Lost connection to MySQL server at 'sending authentication information', system error: 32
# Lost connection to MySQL server at 'waiting for initial communication packet', system error: 95
# Lost connection to MySQL server during query
# Can't create UNIX socket (12)
# User ########_root already has more than 'max_user_connections' active connections

As is obvious, these are MySQL issues still and despite having tweaked the my.cfg to death is there anything else I could do to solve these errors?

my.cfg

[mysqld]

skip-bdb

log_slow_queries=/var/log/slow-queries.log

long_query_time=5


[mysqld]

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

skip-locking

#skip-innodb

query_cache_limit=4M

query_cache_size=128M

query_cache_type=1

max_connections=200

max_user_connections=1000

interactive_timeout=120

wait_timeout=120

connect_timeout=120

max_heap_table_size = 64M

thread_cache=32

key_buffer=256M

join_buffer=1M

max_allowed_packet=64M

max_connect_errors=1000

table_cache=1800

record_buffer=1M

sort_buffer_size=2M

read_buffer_size=8M

read_rnd_buffer_size=524288

max_connect_errors=10

# Try number of CPU's*2 for thread_concurrency

thread_concurrency=8

concurrent_insert = 2

myisam_sort_buffer_size=64M

#log-bin

server-id=1


[mysqldump]

quick

max_allowed_packet=16M


[mysql]

no-auto-rehash

#safe-updates


[isamchk]

key_buffer=64M

sort_buffer=64M

read_buffer=16M

write_buffer=16M


[myisamchk]

key_buffer=64M

sort_buffer=64M

read_buffer=16M

write_buffer=16M



Cheers
Marko

  • 1 month later...

Why has mysql been running for so long in all those top listings? Shouldn't it be dying, then restarted after periods of inactivity?

Hi, I'm not sure to be honest but any advice/explanation you can offer is greatly received :)
Marko

  • 1 month later...

nvm

Archived

This topic is now archived and is closed to further replies.

Recently Browsing 0

  • No registered users viewing this page.