Valcora Blog - Comments

Valcora: Another Way To Do Performance Tuning

nospam@example.com (Valcora) — Tue, 16 Jun 2009 13:06:34 -0600

Although the Query Analyzer is an incredible addition to the Enterprise Monitor, we actually used Jet Profiler for this client since they did not have the latest version of the MySQL Enterprise Monitor. Naturally, we also analyzed the slow query logs and ran a tcpdump of the queries hitting the server. In this case, we needed to do a quick profile of the system and this seemed the easiest way to get fast results in the environment we had to work with.

Mark Leith: Another Way To Do Performance Tuning

nospam@example.com (Mark Leith) — Mon, 08 Jun 2009 05:29:02 -0600

Did you use MySQL Query Analyzer to find the problem queries?

strcmp: Finding All MyISAM Tables

nospam@example.com (strcmp) — Sat, 06 Jun 2009 20:42:25 -0600

the quick and dirty solution is echo "$MYSQL_DATA_DIR"/*/*.MYD

should run much faster, because mysqld doesn't have to open all the tables, which can be a problem, if you have 1000s.

Doug Eilertson: Our PHP Experiences

nospam@example.com (Doug Eilertson) — Thu, 21 May 2009 17:55:20 -0600

You have been there and did that (mucho experience, etc.) ... so where is the link to your tips?

Artem Russakovskii: It Must Be a Database Problem...

nospam@example.com (Artem Russakovskii) — Sun, 17 May 2009 15:02:47 -0600

Also, you should add 5.4 to the list in your poll /offtopic

Artem Russakovskii: It Must Be a Database Problem...

nospam@example.com (Artem Russakovskii) — Sun, 17 May 2009 14:25:28 -0600

Of course you must first understand it is buried deep inside human nature to try to push off problems onto something or someone else, if at least to buy some time before having to deal with them.

It is also true that a certain percentage of them are indeed problems with whatever it is that is blamed and those will not come back to waste the problem reporter's time, so the very first thing they'll always try to do is to send them problems away. Yes, it may waste more of someone else's time but not theirs.

As a developer that has to find causes for problems on a daily basis, I myself have to admit to blaming databases, servers, language bugs, etc for something the user (or me) was actually to blame. The reasons are usually a) it really seemed like there was a problem and b) I didn't know any better at the time.

The key is to have employees that learn through their mistakes, rather than push off problems more and more once they "learn" that it's the easy way.

The most common case I can think of is blaming Linux (or mysql, plug another app) when the server runs out of space. Linux likes to die, mysql likes to return errors (111 was it?), but the end result is it seems something is wrong with them.

Good post, everyone needs to vent once in a while

Artem

Valcora: It Must Be a Database Problem...

nospam@example.com (Valcora) — Fri, 15 May 2009 11:51:58 -0600

That is too funny sorta, if it weren't for the fact that I could relate... Early in my career when I was a Data Processing intern in a manufacturing company, I got called out to the factory floor to diagnose a problem with a printer. When I got there the supervisor told me printer would not print. I looked down and noticed the LEDs were off. After a quick glance under the table, I noticed the plug lying on the floor out of the socket. I smiled, plugged it in, and told him his printer was "fixed." Later he called and said I was a "genius." Of course to save face for him, I just told him I was glad to get it working again and never told him it was unplugged...

Bill Karwin: It Must Be a Database Problem...

nospam@example.com (Bill Karwin) — Fri, 15 May 2009 10:22:59 -0600

I'm sure this user-knows-best phenomenon happens to medical doctors and car mechanics and bartenders and everyone else..

Here's another database support anecdote, circa 1996: we got a call from our customer who said their database server spontaneously crashed every week during the night. We tried for weeks to troubleshoot, but we were stumped. Nothing could diagnose or fix the crashing problem.

Finally, the customer called us and explained that their janitor was unplugging server power cords while he was sweeping up the data center one night per week!

Edwin F.: What it Takes to Be a Senior MySQL DBA

nospam@example.com (Edwin F.) — Fri, 15 May 2009 10:05:11 -0600

Completely agreed with your post. The most valuable lesson we can learn in our work (hobbie) life is *"Know your tools, where to look for and who to ask to"*. That's a skill we should have been born with and hard coded in our DNA

Regards.

Toby: Determine 32 or 64-bit Server

nospam@example.com (Toby) — Fri, 15 May 2009 09:45:29 -0600

On OS X, the 'lipo' utility identifies architectures in a binary.

Valcora: It Must Be a Database Problem...

nospam@example.com (Valcora) — Fri, 15 May 2009 08:40:48 -0600

Oh I agree completely. I was just wondering if anyone else had similar experiences. The post was done "tongue-in-cheek."

Roland Bouman: It Must Be a Database Problem...

nospam@example.com (Roland Bouman) — Fri, 15 May 2009 08:18:35 -0600

"There is so much bias out there that sometimes others are blinded to the obvious in their haste to blame someone else!"

oh, I don't know...My users always like to blame "the network". It's true that our network sucks some of the time, but in the particular case I am dealing with it is almost always page complexity and client processing capabilities that are responisble for performance problems.

But I'll gladly accept whatever suggestion I get from my users - I regard it as their social gesture that they're involved and want to help make things better. The fact that they're often wrong doesn't really discredit them in my opinion.

(it would be another case when dealing with people that should know better, but this I rarely have conflicts in that regard.)

I can explain this over and over, and point to graphs that prove the problem but its useless - the mneme is stuck in their mind and their sticking with it.

I don't mind really, it is not really important what the user thinks is the cause of the problem. We devs, sysadmins, DBAs etc should simply do our best to solve whatever the problem is. If we find we can't solve it by ourselves because the responsible part of the system is out of our control, we can say: "Look, I can't find anything, but I think this may be the cause...shall I find whoever is responsible for that and ask them to look into it?"