Резко участились deadlock

очень увлекательно

Продолжать?

я томно вздохнул, мое сердцебиение участилось

Более того, каждый день удаляется примерно 100 000 записей

большую таблицу
46 млн. строк
большую

Ну ок.

сократил до 6 млн. Вот собственно и все. После этого посыпались deadlock.

Так залей туда всё обратно и еще 50М записей накинь. Будет 1 deadlock за 2 года.

Если я залью обратно, то таблица снова вырастит, но я же добиваюсь(добился) обратного

Тоже аналогичная проблема. У меня по садовому участку было разбросано 750 граблей, но по голове от них получали не чаще одного раза в год. Я решил убрать 700 граблей, но теперь при оставшихся 50-ти все стали получать по голове 2-3 раза в день. Что я сделал не так? И как починить, что бы было как раньше, не более одного раза в год?
Аналогия стебная. Но вы реально дали очень мало информации. deadlock в субд сам по себе не происходит. Нафиг никому ненужная субд (по аналогии с граблями на которые не наступают) сама deadlock не вызовет.

Так залей туда всё обратно и еще 50М записей накинь. Будет 1 deadlock за 2 года.

Подстолом. Это прям от души написано :))))) Но в каждой шутке есть доля шутки. И это действительно может помочь. Но конечно не исправить сам косяк заложенный изначально.

я неловко пытаюсь скрыть свое возбуждение, закрывая глаза от смущения

попробуй переключить базу данных в myisam

у нас так тоже биллинг постоянно вис и тормозил, и в интернете посоветовали myisam

попробовали - помогло, полет нормальный, 100% и вам поможет

Таблица inodb, deadlock происходит на update, каждый день из таблицы удаляется около 100 000 записей, каждые 5 минут в нее записывается примерно 200 записей.

А еще, она обновляется произвольно, set count + 1 where id = x, вот именно на этом и происходит deadlock

Дык, не тормозит же. Да и только на 1 таблице

я думаю дело в появившейся фрагментации граблей. попробуйте сделать ребилд участка

у нас так тоже биллинг постоянно вис и тормозил, и в интернете посоветовали myisam

Переводите ваш биллинг на memory, он еще быстрее

Если я залью обратно, то таблица снова вырастит, но я же добиваюсь(добился) обратного

Ну так зато дедлоков не будет.

set count + 1 where id = x

К дедлокам не приводит, к ним приводит несколько таких операций в одной транзакции (если конечно id это ключ)

Но, объяснить такое поведение можно:

раньше конкурентные операции не успевали друг другу вставлять палки в колеса, а после чистки, количество мусора уменьшилось(и сканы стали быстрее), и они начали встречаться.

чинится только правкой sql, а именно: сохранением порядка обновлений в параллельных транзакциях

либо просто апдейты в один поток выполнять

либо хватать монопольную блокировку на таблицу в каждом апдейте

без эскуэля тут не угадать по гуще

да, мы думали посадить на редис, но alchemy не умеет с ним работать

каждый день из таблицы удаляется около 100 000 записей, каждые 5 минут в нее записывается примерно 200 записей.

57600 прибыло 100000 убыло. Итого, минус 42400 записей в сутки, подождите менее полугода и на каждой итерации удаления таблица станет пустой.

А еще, она обновляется произвольно

Все прекрасно в этом мире.

Да, мы так же переехали на постгре с этого хлама, пока всё нормально.

Эх...петросяны одни

когда отсутствуют телепаты, их традиционно заменяют петросяны.

К дедлокам не приводит, к ним приводит несколько таких операций в одной транзакции (если конечно id это ключ)

С чего бы это? deadlock в одной транзакции? Вы пошутили?
Но дальше вы правильно написали в части конкурентных транзакций и почему на большем обьеме реже случался deadlock. На это изначально прозрачно намекнул crutch_master «Так залей туда всё обратно и еще 50М записей накинь. Будет 1 deadlock за 2 года.»

Совсем нет. Читайте внимательно что вам написали, мы все «намеками» конечно хоть и о том же, а вот анон выше Резко участились deadlock (комментарий) не поленился разжевать.

не, дедлок с транзакциями на 2 и более операции.

Но идея с «вернуть мусор обратно» и «работает не трожь» конечно классная, но ведь может не сработать (фиг его знает как там иннодб страницы кладет)

«грабли то нужно вернуть не просто во двор, а на старые места»

не, дедлок с транзакциями на 2 и более операции.

А главное, я дважды написал то же самое. Не мой день

Да там небось какая-то жесть в коде. ОП пока так и не озвучил, какие еще запросы в транзакции, если таковая вообще имеется.

Форум же «Admin», вероятно просто еще одна жертва программистского произвола

ОП пока так и не озвучил, какие еще запросы в транзакции, если таковая вообще имеется

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

ОП пока так и не озвучил, какие еще запросы в транзакции

Да при чем тут в транзакции (одна штука)? там какие только могут не быть, к deadlock это не приведет никогда если она единственная в один момент времени к этим данным. deadlock возникает на конкурентных транзакциях, когда «два, три, четыре... человека хотят схватить последнюю буханку хлеба с полки в магазине».

Я все напутал, точнее перепутал. Таблица эта не 46 млн, а ~30000, и не чистил я ее. Я с другой спутал. В ней я индекс добавил, после чего начались дэдлоки

Переводите ваш биллинг на memory, он еще быстрее

memory ваш - прошлый век. Вот blackhole - это да, это на века. Самый быстрый в мире insert, отвечаю!

Без индекса на поле, по которому выбирается строка для апдейта, у тебя лочилась вся таблица, а с индексом - только одна строка. Поэтому, раз ты не в состоянии сам решить проблему, и не в состоянии предоставить код, чтобы тебе помогли, то дропай индекс :)

дк, myisam же присоветовали

Я все напутал, точнее перепутал. Таблица эта не 46 млн, а ~30000, и не чистил я ее. Я с другой спутал. В ней я индекс добавил, после чего начались дэдлоки

"...Пёрышки у птички, у кошки две косички..."

Да там небось какая-то жесть в коде.

Да там все ногами писали, я более чем уверен.

Я все напутал, точнее перепутал. Таблица эта не 46 млн, а ~30000, и не чистил я ее

И как так можно напутать? Дай контакты твоего работодателя.

В ней я индекс добавил, после чего начались дэдлоки

Ну так убери его. Нет индекса, нет проблем.

дэдлоки

Может ты все перепутал и это не дэдлоки, а ошибки уникальности? Может надо не уникальный индекс сделать?

Да я сам охренел от такой разработки.

Эх...петросяны одни

По тому что ты написал вообще ничего нельзя сказать о том, что происходит. Остаётся или гадать по картам таро или петросянить.

перестаньте удалять записи явно. ставьте пометку на удаление.

Может ты все перепутал и это не дэдлоки, а ошибки уникальности? Может надо не уникальный индекс сделать?

Да тут так же вопросов больше чем ответов, может там какой составной индекс из N fields varchar(100500) и фигачим update на всю таблицу, перестроение тоже занимает время, а в это время второй запрос такого же «класса». Я с вами солидарен тут или карты или кофейная гуща или телепатия, или все-таки ТС расскажет правду.

Решил я создать индекс дополнительный. Вот собственно и все. После этого посыпались deadlock.

нет, запросы точно показывать не надо. давай в угадайку играть.

Обычный запрос update tbl set count = count + 1 where id = 6

так может быть?

t1:

update tbl set count = count + 1 where id = 6;
update tbl set count = count + 1 where id = 5;

t2:

update tbl set count = count + 1 where id = 5;
update tbl set count = count + 1 where id = 6;

Ну понятно, ты клонишь к тому, что одновременно обновляется одна и таже запись? Такое может быть, если быстро открыть две вкладки(просто пример, в реале чуть по другому, но суть такая же).
Но почему резко возрасли этм локи? Потому что я таблицу почистил и быстрее обновление пошло?

Ну понятно, ты клонишь к тому, что одновременно обновляется одна и таже запись? Такое может быть

Все замечательно. Допускаем конкурентное изменение одной и той же записи. Впрочем вам об этом уже много раз и в разных выражениях написали выше. Чините код.

Таблица эта не 46 млн, а ~30000, и не чистил я ее
Потому что я таблицу почистил

Вы когда определитесь с тем что вы делали?

В ней я индекс добавил, после чего начались дэдлоки

После добавления индекса план запросов стал другой. Т.е. например раньше была временная таблица, а теперь нет, или наоборот и т.п. Без конкретики тут обсуждать нечего. Изучай свои запросы.

Вы когда определитесь с тем что вы делали

Изначально спутал с другой таблицей. Нынешняя это 30000, в которую я добавил индекс. Больше ничего не делал.

Что изучать? Допустим я делаю 3 запроса на обновление в 1 момент времени, то есть одновременно. Это может вызвать локи? Если да, то неужели мускул такой тупой, что не может подожать, а потом обновить эти строки?

Потому что я таблицу почистил и быстрее обновление пошло?
gobot ★★★ (24.08.19 17:40:28)

Это простите что? У вас угнали акк и кто-то за вас пишет?

Да не чистил я эту таблицу, говорю ж спутал