Pull to refresh

Comments 30

Предлагаю пойти глубже и искать ошибки в ваших ошибках: вы обозначили проблему — Firebird и логика в хранимых процедурах.

Более того, вы указали, что «решение», которое предлагалось, было, видимо, «снести рассадник» Firebird. (Потому что в этом случае, портирование процедур над другую платформу потребует ручной работы).

Не было ли менее радикального (и дешевого по времени и ресурсам) решения, вроде тюнинга сервера, переноса базы на SSD (или даже в RAM)?
Два очень матерых (на мой непрофессиональный взгляд) админа, которые в течение полугода держали всё это безобразие, предлагали много чего по части железа (в т.ч. и SSD), но именно такого предложения в качестве решения той проблемы не было. По какой-то причине, видимо, они не считали это выходом, даже половинчатым.
У меня вызывает опасение такой «наскок». Когда видят морально устаревшие технологии (а эта сладкая парочка, это как раз вот оно, хрестоматийный пример), и вместо их модернизации, предлагают все снести, не оглядываясь на то что:
1) Разработка нового (и чтобы было в точности, как старое!)- мероприятие, требующее денег, времени и никогда не попадающее в план.
2) Это работало 15 лет, а теперь вдруг «шеф, все пропало, ААААААААА!!!!»
3) Персонал придется переучивать.

И вот тут у нас все эти затраты на одной чаше весов, а на другой части — какой-нибудь тормозящий запрос. Так вот, может, сначала стоит в консерватории поправить?
Добавлю, что проблема с производительностью базы должна быть проиллюстрирована результатами профилирования планов запросов (а в IBExpert очень наглядный анализ производительности), метриками загрузки диска/RAM/CPU, но никак не мнением
очень матерых (на мой непрофессиональный взгляд) админов, которые в течение полугода держали всё это безобразие
Что же за админы без метрик?
Что же за админы без метрик?

Согласен полностью. В то же время, мы боролись за появление другого, более фундаментального инструмента: Регламента работы техподдержки. В рамках которого появился бы SLA, с нужными бизнесу показателями, а следом и релевантные метрики. Первую рабочую версию Регламента мы написали, но когда Генерал увидел, что по тексту у него не одни только права, а внезапно появились обязанности и ограничения, он стал активно динамить процесс. Ну подумайте сами, зачем привыкшему к самодурству начальнику ограничивать себя в возможности устроить нагоняй сотруднику?
Интересный отчёт, спасибо.

Что касаются метрик, то они конечно велись (и надеюсь ведутся) в Нагиос. Без периодической переиндексации БД, например, начинал вырастать показатель Context Switches. Но само зависание могло произойти внезапно: при большом количестве транзакций в секунду резко возрастала нагрузка (CPU load) и СУБД просто переставала отвечать. Мы собирали отладочную версию FB, дабы выгружать дамп памяти, но его анализ ничего особенно не дал (судя по всему в этом был виноват механизм блокировок).
Проблема в том, что смоделировать подобную ситуацию на тестовом стенде не получалось, а на проде, когда разом отваливаются несколько тысяч водителей, клиенты не могут сделать заказ, любому сисадмину (даже самому матерому) проще и дешевле перезагрузить несколько сервисов, FB или виртуальную машину, чем пытаться выяснить причину зависания.

Версия была 1.5? Она это любит. И да, это блокировки.

Версию старались обновлять на последнюю 2.5.4 на тот момент, если не ошибаюсь. За пару недель до "отъезда" даже успели адаптировать бакенд и клиентов к FB 3.0 и перейти на него на одном из городов. Но результаты промониторить как следует уже не получилось...

Может вы они не считали это выходом, так как они (SSDs) уже использовались в течение некольких лет? Интересуюсь как тот самый ГГ, которого вы вскользь упомянули в середине статьи. Кстати тема ГГ не раскрыта до конца и основана на Ваших домыслах, ну или слухах...

Совершенно верно, Роман, на мнениях других людей, но нескольких и не из одной «обоймы». Ничто не мешает вам написать статью-дополнение со своей версией событий, происходивших где-то так между началом нулевых и летом 2016 года.
>Все Delphi-приложения были завязаны на использование данной СУБД
Приложения обычно не бывают абстрактными, для любой СУБД. Если СУБД менять, приложения придется переписывать.
А Delphi сама по себе не завязана ни на какие СУБД. Для нее они все одинаковы, разница только в используемых компонентах доступа, и умении разработчика приложений работать с СУБД.

Насчет Firebird — «обидные ваши слова» :-). Firebird тут являлся «зоной риска», видимо, только потому, что при разработке и сопровождении не было специалистов, действительно знающих эту СУБД. Я не припомню, чтобы компании в этой сфере обращались за оптимизацией к нам, например.
Хотя, может, в лучшем случае на известный профильный форум ходили.

Firebird, к сожалению, позволяет админу не знать даже как померять дисковый ввод-вывод. Не говоря про разработчика, который может не знать специфику версионности, оптимизатора, и прочего, что надо знать для любой СУБД.
Например — для Оракла было бы неплохо какие-то сертификаты иметь, а «Firebird фигня, и так сойдет».

Отсюда — на начальном этапе проект рвет и мечет, а при появлении серьезной нагрузки «почему-то» все идет наперекосяк. Это же для любой СУБД справедливо.
У фб реально что-то с производительностью (не упирается в дисковый io, но начинает тормозить), и с надежностью (периодически появляются невосстановимые бэкапы).
невосстановимые бэкапы сами по себе не появляются. Они являются следствием или повреждения БД, или определенных действий разработчика.
А насчет «реально что-то с производительностью» — у какой версии ФБ и архитектуры? Мы работаем с пользователями самых разнообразных систем на ФБ — и сотни пользователей, и сотни гиг, и т.д. Но никаких таких «что-то» не наблюдаем.
Разумеется, бывает всякое, например, какой-то редкий баг, который приводит к проблемам в 1-2 случаях на тысячу или десятки тысяч. Но делать из этого вывод, что «начинает тормозить», некорректно.

Я вам могу привести две явных причины торможения — не отключенный авто-свип и накопление мусорных версий. Но это не является дефектом Firebird. Это следствие непонимания архитектуры сервера при разработке приложений, и неумение администрировать сервер.
Подобные вещи можно встретить в любой СУБД.
К счастью я уже не занимаюсь фб, но могу сказать, что в регламентные процедуры входил бэкап и восстановление его на рабочую базу (в противном случае начинала падать производительность. Автосвип был отключен, ручной свип делался вместе с бэкапом еженочно, показатели мусора мы отслеживали). Кроме того БД «повреждалась» примерно раз в полгода — год, причины мы так и не выяснили.

Энтерпрайз пришёл в компанию и объявил разработчику что успешно работающее в течении 15 лет это то что нужно уничтожить (по сути аргументом было "сейчас модно в облака", а у вас тут болото), а потом называет ГГ, хотя по сути тот сделал самый правильный вывод из ситуации (собрался и ушёл, захватив с собой тех кто не согласен с подходом нового владельца).


p.s. думаю проблема не технологиях, статья думаю не сильно бы поменялась будь там что-то другое.

Кстати, мы как-то одной конторе помогли с оптимизацией. Через год там у них появилась проблема с железом. Тоже помогли. Параллельно смотрим — а ни один совет по оптимизации приложений и запросов не был сделан.
А почему?
Оказалось, что эта контора решила купить несколько других контор, у которых софт того же типа написан на другой СУБД. Начальство решило «унифицировать» имеющуюся систему с приобретаемыми путем переделки имеющейся. Соответственно, у разрабов пропал смысл что-то делать с текущей системой.
Сильно зависит от версии FB. Если там что-то типа 1.5, которое не умеет в многопоточность, 64 бита, и даже в utf-8 строчки, то да, определенные проблемы у них есть. Особенно в пиковые нагрузки.
Можно конечно брать рекорды, разгоняя процессор и оперативную память, менять хранилище (SAS->SSD->NVMe), и так далее, но это не сильно поможет. 1 поток останется 1, 2 гигабайта памяти 3200MHz останутся 2 гигами памяти.
В компании, где я работал, решили перейти с Delphi7+FB1.5 на VS2013+FB3. Тоже вылилось в большое количество головняка и денег. Причем железо так и не поменяли, даже не пробовали.
1.5 и 2.5 суперсервер не-многопоточный. Суперсервер и не используют обычно при количестве пользователей больше 5-10, особенно при наличии длительных расчетов. Классик любой версии — распараллеливается, и как раз используется в массе для средне и сильно нагруженных систем.
32бит 64бит — не принципиально, особенно для классика. И разница в производительности 32-64 бит не больше 7%.
Суперсервер у ФБ стал многопоточным только в 3.0. И вот только его уже рекомендуют использовать вместо классика.

В 2.5 же гибрид ещё, superclassic он отлично справлялся с работой и насколько помню тянул неплохо.

я не стал упоминать суперклассик 2.5 именно потому что гибрид — классик в одном процессе. Но он распараллеливался, да, и еще давал прирост на 10-15%, если было много запросов с сортировкой.

Собственно, у нас документ «Руководство по аппаратному обеспечению для СУБД Firebird» опубликован еще в 2015 году.
http://www.ibase.ru/files/firebird/Firebird_Hardware_Guide_2015_rus.pdf
с описанием всех архитектур, как их тюнить, и т.д.
Такси 373 и Gett. История наделала некоторого шуму в ижевском айтишном болотце. Искали народ, и предлагали не просто бабки, а БАБЛИЩЕ. Но очень уж мутно всё как-то выглядело насчёт перспектив.

Я тоже ходил к ним в гости, и на унаследованный код одним я глазом успел глянуть — прямая дорога в мусорку такому легаси. Итог закономерен, если автор не приукрашивает.
Даже Firebird 2.5 на правильном железе держит 1500 и выше коннектов, во вполне себе нагруженных проектах, когда есть грамотные ДБА или профессиональное сопровождение. И кстати, на Firebird действительно много такси-сервисов написано и работает, обычно на дефолтных конфигурациях, т.е. вообще без оптимизации и без ДБА.
Мда. Решили бабла заработать немножко. Закрыв глаза на анализ, риски и т.д. Поимели проблем и… обвинили во всем firebird. К успеху шли, ребята…
Итак, пришел человек на готовый работающий 15 лет, приносящий доход бизнес.
И захотел он бизнесом крутить-вертеть по своему хотению, по инвесторов велению.
Естественно обосрался, за что был пидорнут на мороз. Кто виноват? Все, кроме него. Включая «генерала», и «ГГ», которые всё это создавали с нуля

По поводу отсутствия документации и “черного ящика” автор тоже лукавит (пытаясь объяснить этим свои неудачи) либо действительно был не в курсе, что она есть: во- первых — это исходный код программ, комментарии к таблицам и хранимым процедурам БД, во-вторых — система управления проектами в Redmine.
Конечно для непосвященного в тонкости работы Такси человека вся эта бизнес-логика может показаться сложной и запутанной, как и архитектура (стандартная трех и местами двухзвенная), но это уже другая история…
Кстати, по словам ИТ-директора “Энтерпрайза” именно простая архитектура ПО стала одной из причин, по которой их выбор пал именно на эту компанию. И конечно, автору, следовало бы сравнить сложность настройки на примерах других систем (например “Такси… стер”, где количество настроек в системе приближается к тысячам).

Скажем честно, high-level описания процессов никогда не создавалось.
Скажу больше, у меня есть сведения, что описаний не создавали намеренно, по указанию руководства. Типа, если кто сопрёт, чтобы не смог разобраться. Хитрый план по выкапыванию ямы себе :)
Sign up to leave a comment.

Articles