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' ([EMAIL PROTECTED]) not > > supported! > > Charset encode 'unicode-1-1-utf-7' -=> 'iso-8859-15' ([EMAIL PROTECTED]) 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. _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
