Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm running 64-bit Debian Squeeze and I've installed bugzilla from the repositories. This action has auto-configured and installed:

  • Bugzilla
  • MySQL Ver 14.14 Distrib 5.1.63
  • Apache 2.2.16-6+squeeze8

When I browse my Bugzilla web interface I find that navigation is very fast, but adding new bugs or comments is very slow (10s+).

I've tried the following things to rectify the issue:

  1. Configured Bugzilla to use mod_perl rather than mod_cgi. The navigation speeded up a little, but form submission remained slow.

  2. Threw more resources at the (virtual) server. It now has two CPU cores and 4 GB memory (up from one core and 1GB memory). No discernible difference.

  3. Followed the advice on this page to tweak my sendmail configuration. Again, this doesn't appear to have improved matters.

  4. Watched the output from top while submitting a bug. Nothing seemed to hog resources.

Can anyone advise on my next best step to troubleshoot the cause of my performance problems? It wouldn't surprise me if the bottleneck is related to MySQL but how can I determine that?

share|improve this question
up vote 0 down vote accepted

I suspect MySQL. Do you get the same if it uses Postgres? What back-end disk-alike does it have in the VM?

share|improve this answer
At this stage, I'd prefer to prove it's MySQL before I go through the pain of tearing it out and trying Postgres. Can you explain the meaning of "What back-end disk-alike does it have in the VM?" I shared that question with the guy who set up my VM and he looked blankly at me. – Duncan Oct 4 '12 at 13:53
If the mysql in the VM writes to files in a filesystem .. which the VM translates to a file in the physical host then your data is passing through 2 sets of filesystem code and 2 sets of block device code before seeing a disk. If it's using a disk partition which is native in the physical host I expect it to be faster. Also testing postgres should not be a lot of work provided you can spare some downtime. – Peter Oct 4 '12 at 15:02
A fair point, regarding disk usage. However if that were a major issue, I'm sure I would have seen that during other operations (apt-get upgrades, etc). I'm seeing very long (10-15s) delays when submitting a bug, which must presumably write to only a handful of tables. Is there a way for me to measure what MySQL is doing to see if the bottleneck is occurring during the database updates? – Duncan Oct 4 '12 at 15:12
strace with timestamps would get you some measurement. I don't know anything about mysql's own investigative tools. And how's DNS on the VM? If there's a DNS timeout getting into each transaction that would be an avoidable snag. – Peter Oct 4 '12 at 15:42
Thanks for your help so far. Fortunately, some other department in my company has revealed it has the capacity to host our bugs database. Hence my playing around has come to an end. – Duncan Oct 4 '12 at 17:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.