High cpu usage

Machiel Richards <[email protected]> Thu, 25 Oct 2018 10:09:51 +0000
Newsgroups gmane.comp.db.mysql.general
Message-ID <DB7P192MB0268B3F13361CB8C31FFD8BACFF70@DB7P192MB0268.EURP192.PROD.OUTLOOK.COM>
--_000_DB7P192MB0268B3F13361CB8C31FFD8BACFF70DB7P192MB0268EURP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Good day all


   Hoping this mail finds you well.


   I am hoping someone can perhaps give us some guidance here as we now see=
m to be stuck on a problem and have not been able to find a solution after =
more than a month.


   We are running an opensips server on Centos 6.5 , using mysql 5.7.13 whi=
ch was installed via Tarball file.


   The server is setup as a slave and master and receives updates from open=
sips config nodes as well as registrations from workers.


   Replication is paused during the day and forward replication (master) is=
 disabled at the moment.


   However , we are getting an issue every day on mysql side in terms of my=
sql pushing up server load.



    During the day the server is running fine with a load avg not going abo=
ve 1.5 during peak times.


    However in the evening , replication is unpaused, and completes process=
ing and catchup within about 15 minutes and is paused again about 30 minute=
s after the unpause.



      Give or take 45 minutes to an hour after the replication is paused ag=
ain, mysql starts to cause high cpu usage with no apparent processes runnin=
g as can be seen on full processlist (maybe one or two selects which comple=
tes fairly quickly)


       The higher load, causes queries to slow down however and opensips to=
 start timing out on db connections, causing clients to resubmit.


     The resubmits , then obviously causes even more load spiking the mysql=
 load to increase as well as the server load and eventually opensips kills =
itself.



    I have looked at the disks, iowaits, memory usage, all is fine.


    We do not see any strange queries or stick queries, no deadlocks, etc..=
. only the increase in selects after mysql starts to push up the cpu load.



    We have added all indexes we can find, but even this has made no differ=
ence at all.


     Currently we are at a loss so I am hoping someone else can assist in e=
xplaining how else we can find out why mysql is eating up the cpu ...



   The same behaviour can also be seen the moment any new feature is added =
to the server that requires mysql processing to be done, so this does not s=
eem to be specifically related to replication, however it does seem like th=
e current load from replication causes mysql to act up.


  the server is currently running on SSD (recently replaced) , and 8Gb of m=
emory with 1 x quadcore CPU.



    should any more info be required, please feel free to ask.


--_000_DB7P192MB0268B3F13361CB8C31FFD8BACFF70DB7P192MB0268EURP_--