Hi, yesterday I tried to get the reason of these problems, because I noticed that otrs is only slow for my account, no other user has the same problems. Martin Edenhofer schrieb am Donnerstag, 17. Juni 2004 um 09:08:33 +0200:

On Tue, Jun 15, 2004 at 07:24:10AM +0200, Joerg Friedrich wrote:

...

a few days I noticed that our otrs-system is very slow. But only when I browse through the queues, every other page is as fast as usual, so I thought, the problem is somewhere else.

I just realized, that everytime someone clicks on "Queue View" or any queue the load on the Server jumps at 100% running 'postmaster' for about 5 seconds, then the queue is displayed and the server load is at zero.

now I found in apache errorlog:

Charset encode 'unicode-1-1-utf-7' -=> 'iso-8859-15' (postmaster@digitalworkshop.com) not supported! Charset encode 'unicode-1-1-utf-7' -=> 'iso-8859-15' (rz.ca@uni-konstanz.de) not supported! Charset encode 'unicode-1-1-utf-7' -=> 'iso-8859-15' (Delivery Status Notification (Failure)) not supported! Charset encode 'unicode-1-1-utf-7' -=> 'iso-8859-15' (This is an automatically generated Delivery Status Notification. [...]

This is just a message that perl can't convert "unicode-1-1-utf-7" chateset to "iso-8859-15" charset. Because perl can't convert "unicode-1-1-utf-7" charsets.

I would guess that this is an database problem. How many open tickets in the system? How many tickets in the system? What database do you use?

1. the four messages could be delivered, by switching the otrs charset to utf-8. 2. the heavy load the machine has, when I access the queue view is a db problem. I use postgres. Number of tickets ~7000. I tracked this down to this query: SELECT t.id, a.article_sender_type_id, a.incoming_time, q.escalation_time, a.id, t.ticket_priority_id FROM article a, queue q, ticket t WHERE t.ticket_answered != 1 AND q.escalation_time != 0 AND t.ticket_state_id in ( 1, 4, 6, 7, 8 ) AND t.id = a.ticket_id AND q.id = t.queue_id AND q.group_id IN ( 2, 3, 4, 10, 1, 12, 7,6 ) AND t.ticket_lock_id in ( 1, 3 ) ORDER BY t.id, t.ticket_priority_id DESC, a.incoming_time LIMIT 1500 postgres needed ~15 sec to perform it. removing one queue from my rw-queues, and the query is done in less than a second. this is a postgres problem. -- Jörg Friedrich There are only 10 types of people: Those who understand binary and those who don't.

Martin Edenhofer schrieb am Dienstag, 22. Juni 2004 um 10:10:56 +0200:

Hi Jörg,

On Tue, Jun 22, 2004 at 07:59:09AM +0200, Joerg Friedrich wrote:

...

yesterday I tried to get the reason of these problems, because I noticed that otrs is only slow for my account, no other user has the same problems. [...]

2. the heavy load the machine has, when I access the queue view is a db problem. I use postgres. Number of tickets ~7000.

I tracked this down to this query: SELECT t.id, a.article_sender_type_id, a.incoming_time, q.escalation_time, a.id, t.ticket_priority_id FROM article a, queue q, ticket t WHERE t.ticket_answered != 1 AND q.escalation_time != 0 AND t.ticket_state_id in ( 1, 4, 6, 7, 8 ) AND t.id = a.ticket_id AND q.id = t.queue_id AND q.group_id IN ( 2, 3, 4, 10, 1, 12, 7,6 ) AND t.ticket_lock_id in ( 1, 3 ) ORDER BY t.id, t.ticket_priority_id DESC, a.incoming_time LIMIT 1500

postgres needed ~15 sec to perform it. removing one queue from my rw-queues, and the query is done in less than a second.

this is a postgres problem.

Maybe a postgres problem or we could optimize the SQL query.

PS: It's because postgres gets problems with many open ticksts. It should work fine if there are ~ 1000 open tickets.

the problem disappeared after setting the charset to utf8, displaying the queue-view and switching back to iso-8859-15. the problem must be related to my charset-problems -- Jörg Friedrich There are only 10 types of people: Those who understand binary and those who don't.