https://ruby-doc.org/stdlib-3.1.0/libdoc/logger/rdoc/Logger.html#method-i-add > Bugs¶ ↑ > Logfile is not locked. Ебать добрый вечер. Пользовался этой поебенью с сотнями процессов, пишущих в один файл, годами — и ни разу ничего не пидорасило. Похоже, я чего-то не знаю про прыщавый write в файлы.

Обнаружил, что cочетание activerecord и тредов вредно для здоровья. В activerecord все взаимодействие с базой данных внутри процесса проходит через пятиэтажную систему блокировок. Они используются для кеша prepared statements и прочих вещей, которые тебе на хуй не обосрались. Неряшливый профайлинг показал, что в ожидании лока треды проводят по 5% времени. Но это ерунда. Беда в том, что эти блокировки иногда как-то так стакаются, что тред просыпается уже через 5-15 минут, когда соединение уже прибито по idle_in_transaction_timeout. У меня это происходит в 1 случае из 7 000 000 на сильно загруженном сервере. Activerecord — это безнадежно переусложненная хуйня. Не берите activerecord. Что брать — пока не знаю.

Как писать на сраном ruby чтобы не жрало память: — дергай GC.start full_mark:false после работы, либо перед тем, как поспать или послушать соскет; — ребутай свои процессы время от времени, чтобы убрать эффекты от фрагментации памяти, но желательно gracefully это делать, иначе граблей не оберешься; — плоди процессы при помощи fork(), он дает copy-on-write; — переделай параллельность с процессов на треды — это даст гораздо меньше выигрыша, чем кажется, и гораздо больше граблей, чем кажется, но все-таки работает; — выкинь activerecord, его писали жопой и не переделывают.

https://github.com/rubygems/bundler/issues/7135 сука блять ебаное говно заебался дебажить

поставил lolcat из aptitude на debian stable @ из коробки блюет трейсбеками

> nil || false => false Кто догадался, как это работает — тому я не завидую.

https://github.com/atipugin/telegram-bot-ruby/blob/master/lib/telegram/bot/client.rb#L24 Ничего особенного, просто библиотека перехватывает обработку сигнала. Не, ну нормальная практика. Я ничего против не имею. Я не имею в виду, что я чуть не ебнулся головой, пытаясь понять, почему мой код с обработкой сигнала не работает. Вовсе нет. Ничего подобного.

Радикально решил проблему с потреблением памяти долгоживущих процессов на ruby. Процесс теперь перед началом работы вызывает инновационную функцию fork™, после которой родитель остается сидеть-пердеть с waitpid, а потомок — собственно, заниматься работой. Спустя N итераций, либо N секунд (через час где-то) процесс-потомок завершается, а проснувшийся родитель тупо создает его обратно при помощи той же инновационной функции fork™. Происходит это все быстро и совершенно незаметно. Вся нафрагментированная и натёкшая память высвобождается. Не знаю, куда ее теперь девать.

Тем временем в доебане поломатый бандлер: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955405

https://framagit.org/zoggy/ocaml-iri/-/blob/master/iri_lexer.ml#L142 Блядь, даже для обоссаного окамла есть библиоетка для парсинга ссылочек с юникодом, которая обрабатывает точки с запятыми нормально! Господи, блядь, за что?

addressable не понимает точки с запятой в query, потому что автор мудак: https://github.com/sporkmonger/addressable/issues/114#issuecomment-16338080 URI в стандартной библиотеке не понимает non-ascii вообще.

https://github.com/toland/patron/blob/1067878599e5ef76276a14d800cb6f9dd8cc4e9e/lib/patron/response.rb#L31 да мои вы заботливые

addressable писал еблан. Что еще взять для простой нормализации обоссаной http-ссылки в виде строки?

https://threatpost.com/bitcoin-stealers-700-ruby-developer-libraries/154937/ Рубрика «велосипедные пакетные менеджеры».

Ну вот такая вот история, например. Подключил модный гемчик. Сделал huita.try(:[], :wtf) А по-другому я нынче и не пишу уже — страшно. Для тех, кто современных рубей не видел — это абсолютно то же самое, что и huita[:wtf], но вызванное так, чтобы если вместо huita мне подсунут не хеш, а что-то другое, то в результате всего лишь будет nil, а не падение с эксепшоном. И все равно все ебнулось с undefined method `wtf' и совершенно невменяемым трейсбеком. Потому что huita принадлежит к классу из гемчика, который сделан через поебень под названием virtus. Этот ебаный virtus переопределил метод [] и заменил его на #send, потому что, э-э-э... Ну, чтобы пиздато было, наверное. Часа времени на дебаг как не бывало.

Любишь activerecord — люби и долгоживущие процессы по полгига. Нет, с этим ничего нельзя сделать.

% find .gem -name "development.log" .gem/ruby/2.3.0/gems/factory_girl_rails-4.8.0/tmp/aruba/testapp/log/development.log .gem/ruby/2.3.0/gems/factory_girl_rails-4.9.0/tmp/aruba/testapp/log/development.log .gem/ruby/2.3.0/gems/nested_form-0.3.2/spec/dummy/log/development.log

Выкинул на хуй пуму и заменил единорогом. В 2 раза больше воркеров жрут при этом меньше памяти. Рекомендую.

По непонятной мне причине puma через несколько часов монотонной долбежки юзверями начинает отвечать на запросы несколько секунд. Как это дебажить — не имею понятия. Сворачиваю на хуй это поделие и уебываю обратно на unicorn.

https://github.com/atipugin/telegram-bot-ruby/commit/ba40802ffb4f94853be964f29c96f36d1e39376e а давайте сломаем на хуй api ну просто так, лучше же стало было два аргумента, а сейчас хеш с двумя элементами нормальный же коммит, а?