Problem zwischen Webinterface und MySQL
Ich habe ein Problem mit meinem Webinterface, und zwar "stürzt" es bei einer größeren Suche ab. Es kann dann meistens nicht mehr mit OTRS gearbeitet werden bis der mySQLd neu gestartet wurde. Webserver neu starten bringt nichts. Ich habe bereits einige Werte vom mySQLd erhöht (Connections auf 2500, key_size erhöht) hat aber nichts gebracht. Versionen: SuSE 9.2 MySQLd 4.0.21 Apache 2.0.50 (Feb 1 2006) Rechner isn guter eigentlich, Last ist auch nicht hoch: HP DL360 3 Ghz Xeon HT 1 GB Ram 70 GB SCSI Platte (glaub 10k Umdrehungen) Gruß Dennis
Ich habe noch was rausgefunden: Wenn ich in der Suche das Create_by Feld benutze passiert es, bei den anderen suchen konnte ich es noch nicht nachstellen, also habe ich mal die Prozesse der DB abgefragt und siehe da: Dieses Select Statement "blockiert" den SQL-Server: ELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND th.create_by IN (31) AND th.history_type_id = 1 AND sq.group_id IN (6, 7, 9, 8, 5, 3, 2, 4, 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 32, 50) ORDER BY st.create_time_unix DESC LIMIT 5000; Lasse ich die Gruppen/Queues weg schafft er es, die Dauer ist aber unvernünftig lang: SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND th.create_by IN (31) AND th.history_type_id = 1 ORDER BY st.create_time_unix; +-------+---------+------------------+ | id | tn | create_time_unix | +-------+---------+------------------+ | 42001 | 1042396 | 1143535123 | | 42489 | 1042884 | 1143712887 | | 42523 | 1042918 | 1143719588 | | 42772 | 1043170 | 1143803491 | | 42774 | 1043172 | 1143803556 | +-------+---------+------------------+ 5 rows in set (29.82 sec) Für 5 Zeilen knapp 30 Sekunden. Ich hoffe es kann mir jemand helfen, denn im Moment steht das OTRS eben 1-2x am Tag und kann nur durch das manuelle töten des SELECT-Prozesses wieder zum Leben erweckt werden. Gruß Dennis Dennis Schwan schrieb:
Ich habe ein Problem mit meinem Webinterface, und zwar "stürzt" es bei einer größeren Suche ab. Es kann dann meistens nicht mehr mit OTRS gearbeitet werden bis der mySQLd neu gestartet wurde. Webserver neu starten bringt nichts.
Ich habe bereits einige Werte vom mySQLd erhöht (Connections auf 2500, key_size erhöht) hat aber nichts gebracht.
Versionen:
SuSE 9.2 MySQLd 4.0.21 Apache 2.0.50 (Feb 1 2006)
Rechner isn guter eigentlich, Last ist auch nicht hoch:
HP DL360 3 Ghz Xeon HT 1 GB Ram 70 GB SCSI Platte (glaub 10k Umdrehungen)
Gruß Dennis ------------------------------------------------------------------------
_______________________________________________ OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? => http://www.otrs.de/
Hi Dennis, On Fri, Mar 31, 2006 at 02:07:31PM +0200, Dennis Schwan wrote:
Ich habe noch was rausgefunden:
Wenn ich in der Suche das Create_by Feld benutze passiert es, bei den anderen suchen konnte ich es noch nicht nachstellen, also habe ich mal die Prozesse der DB abgefragt und siehe da: Dieses Select Statement "blockiert" den SQL-Server:
ELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND th.create_by IN (31) AND th.history_type_id = 1 AND sq.group_id IN (6, 7, 9, 8, 5, 3, 2, 4, 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 32, 50) ORDER BY st.create_time_unix DESC LIMIT 5000;
Lasse ich die Gruppen/Queues weg schafft er es, die Dauer ist aber unvernünftig lang:
SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND th.create_by IN (31) AND th.history_type_id = 1 ORDER BY st.create_time_unix;
+-------+---------+------------------+ | id | tn | create_time_unix | +-------+---------+------------------+ | 42001 | 1042396 | 1143535123 | | 42489 | 1042884 | 1143712887 | | 42523 | 1042918 | 1143719588 | | 42772 | 1043170 | 1143803491 | | 42774 | 1043172 | 1143803556 | +-------+---------+------------------+ 5 rows in set (29.82 sec)
Für 5 Zeilen knapp 30 Sekunden. Ich hoffe es kann mir jemand helfen, denn im Moment steht das OTRS eben 1-2x am Tag und kann nur durch das manuelle töten des SELECT-Prozesses wieder zum Leben erweckt werden.
So direkt können wir dir ohne Supportvertrag leider nicht helfen :(. Aber es wäre schön, wenn du zu diesem Problem einen Fehlerbericht auf http://bugs.otrs.org aufmachen kannst, dann können wir versuchen das Ganze nachzuvollziehen und auch zu fixen.
Gruß Dennis
Danke und viele Grüße, Christian -- ((otrs)) :: OTRS GmbH :: Europaring 4 :: D - 94315 Straubing Fon: +49 (0) 9421 1862 760 :: Fax: +49 (0) 9421 1862 769 http://www.otrs.com/ :: Communication with success!
Habe ich gemacht, wahrscheinlich wars auf deutsch aber falsch... Christian Schoepplein schrieb:
Hi Dennis,
On Fri, Mar 31, 2006 at 02:07:31PM +0200, Dennis Schwan wrote:
Ich habe noch was rausgefunden:
Wenn ich in der Suche das Create_by Feld benutze passiert es, bei den anderen suchen konnte ich es noch nicht nachstellen, also habe ich mal die Prozesse der DB abgefragt und siehe da: Dieses Select Statement "blockiert" den SQL-Server:
ELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND th.create_by IN (31) AND th.history_type_id = 1 AND sq.group_id IN (6, 7, 9, 8, 5, 3, 2, 4, 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 32, 50) ORDER BY st.create_time_unix DESC LIMIT 5000;
Lasse ich die Gruppen/Queues weg schafft er es, die Dauer ist aber unvernünftig lang:
SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND th.create_by IN (31) AND th.history_type_id = 1 ORDER BY st.create_time_unix;
+-------+---------+------------------+ | id | tn | create_time_unix | +-------+---------+------------------+ | 42001 | 1042396 | 1143535123 | | 42489 | 1042884 | 1143712887 | | 42523 | 1042918 | 1143719588 | | 42772 | 1043170 | 1143803491 | | 42774 | 1043172 | 1143803556 | +-------+---------+------------------+ 5 rows in set (29.82 sec)
Für 5 Zeilen knapp 30 Sekunden. Ich hoffe es kann mir jemand helfen, denn im Moment steht das OTRS eben 1-2x am Tag und kann nur durch das manuelle töten des SELECT-Prozesses wieder zum Leben erweckt werden.
So direkt können wir dir ohne Supportvertrag leider nicht helfen :(. Aber es wäre schön, wenn du zu diesem Problem einen Fehlerbericht auf
aufmachen kannst, dann können wir versuchen das Ganze nachzuvollziehen und auch zu fixen.
Gruß Dennis
Danke und viele Grüße, Christian
------------------------------------------------------------------------
_______________________________________________ OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? => http://www.otrs.de/
Hallo. Ich hatte das Problem früher auch, nachdem wir das OTRS c.a. 1 Jahr genutzt hatten und die DB schon ziemlich groß war. Lösung 1: Suchanfragen zeitlich auf 3 Monate beschränken Lösung 2: MySQL Replikation für Sucheserver aufsetzen -- Mit freundlichen Grüssen André Bauer System: Debian 3.1 / Apache 2.0.54 / MySQL 4.0.24 / OTRS 2.0.4 ============================================ CS> Hi Dennis, CS> On Fri, Mar 31, 2006 at 02:07:31PM +0200, Dennis Schwan wrote:
Ich habe noch was rausgefunden:
Wenn ich in der Suche das Create_by Feld benutze passiert es, bei den anderen suchen konnte ich es noch nicht nachstellen, also habe ich mal die Prozesse der DB abgefragt und siehe da: Dieses Select Statement "blockiert" den SQL-Server:
ELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND th.create_by IN (31) AND th.history_type_id = 1 AND sq.group_id IN (6, 7, 9, 8, 5, 3, 2, 4, 1, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 32, 50) ORDER BY st.create_time_unix DESC LIMIT 5000;
Lasse ich die Gruppen/Queues weg schafft er es, die Dauer ist aber unvernünftig lang:
SELECT DISTINCT st.id, st.tn, st.create_time_unix FROM ticket st, queue sq , ticket_history th WHERE sq.id = st.queue_id AND st.id = th.ticket_id AND th.create_by IN (31) AND th.history_type_id = 1 ORDER BY st.create_time_unix;
+-------+---------+------------------+ | id | tn | create_time_unix | +-------+---------+------------------+ | 42001 | 1042396 | 1143535123 | | 42489 | 1042884 | 1143712887 | | 42523 | 1042918 | 1143719588 | | 42772 | 1043170 | 1143803491 | | 42774 | 1043172 | 1143803556 | +-------+---------+------------------+ 5 rows in set (29.82 sec)
Für 5 Zeilen knapp 30 Sekunden. Ich hoffe es kann mir jemand helfen, denn im Moment steht das OTRS eben 1-2x am Tag und kann nur durch das manuelle töten des SELECT-Prozesses wieder zum Leben erweckt werden.
CS> So direkt können wir dir ohne Supportvertrag leider nicht helfen :(. CS> Aber es wäre schön, wenn du zu diesem Problem einen Fehlerbericht auf CS> http://bugs.otrs.org CS> aufmachen kannst, dann können wir versuchen das Ganze nachzuvollziehen CS> und auch zu fixen.
Gruß Dennis
CS> Danke und viele Grüße, CS> Christian
participants (3)
-
André Bauer -
Christian Schoepplein -
Dennis Schwan