On 2012-03-08 06:42, Fernando Frediani (Qube) wrote:
Hello chaps.
I have a system here that has about 7 years worth of data(3GB of MySQL data) and receives about 30 – 50 tickets / day in the recent 2 years, so not that huge system really.
It has been upgraded through the versions and works fine. Now I’m running version 2.4.5 (yes I will upgrade it to 3.1 at some point soon).
What happens is that sometimes some tickets depending if it has many messages or many merges when you try to open any message of it, takes a long time, sometimes over a minute or two.
I’ve looked at all possible causes and I don’t think is the Database server which I haven’t observed any contention issues and works perfect for all other systems using it.
One thing I suspect is the filesystem, specially inside the var folder that has thousands of small files (although separated in different folders, etc) for the attachments and that somehow might be slow to index and read all necessary files attached to that specific ticket. However I still fell that is not the root of the problem because of the following:
While OTRS is trying to load the message if you look at the server running it you will find a “httpd” process running at a 100%. If there was a contention on the Database server or on the filesystem that couldn’t responde in a reasonable time, httpd should not be running at 100%, but rather be waiting from a response with data to be processed and displayed to the client.
It may show 100% CPU usage, but may be actually waiting for i/o. You may try these commands when doing this merge. iostat -x 1 5 vmstat 1 5 This will give you stats each second, for 5 second. If you don't know how to analyze the numbers, just post them somewhere (or here).