Ры (pbl) wrote,
Ры
pbl

Одолели меня воспоминанья относительно крейзиест щыт айв син ин май (прафешнл) лайф:

413 Request entity too large



Эта адская хуитролия стоила мне, наверно, пять лет жизни. Было это, мо-поему, на втором году моей службы на нынешнем месте. Во-первых, доступа к продакшну у меня тогда не было. Что меня в целом не только устраивало, но и радовало. Но не в данных обстоятельствах: воспроизвести эту хуйню на девелопменте было невозможно, поскольку клиентских сертов на локальном сервере не было. Во-вторых, на продакшне был отключен error_log. В третьих, я даже не знал, что у нас используются клиентские сертификаты. Я ебался несколько недель, пытаясь понять, что, блядь, здесь вообще может быть не так, но вотще. Администраторы, разумеется, проблему игнорили в ноль (ваша же система дохнет, вот и ищите).

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

Что не принесло мне большого облегчения.

В общем, у нас в продакшне до сих пор живет адейший хак в недрах клиентской либы, который долбится гетом к (пустому) certup.txt, если пост заваливается (и потом повторяет пост, естественно). Более того, проблема стабильно поднимает свою уродливую башку в разных частях системы каждые несколько месяцев, но теперь ей не удается вогнать меня в глубокий ахуй дольше, чем на пятнадцать минут.

4k limit on text nodes



Это можно было нагуглить. Можно, безусловно. Я потом и нагуглил. Но ситуация была такая: я только начал работать. С клиентской частью я на тот момент не сталкивался что-то около четырех лет (и потом, кстати, никогда ей особо не занимался - я же гребаный бызныс-рульщик, а не какое-нибудь интерфейсное дизайнеро).

Работала у нас, как водится, левая библиотека пятилетней давности, кривая и косожопая. (Наш техдир любит велосипеды с квадратными колесами - они же зато готовые.) Несколько десятков кил плотного безумия.

И вот я вижу охуеннейший эффект - что от моих сервисов до клиента больше четырех кил (шматья уя же) в скаляре не доходит. Ну просто тупо не доходит. Это я вижу после второго моего продакшна эвер. В этом самом ебаном продакшне. У заламывающего руки тикетинга, без которого никто нам ни цента денег не даст, и мы все умрем голодной смертью. И у меня четко перед глаза развилка - или искать по-правильному, пока весь бизнес рыдает кровавыми слезами и точит на меня хедсеты, или срочно-срочно рисовать кривую заплатку. Угадайте, что я сделал? Правильно, заплатку. Все скаляры в сервисе начал резать на массивы шматьями по килобайту, и (полу-)прозрачно собирать их обратно перед мордой клиента.

И это, блядь, заработало.

А потом я уже начал гуглить.

Когда нашел - ругался непрерывно полчаса сплошным матом. Что не принесло мне значительного облегчения.

Особенно меня порадовал знатный пи... рограммист Борис Збарски. Если кто сталкивался - он очень любил зарубать все чейнч риквесты с аргументацией "в стандарте написано, что можно, как у нас, мы не будем делать по-другому". Тут же ситуация немножечко не такая. Потому что в стандарте совершенно ясно написано, что так как у них - нельзя.

И вот, всего через восемь лет...
Boris Zbarsky (:bz) 2011-04-15 19:01:23 PDT
HTML5 parser fixed this.
Хотя, чорт. Какое отношение HTML5 парсер имеет отношение к их ыхымэльному парсеру? Ну не буду проверять уж.

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

Репликация такая репликация



Здесь решительно никакой мистики не было, а сводилось все к последствиям политики - в целом здравой, щетаю, - "разработчикам не положено знать, какая у нас инфраструктура" и раздолбайства этих самых разработчиков. Были у нас места, где после INSERT'а ряд сразу (для некоторых значений "сразу") доставался обратно по первичному ключу... (ну дальше можно не рассказывать)

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

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

$k



А вот это было чисто внутреннее дело. Работал у нас один юноша (хороший, кстати, мужик - я бы с ним с удовольствием пивка выпил бы; а вот работать вместе больше не хотел бы), который испытывал большие проблемы с именованием чего бы то ни было. Ну он не то что не мог, ему лень было. Он такой расслабленный, что практически раста, хотя не курил никогда.

В общем, он все подряд называл "кы".

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

Эффект от данной баги не то чтобы какой-то особенный мистический ужас вызывал - ну просто очень неприятно, что есть примерно процентная вероятность, что сэйл будет насмерть запорот строго посреди процесса. И воспроизвести это очень трудно.

В целом вся конструкция выглядела примерно так - в данном куске процесса, на нескольких стадиях, этот товарищ сначала полз по сессии, вытаскивая пассажиров из сэйла и засовывая их в $k по рефренсу.

Двумя тысячами строк позднее, в одной весьма редкой ветке, обусловленной как состоянием бизнес-объекта, так и поведением пользователя, он попадал в цикл, где $k использовалось в качестве счетчика.

А потом, при переходе на следующую стадию процесса (что происходило не всегда, а только, опять же, при определенном поведении пользователя), вся эта хуитролия из сессии сбрасывалась в базу.

А наш техдир страшненько не любит транзакционные энджины - они же такие ме-е-е-едленные. Ну хотя нет, вру, он не из-за производительности их не любит, а из-за проблем с рикавери.

В общем, в том редком случае, когда юзер последовательно попадал во все три ветки (один процент), последний пакс в его ордере превращался в тыкву число двадцать. У которого, конечно, не было никакого метода syncToStorage() (поручики, переопределение числа 20 в качестве решения проблемы не предлагать - здесь вам не джвм!) Происходило это ровнехонько посреди дампа всего состояния, в результате чего сэйл неизбежно завязывался в узел и пропадал в чорной щели между валидными стейтами.

Не надо, думаю, объяснять, как я матерился, и как мало мне от этого полегчало.

Боевой товарищ к тому моменту от нас уже съебал, и слава богу - я бы его за такое голыми руками удавил бы, а мужик он все-таки хороший.

Баден... Баде... Бад... Ба...



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

Совсем незадолго до того я распинался, что, мол, вспомнил - самое няшное в перле это цпан.

В данном случае почти не матерился, а просто тихо скорбел. Но все равно облегчения это мне не принесло.

WORK_FAIL



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

Коротко, gearmand роняет джобы. В зависимости от размера пэкэта и от каких-то еще невнятных переменных. Роняет не всегда, а с некоторой вероятностью. Мне удалось на девяносто девять процентов убедить как себя, так и КА/АК, что проблема не в клиентском/воркеровском апишнике, а именно в балансере.

Не знаю, стану ли я материться полчаса, когда мы все-таки разберемся, но уж облегчения мне это почти наверняка не принесет.
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments