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

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

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments