есть такой варик, когда бд дают ресурсов по мере нужного, ночю минимум,  но когда штати просипаютса дает больше, и таким образом ценообразование +/- то же

У нас физ сервак

знач мой косяк

Всем привет, после запуска приложения на проде через пару часов в логах начинает сыпаться ошибка: "log writing failed. deadlock; recursive locking", в то же время начинает течь оперативная память. Может кто сталкивался с подобным, буду рад любой наводке)

Ruby 2.5.3
Rails 5.2.4.2

все ок, я просто не сказал об этом, сорян 🙂

а какая бд

вижу

он нужен был когда всю эту красоту писали 🙂

Оптимизацией они тоже занимаются

иногда, помимо индексов, ничего не меняя в логике приложения, ещё можно поиграться с уровнями изоляции транзакций. у меня такое было несколько раз что рид-лок создавал затык, который мы оперативно починили перейдя на read uncommitted потому что всё равно читалось один раз.

это например помогает для не сильно важных вещей типа "обновить в своей записи кеш каунтера числа записей по foreign key в другой таблице", где ничего страшного что может этот кеш иногда отойти от реалий - в контексте где выводится только сам каунтер а записи сами не запрашиваются там часто не так важно чтобы он был абсолютно точным сию секунду, а если ты загружаешь записи, тогда и точное значение будет

вещ звучит как не сильно важная, но может немного ударить по перформансу если эта "другая таблица" активнее основной

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

ну и ещё есть стандартный момент в базах данных - нередко так бывает что в записях есть сериализованные поля и несериализованные поля, а mysql любит засасывать в свой внутренний кеш записи целиком. в итоге если размер записи (в байтах) оказывается большой из-за сериализованной части, которая в ряде транзакций не используется вообще (а используются только foreign keys / несериализованные поля), mysql будет переполнять свой внутренний кеш очень быстро. и иногда можно добиться значительного улучшения качества работы mysql кеша (и как следствие общего перформанса системы) тем что вынести сериализованные блобы в другую 1:1 таблицу

это конечно немного сложнее чем индекс добавить или уровень изоляции транзакции снизить, но обычно не требует серьёзного пересмотра того как что внутри хранится

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

есть какие-то трики которые можно попробовать улучшить безотносительно даже схемы данных 🙂

но, по-хорошему, после изобретения редиса надо серьёзно пересматривать многие свои представления о базах данных 🙂 уж очень хорошая штука

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

Да, согласен!