Comments 30
Более того, вы указали, что «решение», которое предлагалось, было, видимо, «снести рассадник» Firebird. (Потому что в этом случае, портирование процедур над другую платформу потребует ручной работы).
Не было ли менее радикального (и дешевого по времени и ресурсам) решения, вроде тюнинга сервера, переноса базы на SSD (или даже в RAM)?
1) Разработка нового (и чтобы было в точности, как старое!)- мероприятие, требующее денег, времени и никогда не попадающее в план.
2) Это работало 15 лет, а теперь вдруг «шеф, все пропало, ААААААААА!!!!»
3) Персонал придется переучивать.
И вот тут у нас все эти затраты на одной чаше весов, а на другой части — какой-нибудь тормозящий запрос. Так вот, может, сначала стоит в консерватории поправить?
очень матерых (на мой непрофессиональный взгляд) админов, которые в течение полугода держали всё это безобразиеЧто же за админы без метрик?
Что же за админы без метрик?
Согласен полностью. В то же время, мы боролись за появление другого, более фундаментального инструмента: Регламента работы техподдержки. В рамках которого появился бы SLA, с нужными бизнесу показателями, а следом и релевантные метрики. Первую рабочую версию Регламента мы написали, но когда Генерал увидел, что по тексту у него не одни только права, а внезапно появились обязанности и ограничения, он стал активно динамить процесс. Ну подумайте сами, зачем привыкшему к самодурству начальнику ограничивать себя в возможности устроить нагоняй сотруднику?
Что касаются метрик, то они конечно велись (и надеюсь ведутся) в Нагиос. Без периодической переиндексации БД, например, начинал вырастать показатель Context Switches. Но само зависание могло произойти внезапно: при большом количестве транзакций в секунду резко возрастала нагрузка (CPU load) и СУБД просто переставала отвечать. Мы собирали отладочную версию FB, дабы выгружать дамп памяти, но его анализ ничего особенно не дал (судя по всему в этом был виноват механизм блокировок).
Проблема в том, что смоделировать подобную ситуацию на тестовом стенде не получалось, а на проде, когда разом отваливаются несколько тысяч водителей, клиенты не могут сделать заказ, любому сисадмину (даже самому матерому) проще и дешевле перезагрузить несколько сервисов, FB или виртуальную машину, чем пытаться выяснить причину зависания.
Может вы они не считали это выходом, так как они (SSDs) уже использовались в течение некольких лет? Интересуюсь как тот самый ГГ, которого вы вскользь упомянули в середине статьи. Кстати тема ГГ не раскрыта до конца и основана на Ваших домыслах, ну или слухах...
Приложения обычно не бывают абстрактными, для любой СУБД. Если СУБД менять, приложения придется переписывать.
А Delphi сама по себе не завязана ни на какие СУБД. Для нее они все одинаковы, разница только в используемых компонентах доступа, и умении разработчика приложений работать с СУБД.
Насчет Firebird — «обидные ваши слова» :-). Firebird тут являлся «зоной риска», видимо, только потому, что при разработке и сопровождении не было специалистов, действительно знающих эту СУБД. Я не припомню, чтобы компании в этой сфере обращались за оптимизацией к нам, например.
Хотя, может, в лучшем случае на известный профильный форум ходили.
Firebird, к сожалению, позволяет админу не знать даже как померять дисковый ввод-вывод. Не говоря про разработчика, который может не знать специфику версионности, оптимизатора, и прочего, что надо знать для любой СУБД.
Например — для Оракла было бы неплохо какие-то сертификаты иметь, а «Firebird фигня, и так сойдет».
Отсюда — на начальном этапе проект рвет и мечет, а при появлении серьезной нагрузки «почему-то» все идет наперекосяк. Это же для любой СУБД справедливо.
А насчет «реально что-то с производительностью» — у какой версии ФБ и архитектуры? Мы работаем с пользователями самых разнообразных систем на ФБ — и сотни пользователей, и сотни гиг, и т.д. Но никаких таких «что-то» не наблюдаем.
Разумеется, бывает всякое, например, какой-то редкий баг, который приводит к проблемам в 1-2 случаях на тысячу или десятки тысяч. Но делать из этого вывод, что «начинает тормозить», некорректно.
Я вам могу привести две явных причины торможения — не отключенный авто-свип и накопление мусорных версий. Но это не является дефектом Firebird. Это следствие непонимания архитектуры сервера при разработке приложений, и неумение администрировать сервер.
Подобные вещи можно встретить в любой СУБД.
Энтерпрайз пришёл в компанию и объявил разработчику что успешно работающее в течении 15 лет это то что нужно уничтожить (по сути аргументом было "сейчас модно в облака", а у вас тут болото), а потом называет ГГ, хотя по сути тот сделал самый правильный вывод из ситуации (собрался и ушёл, захватив с собой тех кто не согласен с подходом нового владельца).
p.s. думаю проблема не технологиях, статья думаю не сильно бы поменялась будь там что-то другое.
А почему?
Оказалось, что эта контора решила купить несколько других контор, у которых софт того же типа написан на другой СУБД. Начальство решило «унифицировать» имеющуюся систему с приобретаемыми путем переделки имеющейся. Соответственно, у разрабов пропал смысл что-то делать с текущей системой.
Можно конечно брать рекорды, разгоняя процессор и оперативную память, менять хранилище (SAS->SSD->NVMe), и так далее, но это не сильно поможет. 1 поток останется 1, 2 гигабайта памяти 3200MHz останутся 2 гигами памяти.
В компании, где я работал, решили перейти с Delphi7+FB1.5 на VS2013+FB3. Тоже вылилось в большое количество головняка и денег. Причем железо так и не поменяли, даже не пробовали.
32бит 64бит — не принципиально, особенно для классика. И разница в производительности 32-64 бит не больше 7%.
Суперсервер у ФБ стал многопоточным только в 3.0. И вот только его уже рекомендуют использовать вместо классика.
В 2.5 же гибрид ещё, superclassic он отлично справлялся с работой и насколько помню тянул неплохо.
Собственно, у нас документ «Руководство по аппаратному обеспечению для СУБД Firebird» опубликован еще в 2015 году.
http://www.ibase.ru/files/firebird/Firebird_Hardware_Guide_2015_rus.pdf
с описанием всех архитектур, как их тюнить, и т.д.
Я тоже ходил к ним в гости, и на унаследованный код одним я глазом успел глянуть — прямая дорога в мусорку такому легаси. Итог закономерен, если автор не приукрашивает.
И захотел он бизнесом крутить-вертеть по своему хотению, по инвесторов велению.
Естественно обосрался, за что был пидорнут на мороз. Кто виноват? Все, кроме него. Включая «генерала», и «ГГ», которые всё это создавали с нуля
По поводу отсутствия документации и “черного ящика” автор тоже лукавит (пытаясь объяснить этим свои неудачи) либо действительно был не в курсе, что она есть: во- первых — это исходный код программ, комментарии к таблицам и хранимым процедурам БД, во-вторых — система управления проектами в Redmine.
Конечно для непосвященного в тонкости работы Такси человека вся эта бизнес-логика может показаться сложной и запутанной, как и архитектура (стандартная трех и местами двухзвенная), но это уже другая история…
Кстати, по словам ИТ-директора “Энтерпрайза” именно простая архитектура ПО стала одной из причин, по которой их выбор пал именно на эту компанию. И конечно, автору, следовало бы сравнить сложность настройки на примерах других систем (например “Такси… стер”, где количество настроек в системе приближается к тысячам).
Post mortem