Gilbertson: Swed: All I know is that it’s not going to be a pleasant job and there’s no way I’m using Excel to do it

Swed: Keiter, if the same ean was ***igned twice then they sure do not want to lose that information, so definitely not good to let some automat pick

Keiter: Sonny_Jim: a DBA’s job definitely includes cleaning up data from time to time

Lovejoy: Actually i’ll find out

Dobies: Thanks for the advice

Oehrle: Alright heading off for a moment, thanks again tons for the help danblack

Cluver: Hi. I’ve got a MySQL running in a KVM that occasionally has IO spikes that cause high request latency. I’m trying to think of ways to reduce this latency, without having to physically move where the DB is stored.

Sverchek: Does allocating more RAM seem like a reasonable direction to go in?

Merrihew: Is it powering a website?

Ormsbee: Do you already maxed out on what you can optimize via caching?

Rakoci: How much traffic do you have during those spikes?

Umbach: Traffic is pretty low and constant – less than 1 request per second.

Keffer: How can that cause problems?

Kekua: How much do you pay for it?

Turnage: Should be enought to hande more traffic i guess

Applin: Do you mind telling us where you host it?

Tusing: I see. i heard good things about them.

Heady: Did not use them myself though.

Abele: Are these users all logged in and need realtime fresh pages?

Mehringer: Well, that’s one example spike

Blaich: Sar? tps? breads? bwrites? never heard of any of those.

Nanfito: Yeah, all logged in, all updating things like last access time which is a desired feature

Bieker: Yeah, linux. sar = command to view sysstat which is recording cpu and i/o stats every minute

Polakis: Aha. i just use top and other tools.

Viramontas: 4 TPS only and iowait at 100%? Looks like a really poor I/O

Landini: It might be a vbulletin issue then. i dont know it.

Malmgren: You would have to ****yze what takes so long.

Gazaway: Repeatedly firing “SHOW FULL PROCESSLIST” in mysql might bring up somethin.

Dewire: I’d check the disks health, not sure if possible on DigitalOcean

Frothingham: They said there are no problems on the hw

Skoglund: But offered to move the VM to another hypervisor, which would result in uncoordinated downtime

Barnfield: Also apache might have a feature to log which http requests take how long to process.

Galati: I would first find out, WHAT takes long.

Salvetti: Then start to optimize.

Corbet: Maybe you have a 500mb PNG logo on top of your page : who knows.

Budz: With a nocache header.

Ballance: I have New Relic set up. simple queries like update 1 field on a 4000 row table will take a few seconds during these spikes, then go back to like 100ms

Kubly: Well, during a spike anything could take long.

Breiter: You need to find out what takes how much time in general.

Specht: UPDATE user SET lastactivity = ? WHERE userid = ? for example usually takes 10ms, but during times of high iowait it will take 5-12 sec. there is no correlation in the request logs that would cause additional db load all of a sudden

Trentacoste: It probably takess so long because it waits for locked tables or locked rows.

Bridegroom: Not because the actual update takes longer.

Arterburn: SHOW FULL PROCESSLIST will tell you more about whats going on under the hood.

Correl: Bythebeach: Also SHOW ENGINE INNODB STATUS

Parchman: Nearly all queries get slower suddenly, incl. selects that would never hit a locked table/row but that would likely still go to disk

Marucci: 10 PRINT “bythebeach: get more info via SHOW FULL PROCESSLIST”