зачем gallery_grabber блокирует базу?

[webmaster]

Разбираясь с тормозами на сервере смарта заметил в логе запись, долго думал...
01:36::query_time=7.1607100963593::query=LOCK TABLES rot_gallery_info WRITE:: <= /.../bin/gallery_grabber.php (db_query) (time: 7.1607100963593)

Зачем граббер блокирует базу которая используется практически во всех запросах? Что он такого важного может делать с базой чтобы это требовало блокировки изменений от всего остального? Стоит только ему запуститься как запросы на mysql-сервере начинают накапливаться и на несколько минут наступает полная жопа. Потом конечно все рассасывается потихоньку до следующего запуска, но зачем вообще это???

[admin]

Что бы чекеры с разных сайтов Но юзающие одну базу не начали проверять одну и ту же галеру.

При этом это не время лока, а время пока ждали что б его получить.

Чекер работает постоянно, как вы определили меду какими запусками именно чекер что там накапливает?

[webmaster]

Пипец. Для избежания какого-то несчастного дублирования блочить целиком гигабайтную базу которая используется всем чем можно. У меня комментарии только матерные сейчас.
На совсем не слабом 2-х процессорном выделенном только под мускул сервере 128Гб оперативы, все что можно хранится в памяти, но от вручную поставленных локов оно естественно не спасает.

Определяется очень просто, по логам db_queries и slowlog мускула, именно с этого запроса начинаются тормоза. Даже аут на галеру и тот по 30 секунд отрабатывает в течение нескольких минут после этого лока.

[tgptraffic_biz]

Я присоединяюсь. МЫ взяли сервак чисто под БД, конфиг
CPU Dual Xeon E5-2630
RAM 64GB DDR3
HDD 2x 480G SSD

Вынесли туда 3 мастера и порядка 20 слейвов. СЕйчас наблюдаем как это все работает несколько дней уже.
Так вот сервер падает у нас во время лока таблиц, скапливаются запросы и начинается задница.
Может можно какую-то бету сделать или настройку чтобы это обойти можно было ?
Потому что тут ничего придумать нельзя и сервак под мускуль теряет смысл

[webmaster]

у нас под базой сервер похожий, только памяти 128Гб и она DDR4. База 460к галерей. При достижении трафа в 40к-50к начинаются тормоза, slowlog в php говорит про долгое выполнение out.php и index.php смарта, как правило это при переходе на галерею или аут.

Админы долго не могли понять в чем дело т.к. на сервере с базой нагрузки как таковой нет ни по процессору ни по дискам, свободной памяти полно, буфера все выделены с большим запасом. Но при этом копится большое количество запросов. И даже простые запросы вида SELECT gd.gallery_id FROM rot_gallery_data1 as gd LEFT JOIN rot_gallery_info as gi on gi.gallery_id = gd.gallery_id WHERE gallery_slug = 'parking-court' and gallery_type IN (0, 10) начинают выполняться по 6-7 секунд. EXPLAIN ничего странного не показывает, индексы все есть и используются.
В результате поймали этот gallery_grabber.php который оказывается самый нужный на сервере и может запросто забрать под себя самую главную таблицу просто чтоб "чекеры не начали проверять одну и ту же галеру". Ну а когда запросов много - они за время лока успевают скопиться, и дальше уже идет по нарастающей...

[admin]

Ок, включайте чекер и скидывайте шел где он лочит все и копит запросы, я проверю в понедельник

[tgptraffic_biz]

Ситуация в принципе похожа. Только у нас вынесен нетворк целый, 3 мастера с базами по 600к + слейвы.
Траффа 1.2-1.5 ляма. ТОже тормоза и даже падения, админы всем известные всем тут софтком, возимся уже дней 5

[admin]

И при включении чекера все сразу ок?

[webmaster]

Для тех кто не ждет милостей от автора и не готов ждать проверок в понедельник и возможного исправления когда-нибудь - рассказываю как наши админы справились с проблемой:

1. Основному серверу mysql присвоен номер 1
2. Сервер реплицировали на еще один инстанс в режиме slave read/only штатными средствами MariaDB с присвоением ему номера 2
3. Настроен прокси для mysql-запросов, мы пользуемся ProxySQL. На прокси настроены правила которые распределяют запросы на чтение на сервер 2, запросы на запись - на сервер 1
4. Смарт переключен на ProxySQL вместо прямого соединения с серверами mysql

В результате всего сделанного - имеем стабильный и быстрый ответ для основного количества запросов - ауты, генерация страниц и т.п. с сервера 2 и постоянно перегруженный сервер 1 который разруливает все остальное.
Нельзя сказать что проблема решена совсем, но влияние блокировок минимизирована, теперь хотя бы ауты не тормозят как раньше. Что делать с перегрузом сервера 1 пока думаем, админы говорят кроме этого лока еще много интересного вылезло... Пока анализируют что как влияет.

Жаль только что такими вопросами приходится заниматься пользователям скрипта, я как-то надеялся что смарт больше рассчитан на серьезную нагрузку... Но блокировка таблицы галер целиком для нужд граббера заставила в этом очень серьезно усомниться.

[admin]

На примере этого топика можно в режиме реально времени наблюдать как вместо того что б вместе разобрать проблему люди начинают делать костыли, при апдейте костыли отваливаются и угадайте кто виноват?)