UNIX for Advanced & Expert Users

Yes, most of the DB tables (99 percent) are MYISAM tables, especially the larger ones.

I don't have SAN.... The SCSI disks are directly attached in the box.

Just spiked again.... nearly exactly Thursday, February 13, 2020 10:02 AM UTC to Thursday, February 13, 2020 10:03 AM UTC, (5PM my time) just a one minute spike hit. Instrumentation shows no cron or batch-like processing. Only MySQL, Apache, etc (LAMP) and nothing "traceable" in the application:

sar I agree is a good idea. Does the CPU spike coincide with an I/O spike??

In my experience this is likely to be kernel element feature. For example, are you watching the cron process itself because, as you will know, this wakes up periodically (and the regularity varies from kernel to kernel, somewhere between 4 and 24 hours) to integrity check its cron table cache in memory against the crontabs on disk. If there's a lot of cron jobs this process takes a short while.

So question is are you checking the cron process itself and not just cron jobs scheduled to run?

The above is a sheer guess.

Hi Dennis,

No. I have mentioned this a number of times already, including the first post . There are no network I/O spikes.

Regarding disk I/O, I have not yet set up any instrumentation to attempt to correlate disk I/O to the spikes.

So sar as suggested is a good idea because it might tell you that.

Agreed...

I think I will try iostat or iotop during anticipated spike periods (if I can predict one, LOL)

Or I will write some code to instrument this when the spike happens and try to trap the causal process that way.

Or, I may use atop (they are all very similar linux command line tools for this kind of thing.... )

Thanks for the suggestions and ideas.

It's great to have some outside input; as it is hard to trace spikes like this.

Thank you again.