Michael, thank you the link, it's funny, but last time i did not find "New Issue" button. Thank you for the help!
Hi, Thomas, i'd checked for concurent mysql statements. This request was only one. In iotop mysql use whole disk write IO. So i have big load average on my VPS. After create this index, problem has gone for me. Icinga bug - https://dev.icinga.org/issues/10110 > it would be great if you could report this on dev.icinga.org, we are > currently trying to improve IDO indices. I was missing one detail in > your mail, how long did the query take with the new index? Could you > show a processlist output where such a query is hanging around? Is it > waiting "alone" or waiting for other queries to complete? > > While your index seems to perfectly fit this query I'd first prefer to > find out if there is a chance to tweak the query itself. > > mysql> EXPLAIM SELECT actual_end_time, actual_end_time_usec, > was_cancelled FROM icinga_downtimehistory WHERE instance_id = 1 AND > entry_time = FROM_UNIXTIME(1360657630) AND internal_downtime_id = > '77733' and object_id = 12107\G > *************************** 1. row *************************** > id: 1 > select_type: SIMPLE > table: icinga_downtimehistory > type: const > possible_keys: instance_id,tom_index > key: instance_id > key_len: 31 > ref: const,const,const,const > rows: 1 > Extra: > 1 row in set (0.00 sec) > > Query execution time is also 0.00 sec, in a live environment with real > data and slightly more than 100k records. ----- Romaneev Vasily _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
