T🐜
м.б. кто-то еще туда пишет с транзакциями?
Когда убрал та же ошибка?
Когда убрал та же ошибка?
Size: a a a
2020 September 27
T🐜
https://stackoverflow.com/questions/5836623/getting-lock-wait-timeout-exceeded-try-restarting-transaction-even-though-im
глянь, возможно есть зависшие транзакции. Их надо убить руками. Если таймаут слишком большой.
глянь, возможно есть зависшие транзакции. Их надо убить руками. Если таймаут слишком большой.
АВ
The Ant 🐜
м.б. кто-то еще туда пишет с транзакциями?
Когда убрал та же ошибка?
Когда убрал та же ошибка?
Пока ошибки новые не прилетели, но до добавления транзакций была такая-же историй. Кроме этих демонов других задач нет: show processlist, обновление крайне медленно происходит почему-то
АВ
The Ant 🐜
https://stackoverflow.com/questions/5836623/getting-lock-wait-timeout-exceeded-try-restarting-transaction-even-though-im
глянь, возможно есть зависшие транзакции. Их надо убить руками. Если таймаут слишком большой.
глянь, возможно есть зависшие транзакции. Их надо убить руками. Если таймаут слишком большой.
а по этому момменту вполне возможно, сейчас гляну, что-то там есть
T🐜
Пока ошибки новые не прилетели, но до добавления транзакций была такая-же историй. Кроме этих демонов других задач нет: show processlist, обновление крайне медленно происходит почему-то
Медленный апдейт может быть связан с настройками мускла. М.б. сейчас у вас сразу сброс данных на хдд при апдейте. И если диски медленные или забит io то будет притормаживать.
Или каждый апдейт вызывает перестройку индекса (что маловероятно, если данные не меняются практически). Нужно исследовать все варианты.
Или каждый апдейт вызывает перестройку индекса (что маловероятно, если данные не меняются практически). Нужно исследовать все варианты.
АВ
The Ant 🐜
Медленный апдейт может быть связан с настройками мускла. М.б. сейчас у вас сразу сброс данных на хдд при апдейте. И если диски медленные или забит io то будет притормаживать.
Или каждый апдейт вызывает перестройку индекса (что маловероятно, если данные не меняются практически). Нужно исследовать все варианты.
Или каждый апдейт вызывает перестройку индекса (что маловероятно, если данные не меняются практически). Нужно исследовать все варианты.
При выполнении: SELECT * FROM
information_schema.innodb_trx ORDER BY trx_started; у меня получается, что выполняется только 1 транзакция, остальные в ожиданииGE
Вообщем есть такой код, как заставить его работать в 10 потоков без SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction
Как сказали выше транзакция не нужна. В innodb все апдейты и так в транзакцию завернуты. Первое что бы я посмотрел, есть ли индекс на source link. Поиск не должен занимать много времени. Второе посмотрел бы нет ли ненужных индексов, меньше индексов - проще перестраивать. Так же я бы убедился что нету попыток обновить одну и ту же запись одновременно.
АВ
Как сказали выше транзакция не нужна. В innodb все апдейты и так в транзакцию завернуты. Первое что бы я посмотрел, есть ли индекс на source link. Поиск не должен занимать много времени. Второе посмотрел бы нет ли ненужных индексов, меньше индексов - проще перестраивать. Так же я бы убедился что нету попыток обновить одну и ту же запись одновременно.
На этот столбец индекс добавил только что, но есть другие индексы около 10 штук, для поиска. По другим индексам, их лучше удалять на время обновления, потом снова добавлять или оставить?
GE
На этот столбец индекс добавил только что, но есть другие индексы около 10 штук, для поиска. По другим индексам, их лучше удалять на время обновления, потом снова добавлять или оставить?
Не могу ответить на этот вопрос не зная специфики запросов ваших. Но если у вас 11 индексов на такую таблицу возможно вы действительно используете не ту бд или не так.
GE
Не могу ответить на этот вопрос не зная специфики запросов ваших. Но если у вас 11 индексов на такую таблицу возможно вы действительно используете не ту бд или не так.
Если много ищите по данным возможно вам elastic стоит поверх накрутить, индексы посносить. Но перед любыми переделками я бы удостоверился, что проблема именно в этом. Например в песочнице снес бы все лишние индексы и посмотрел бы как ведёт себя приложение.
YV
Вообщем есть такой код, как заставить его работать в 10 потоков без SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction
Очевидно, что этот код однопоточный. Чтобы он работал в N потоков, нужно его сделать многопоточным (ваш кэп).
Крутить «чтобы блокировки снимались быстрее» можно, но упираться все равно будешь так или иначе с ростом нагрузки.
Я бы посоветовал сам код сделать многопоточным.
Ключевые слова - mutex, семафор и тд
Крутить «чтобы блокировки снимались быстрее» можно, но упираться все равно будешь так или иначе с ростом нагрузки.
Я бы посоветовал сам код сделать многопоточным.
Ключевые слова - mutex, семафор и тд
АВ
Если много ищите по данным возможно вам elastic стоит поверх накрутить, индексы посносить. Но перед любыми переделками я бы удостоверился, что проблема именно в этом. Например в песочнице снес бы все лишние индексы и посмотрел бы как ведёт себя приложение.
Вообще "это черновая БД" в которую собирается вся информация, которую находит парсер, затем эта информация дополняется, обновляется по найденной дополнительной информации. Из этой базы уже будет строиться рабочая БД, в которой проставлены все связи и все структурировано. Рабочая БД будет загоняться в elastic. Пока примерно так
АВ
Вообще "это черновая БД" в которую собирается вся информация, которую находит парсер, затем эта информация дополняется, обновляется по найденной дополнительной информации. Из этой базы уже будет строиться рабочая БД, в которой проставлены все связи и все структурировано. Рабочая БД будет загоняться в elastic. Пока примерно так
Т.е вся основная нагрузка приходится на этот черновой вариант) как и все операции по обработке данных
YV
Вообще "это черновая БД" в которую собирается вся информация, которую находит парсер, затем эта информация дополняется, обновляется по найденной дополнительной информации. Из этой базы уже будет строиться рабочая БД, в которой проставлены все связи и все структурировано. Рабочая БД будет загоняться в elastic. Пока примерно так
Для такого плана нагрузки может Kafka подойти
YV
Но там парадигма работы станет немного другой. Ну и ресурсов сожрется дополнительно :)
E
Вообщем есть такой код, как заставить его работать в 10 потоков без SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction
а через job ы нельзя сделать?
АВ
а через job ы нельзя сделать?
и так работает через Jobs
YV
Ванга из отпуска пишет, что мютексы с ретраем должны помочь )
АВ
АВ
Всем спасибо за участие