Риски использования распределенных систем управления версиями

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

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

Встретилось вот еще пара интересных статей на эту тему:

Риски распределенного контроля версий
Контроль версий и «правило 80 процентов»

Вкратце: с централизованной системой, людей принуждают взаимодействовать и просматривать работу друг друга; с децентрализованной системой, поведение по умолчанию состоит в скрытом ветвлении проекта каждым разработчиком.

Необходимо будет прилагать специальные усилия для обмена кода и самоорганизации в некоторую командную структуру.

Да, я знаю, что DVCS может имитировать работу централизованной системы; но поведение по-умолчанию имеет значение.

А поведение по-умолчанию — «ветвить», а не сотрудничать!

Это поощряет людей забираться в пещеры и кодить там объемные доработки, а затем «сбрасывать» эти «кодовые бомбы» на своих товарищей, причем до момента «сброса» код не может быть кем-либо проверен.

Да, правильные практики возможны с DVCS, но они не поощряются, что заставляет меня беспокоиться о будущем разработки с открытым исходным кодом...

Про новую архитектуру Firebird - SuperClassic

Несколько раз с коллегами начинали разговоры о ней, и каждый раз удивлялись зачем она нужна. В качестве памятки кусочек обсуждения в fb-devel:

SuperServer:

• один процесс ОС на все соединения/базы
• общий кеш страниц для всех баз
• централизованный(central) менеджер блокировок
• блокировки работают на базы, а не соединения - т.е. все операции с базой выстраиваются в одну очередь.
• для версии <>
• не поддерживает многопроцессорность, т.к. ОС не может распаралелить один процесс по нескольким процессорам

Classic:

• отдельный процесс на каждое соединение с БД
• отдельный кеш страниц на каждое соединение
• внешний менеджер блокировок(в 2.5. он уже внутренний)
• хорошая поддержка многопроцессорности
  
• накладывает некоторые ограничения в следствие ресурсоемкости процессов, в сравнении с потоками

SuperClassic:

• один процесс на все соединения (в перспективе - отдельный процесс на каждую базу)
• используется пул потоков ОС для обработки запросов от соединений - т.о. каждое соединение работает в отдельном потоке управляемом ОС, а неактивные соединения не отъедают ресурсы потоков
• централизованный менеджер блокировок, который может обрабатывать как внутренние, так и внешние обращения(одна и таже база может быть доступна как посредством СУБД из процесса А, так и через FB Embeded из процессов B, C и т.д.)
• теоретически этот менеджер блокировок позволяет организовывать кластеризацию используя готовые распределенные движки блокировок
• кеш страниц на соединение
• хорошая поддержка многпроцессорности, т.к. потоки ОС легко распараллеливаются

В v3.0 планируются такие доработки:

• общий кеш страниц на уровне базы
• кеш подготовленных запросов
• общий кеш метаданных

Как итог - SuperClassic это промежуточный шаг(насколько я понял изначально родившийся в RedSoft) к следующей основной архитектуре FB, появившийся в следствии крупного рефакторинга внутренностей движка.

Пока для пользователей практический выигрыш лишь в экономии на процессах и, как следствие, чуть более быстрой синхронизации. Хотя если верить документации, то совокупный выигрыш - до 15-20% на TPC-С тестах в сравнении с классиком.

Подробнее можно посмотреть в Firebird 2.5 Release Notes

UPD: Презентация от Дмитрия Еманова - Firebird 2.5 Architecture

Динамически загружаемые bpl , их выгрузка и интерфейсы

Очевидная, но съевшая кучу времени ошибка.

Если в проекте используются динамически загружаемые/выгружаемые bpl, следует помнить, что при выгрузке информации о классах, реализованных в этих bpl в памяти не остается.

Предположим есть некий список, в котором регистрируются _интерфейсы_, имплиментирующие классы которых реализованы в динамически загружаемых bpl(к примеру в плагинах). Сам список живет в базовом приложении, которое и загружает эти пакеты.

Если оставить разрушение этих объектов на совести основного кода, что при использовании интерфейсов довольно очевидно, но делать это _после_ выгрузки bpl с кодом класса реализующего интерфейс, например в секции finalization, - будем получать маловразумительные AV.

Интерфейсы должны быть интерфейсами!

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

Есть объект, унаследованный от TComponent и поддерживающий какой-то интерфейс. Временем жизни этого объекта управляет некая фабрика, честно убивающая его при закрытии приложения вручную, как обычный объект - т.е. посредством вызова Free.

А в совершенно другой части приложения есть ссылка на этот объект, но в виде глобальной переменной модуля. Некрасиво, но пока приложение живет проблем нет.

А при завершении работы - фабрика все честно чистит и умирает сама, выполняется весь пользовательский код. И начинают финализироваться модули, обнуляя интерфейсы и соотв. дергая TComponent._Release у давно умершего объекта...

Обнаружить сию неприятность удалось только благодаря FastMM, который заполняет память под разрушенными объектами по специфическому шаблону:

Q: My program used to work fine, but if I enable "FullDebugMode" and run it I get an access violation at address $8080xxxx. Why?
A: You are attempting to access properties of a freed object. When you free a block in "FullDebugMode", FastMM fills the freed memory area with a pattern of $80 bytes. If there were any pointers, long strings or object references inside the freed object they will now point to $80808080 which is in a reserved address space.

Все плохое в FB от Windows :)

Проглядывая презентацию Алексея Пешкова о прошлом, настоящем и будущем безопасности в Firebird наткнулся на интересную информацию:

Тот громкий "зашитый" пароль politically/correct был введен для коннекта сервером к своей базе паролей, которая в свою очередь была введена для порта сервера на .... Win3.X в 92-93г., у которой в то время не было свой подсистемы пользователей.

Как любит говорить один мой друг, коммерческий дух win-платформы пересилил здравый смысл :)

Firebird и база на SSD диске

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

"Если на обычном 5-то рейде в таких ситуация(более 1000 коннектов) ответ ждали до минуты, то в ssd это время оставалось константным, порядка 4сек."

Естественно не для всяких систем это будет верно, но все же...

Hi Pays,

I can't give you exact figures, but we switched

from
HP 585 4 processor AMD Opteron 850/16GB with raid5 HP SCSI Ultra320 15krpm 8
disk array for the DB

to
HP 385 2 x quad core AMD Opteron 2384 and an FusionIO IODrive, an 80GB SSD
formatted as 40GB so it can continously prepare the remaining 40GB for write
operations which gives it a performance advantage.

The performance gain was noticable. We are btw running FB2.1 classic, AMD 2
x quad core/20GB ram. A "big" query taking around 8 seconds on the SCSI took
only 4 seconds on the FusionIO. Thus the pure performance gain was just
around 2 times faster. It was a query primarily putting load on the disks,
not the CPU, so I guess the new and better server hardware didn't influence
the result too much.

But the really interesting part comes under higher load! As there is no
latency in positioning the heads on a SSD, it really doesn't seem to care
about number of connections (at least not in our case). So where the SCSI
raid dramatically dropped performance and went to around one minute for the
above query during heavy load (>1000 connections), the SSD still answered in
4 seconds. That makes all the difference to us - and not least our users :)

I hope you can use the above informations in your research. Only
disadvantage for the IODrive, at least for now, is that it isn't mounted
until the server loads the drivers for it. So you can't really boot from it.

Kind regards

Poul Dige
Tabulex

Vista и перенаправление(виртуализация) файловой системы

Когда-то, читая замечательный блог Not a kernel guy, встретил у него описание, как 64-х битные версии новых Windows умеют перенаправлять обращения к реестру и файловой системе.

Почитал, удивился и забыл - в тех системах, которые приходилось писать самому или делалось все так, как хочет Майкрософт(пишем только в профиль пользователя), или намеренно указывалась необходимость иметь права на запись в каталог инсталяции для упрощения системы обновлений.

Но впоследнем проекте получилось сполна опробовать красоту решения от MS - пока у пользователя включен UAC, все обращения на запись в ProgramFiles перенаправляются в профиль пользователя(в нашем случае копировалась 400Мб база, лежащая "под" приложением). Казалось бы, сами себе злобные буратины, что не выполняем рекомендации MS. Но раз уж не выполняем, то МС само заботится о нас и на первый взгляд все ок.

До тех пор, пока пользователь, как это принято, не отключает этот UAC к чертовой матери, и оказывается перед девственно чистой БД :)

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

Про UAC - http://msdn.microsoft.com/en-us/library/bb756960.aspx
Про манифест - http://msdn.microsoft.com/en-us/library/bb756929.aspx