Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Висит таблица при первом открытии
|
|||
|---|---|---|---|
|
#18+
Здрасте всем! В общем: Пару дней назад хостер перезагрузил наш впс и начались взаимоблокировки запросов в PROCESSLIST со всеми вытекающими. Которых раньше не было. Сколько ни искали причину мы, сколько не писали б хостеру в тикетах причина до сих пор не найдена. Блокируются всегда запросы с одной и той же таблицей, но это логично так как она самая крупная ~750т. записей и самая востребованная)) Запросы блокирующие - всегда разные но всегда к этой таблице. Что смущает больше всего это не стабильное время выполнения запроса. Смотришь в PROCESSLIST висит запрос 300сек. блокирует кучу других. Копирую его - убиваю - делаю в ручную в phpmyadmin = отрабатывает за микросекунды. И вопрос не в кеше первое что попробовали это: set @@global.query_cache_size=0; результатов ни каких не дало. Едем дальше... Стабильно висят запросы при первом обращении: 1) перезагружаю сервер 2) Захожу в phpMyadmin под рутом и запускаю простой запрос select SQL_NO_CACHE count(`id`) FROM `bigTable` where tip=2 и получаю зависание длиною 30-70секунд! Висит всё! Даже SHOW PROCESSLIST висит и phpMyadmin не откликается. Иногда SHOW PROCESSLIST не висит, работает, но запроса этого он не показывает на всём пути его выполнения. 3) В итоге запрос всё таки отрабатывает и возвращает результат. Тут же запускаю его снова и он отрабатывает уже меньше чем за секунду! 4) Убираю SQL_NO_CACHE отрабатывает за несколько миллисекунд.(из кэша) 5) Проходит время таблица видимо притерпевает изменения данных. И снова запрос работает 50+ секунд... Что это и почему так происходит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2017, 13:38 |
|
||
|
Висит таблица при первом открытии
|
|||
|---|---|---|---|
|
#18+
hated, таблица на каком движке? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2017, 14:29 |
|
||
|
Висит таблица при первом открытии
|
|||
|---|---|---|---|
|
#18+
miksofthated, таблица на каком движке? MyISAM ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2017, 14:41 |
|
||
|
Висит таблица при первом открытии
|
|||
|---|---|---|---|
|
#18+
Очень прошу помощи... Уже головы сломали - всё без толку... Клиенты на части уже рву всё висит... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2017, 15:09 |
|
||
|
Висит таблица при первом открытии
|
|||
|---|---|---|---|
|
#18+
Ну хоть чисто теоретически ответьте. Как работает мускул при первом запросе к таблице? Почему первый запрос после запуска сервера всегда дольше, чем все последующие запросы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2017, 18:05 |
|
||
|
Висит таблица при первом открытии
|
|||
|---|---|---|---|
|
#18+
hatedОчень прошу помощи... Уже головы сломали - всё без толку... Клиенты на части уже рву всё висит... задержки в конкретное число секунд 10, 30, 60, 300 могут быть вызваны сетевыми проблемами. У нас был случай что слетел локальный нейм-ресолюшн и ВСЕ первые запросы зависали на конкретно 30 секунд. "первые запросы" -- первый запрос на новой конекции. Решилось за 5 секунд рестартом сервера с опцией скип-нейм-ресолюшн... при ето, естесвено, никаких ИМЕНЫХ грантов не должно быть, только по ИП. (не доказано что это ваш случай, но вдруг поможет) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2017, 18:09 |
|
||
|
Висит таблица при первом открытии
|
|||
|---|---|---|---|
|
#18+
доки по теме: https://dev.mysql.com/doc/refman/5.7/en/host-cache.html https://dev.mysql.com/doc/refman/5.7/en/server-options.html#option_mysqld_skip-name-resolve ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2017, 18:10 |
|
||
|
Висит таблица при первом открытии
|
|||
|---|---|---|---|
|
#18+
javajdbchatedОчень прошу помощи... Уже головы сломали - всё без толку... Клиенты на части уже рву всё висит... задержки в конкретное число секунд 10, 30, 60, 300 могут быть вызваны сетевыми проблемами. У нас был случай что слетел локальный нейм-ресолюшн и ВСЕ первые запросы зависали на конкретно 30 секунд. "первые запросы" -- первый запрос на новой конекции. Решилось за 5 секунд рестартом сервера с опцией скип-нейм-ресолюшн... при ето, естесвено, никаких ИМЕНЫХ грантов не должно быть, только по ИП. (не доказано что это ваш случай, но вдруг поможет) Не, такой конкретики нет. Скорее в процентном соотношении. любая таблица базы. Допустим беру табличку полегче после рестарта сервера первый запрос к ней 2секунды, повторные уже как надо 0,2-0,1 убираю из запроса sql_no_cache работает кэш и запрос отлетает за 0.00001. Просто я пытаюсь понять это нормальная работа мускула или это симптом той болячки которую мы уже 3тьи сутки ищем.? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2017, 18:31 |
|
||
|
Висит таблица при первом открытии
|
|||
|---|---|---|---|
|
#18+
hatedjavajdbcпропущено... задержки в конкретное число секунд 10, 30, 60, 300 могут быть вызваны сетевыми проблемами. У нас был случай что слетел локальный нейм-ресолюшн и ВСЕ первые запросы зависали на конкретно 30 секунд. "первые запросы" -- первый запрос на новой конекции. Решилось за 5 секунд рестартом сервера с опцией скип-нейм-ресолюшн... при ето, естесвено, никаких ИМЕНЫХ грантов не должно быть, только по ИП. (не доказано что это ваш случай, но вдруг поможет) Не, такой конкретики нет. Скорее в процентном соотношении. любая таблица базы. Допустим беру табличку полегче после рестарта сервера первый запрос к ней 2секунды, повторные уже как надо 0,2-0,1 убираю из запроса sql_no_cache работает кэш и запрос отлетает за 0.00001. Просто я пытаюсь понять это нормальная работа мускула или это симптом той болячки которую мы уже 3тьи сутки ищем.? скачайте вот эту утилитку и посмотрите что она подсоветует. https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2017, 19:27 |
|
||
|
Висит таблица при первом открытии
|
|||
|---|---|---|---|
|
#18+
hatedЗдрасте всем! В общем: Пару дней назад хостер перезагрузил наш впс и начались взаимоблокировки запросов в PROCESSLIST со всеми вытекающими. Которых раньше не было. Сколько ни искали причину мы, сколько не писали б хостеру в тикетах причина до сих пор не найдена. Блокируются всегда запросы с одной и той же таблицей, но это логично так как она самая крупная ~750т. записей и самая востребованная)) Запросы блокирующие - всегда разные но всегда к этой таблице. Что смущает больше всего это не стабильное время выполнения запроса. Смотришь в PROCESSLIST висит запрос 300сек. блокирует кучу других. Копирую его - убиваю - делаю в ручную в phpmyadmin = отрабатывает за микросекунды. И вопрос не в кеше первое что попробовали это: set @@global.query_cache_size=0; результатов ни каких не дало. Едем дальше... Стабильно висят запросы при первом обращении: 1) перезагружаю сервер 2) Захожу в phpMyadmin под рутом и запускаю простой запрос select SQL_NO_CACHE count(`id`) FROM `bigTable` where tip=2 и получаю зависание длиною 30-70секунд! Висит всё! Даже SHOW PROCESSLIST висит и phpMyadmin не откликается. Иногда SHOW PROCESSLIST не висит, работает, но запроса этого он не показывает на всём пути его выполнения. 3) В итоге запрос всё таки отрабатывает и возвращает результат. Тут же запускаю его снова и он отрабатывает уже меньше чем за секунду! 4) Убираю SQL_NO_CACHE отрабатывает за несколько миллисекунд.(из кэша) 5) Проходит время таблица видимо притерпевает изменения данных. И снова запрос работает 50+ секунд... Что это и почему так происходит? блокировки? дедлоки? может с майисам поменять на иннодб? и посмотреть че получится. вероятный сценарий. 1) что-то пытается записаться в файл. 2) блочится файл ЦЕЛИКОМ 3) чтоние заблокированного файла не возможно - все висит. 4) повсле того, как убили блокирующий запрос все пошло бодрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.08.2017, 12:28 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39504377&tid=1830482]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
54ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 373ms |

| 0 / 0 |
