8

I've got a Redmine instance (Bitnami Stack) that's unusually slow. Because I'm just trying to get to the bottom of this, I have some theories which I'd like to discuss here. So, if anybody has any ideas about this, please feel free to help :-)

System:

Bitnami Stack with Redmine 1.4.x upgraded to Bitnami Stack with Redmine 2.1.0 like this:

  • mysqldump'd the old database
  • installed new Bitnami Stack with Redmine 2.1.0
  • imported the dump cleanly with recreating all tables
  • rake db:migrate and all that

The stack is running on a Virtual Machine with OpenSUSE 12.1. The resources shouldn't be a problem, as there are always multiple gigabytes of free RAM and CPU spikes on Redmine requests go only up to 50% of 2 CPU cores. Also, there are only a few users accessing it.

What may be totally important: User login is handled via LDAP (ActiveDirectory).

Problem:

On each request, Redmine reacts unusually slow. Sometimes it takes 3 seconds, sometimes even up to 10 seconds to deliver the page.

My thoughts:

  • I don't know if "On-the-fly user creation" is checked in Redmine's LDAP settings, I can only check this one later today. But could the lack of a check here be a problem? Authentication takes a moment when logging in that's normal and acknowledged. But when not creating the user on the fly, does it keep a session only or does it re-authenticate on each request, so that could be the problem?
  • Is Redmine 2.x maybe so much slower than 1.4.x that it's just plain normal?
  • Is Bitnami's Apache2+Passenger config faulty?
  • MySQL indexes wouldn't be a problem given the fact that MySQL is very calm on the CPU, would it?

One more thing that seems very odd to me, but maybe a false measurement result (need to re-check this tomorrow when I see the machine):

I tried to check if it's a network problem (network reacting slow, maybe DNS or something; server is in the local network). It seemed like requests on localhost (Browser directly on the OpenSUSE VM) were fast, but requests over the network weren't. Usually, I would think of a network problem, but the strange thing is: When actually measuring connect times, the network is fast as hell. Ping is good, static delivery times too. It seemed like only Redmine-side calculated pages are slowly sent by the application server while Apache's still fast - but only when the request is a remote LAN request. Very strange … but as I mentioned above, I have to re-check this one. It just seems illogical to me.

  • Did you get any feedback - or did you find anything? – Anthony Horne Jun 18 '15 at 8:27
  • 2
    This might also be a disk bandwidth or seek time issue. How do things look in top, and in particular, how is hi, the hardware interrupt time? – Falcon Momot Sep 7 '15 at 7:38
  • Are you accessing it with domain with local DNS? Do you access it as localhost inside VM and it works fine? Can you try to access it with with VM's IP? Have you setup hostname correctly in Redmine and Apache configurations? – Sohail Ahmed Jul 27 '17 at 11:51
  • Are you running the VM on local storage on the server, or on a remote nfs/iscsi one? – Marco Aug 19 '17 at 6:41
0

Try to re-check the redmine logs if there's any issue related to the processing of the pages or user logins if you're considering LDAP AD login to be at fault.

Also please check the apache and mySQL logs - webserver may be busy with something else or ruby may be stuck on rendering an unsupported plugin for example. MySQL may be running a long running query and so on..

If you restart all the services that serve the redmine instance - is it running fast at the beginning and slows down after a while or it's slow from the begining ?

As mentioned in the comments section - Disk IOs can be also at fault. Try to tail webserver logs as you click around the redmine web interface to have some idea what is taking the most ammount of time to render.

Also try to test your network connection to the redmine instance (not only with ping/ICMP) but also try loading some static content (download) or pushing some files (upload) over port 80 or 443.

Try to measure packet loss,round trip time and jitter (how many packets arrive out of sequence) to have some idea if network is not at fault.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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