![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
asshole scriptin
Jul. 31st, 2015 04:36 pmvpatryshev$ cp ~/Downloads/4C24EBD1.crt.txt ./*.crt vpatryshev$ ls *.crt
Сегодня с утреца поглядел на страницу ексепшенов - ничего нету, всё тихо. Стал было радоваться тихому утру - можно какой-нибудь большой рефакторинг заварить, пока ничего не сломано (предыдущий большой рефакторинг сидит ждёт выхода в продукцию).
Вдруг кабум, эксепшен. Пошел смотреть в логи, нашел другой. Тут и Адам подоспел, говорит, а чёето у меня транзакция висит по пять минут.
Итак, три кварка к обеду. А что было?
1. Тыпычный дедлок, покажите мне стектрейс, я его починю. У меня когда юзер спасается, то его имущество спасается первым. (When a User is saved, some of its data is saved first). Ну а кое-где у нас порой, в другом коде и в другой транзакции, сначала спасаем юзера, а потом его имущество. Понятно, что эти две транзакции подрались и за юзера, и за имущество. Одна держит имущество, ждёт когда юзера отдадут, а другая наоборот.
2. Протечка транзакции. Затеял один умник устроить кеш на данные. Когда данные нужны, просим кеш, а у кеша есть метод, достающий данные. Он их достаёт через транзакцию. И возвращает. Ну как бы не очень монадично, верно? Так вот, а Хыбернейт, он же ленивый; он возвращает пустые обёртки; мол, попросят конкретный контент, прочитаем. Вот оно в кеше и валяется, нечитаное. И когда дело доходит полистать данные, нет ли там чего хорошего, транзакция давно уже испарилась, а кеш ещё нет. Так что кабум, взрыв на макаронной фабрике, выдёргивание из шляпы несуществующего кролика. Ну чё, надо немножко реифицировать, если решили покешировать.
3. Загадка. Адам пишет, мол, транзакция виснет. Посмотрели - виснет на локе, доступ к таблице, где сгенерированные key ranges сидят. Что смешно, в его конкретном случае в этой таблице всего одна строка. И если попинать майсиквел, то имеет место всего одна транзакция. И такое ощущение, что она сама себя и заперла. Следов другой транзакции нету. Да и квери-то весь - update ... set ... where... - одну строку апдейтнуть.
Перестартовали майсиквел, стали смотреть поведение. Оказалось, к этой таблице идёт бурный поток запросов, текущий ключ увеличивается на 100 несколько раз в секунду. Чтоб не разбираться в глюках, я просто увеличил размеры key range в 200 раз - и майсиквел затих. Всё работает, в смысле. Сейчас пойду поработаю над генератором ключей, чтобы он статистику подбирал да фиксил range size, пока не добьётся, чтобы не больше одного типа запроса в десять секунд. Какая разница, длинных чисел нам до сингулярности должно хватить. А там, глядишь, ещё 64 бита в дискурс добавят.
Вдруг кабум, эксепшен. Пошел смотреть в логи, нашел другой. Тут и Адам подоспел, говорит, а чёето у меня транзакция висит по пять минут.
Итак, три кварка к обеду. А что было?
1. Тыпычный дедлок, покажите мне стектрейс, я его починю. У меня когда юзер спасается, то его имущество спасается первым. (When a User is saved, some of its data is saved first). Ну а кое-где у нас порой, в другом коде и в другой транзакции, сначала спасаем юзера, а потом его имущество. Понятно, что эти две транзакции подрались и за юзера, и за имущество. Одна держит имущество, ждёт когда юзера отдадут, а другая наоборот.
2. Протечка транзакции. Затеял один умник устроить кеш на данные. Когда данные нужны, просим кеш, а у кеша есть метод, достающий данные. Он их достаёт через транзакцию. И возвращает. Ну как бы не очень монадично, верно? Так вот, а Хыбернейт, он же ленивый; он возвращает пустые обёртки; мол, попросят конкретный контент, прочитаем. Вот оно в кеше и валяется, нечитаное. И когда дело доходит полистать данные, нет ли там чего хорошего, транзакция давно уже испарилась, а кеш ещё нет. Так что кабум, взрыв на макаронной фабрике, выдёргивание из шляпы несуществующего кролика. Ну чё, надо немножко реифицировать, если решили покешировать.
3. Загадка. Адам пишет, мол, транзакция виснет. Посмотрели - виснет на локе, доступ к таблице, где сгенерированные key ranges сидят. Что смешно, в его конкретном случае в этой таблице всего одна строка. И если попинать майсиквел, то имеет место всего одна транзакция. И такое ощущение, что она сама себя и заперла. Следов другой транзакции нету. Да и квери-то весь - update ... set ... where... - одну строку апдейтнуть.
Перестартовали майсиквел, стали смотреть поведение. Оказалось, к этой таблице идёт бурный поток запросов, текущий ключ увеличивается на 100 несколько раз в секунду. Чтоб не разбираться в глюках, я просто увеличил размеры key range в 200 раз - и майсиквел затих. Всё работает, в смысле. Сейчас пойду поработаю над генератором ключей, чтобы он статистику подбирал да фиксил range size, пока не добьётся, чтобы не больше одного типа запроса в десять секунд. Какая разница, длинных чисел нам до сингулярности должно хватить. А там, глядишь, ещё 64 бита в дискурс добавят.
