Някои факти за firebird под linux

[stoar08]

Понеже стана дума в Пловдив за някои 'странни' ефекти на firebird под windows, реших да отделя няколко минути и да споделя някои подробности.

1. TempDirectories (или environment variable FIREBIRD_TMP)
Когато дадена заявка не се събира в TempCacheLimit байта RAM, firebird започва да 'swap' данните на твърдия диск. Ако TempCacheLimit клони към невъзможно голяма стойност, чисто и просто ще е ангажимент на операционната система да сложи нещата в swap. На практика не съм сигурен дали между 2та варианта има разлика, но лично аз предпочитам да не лъжа приложението и да го оставя самичко да си буферира нещата.
Странната част е, че почти никъде не се вижда използваното за целта място. Вижте снимката, на която са заети 3.8GB, но няма нито 1 файл на въпросното място ...

2. environment variable FIREBIRD_LOCK (не съм видял настройка в .conf и го отчитам като косур)
При classic и superclassic се поддържат няколко сервизни файла (при 2.1 са глобални, при 2.5 са отделни за всяка база) - event/lock/monitor. В тях се съхраняват съответно данни за събитията, заключените обекти и 'мониторинг таблиците'. Firebird ги ползва като memory mapped files, което означава, че ги третира като RAM. В общия случай тяхното место не дава отражение върху реалната работа, но при тежки товари (1000 тракера може би се класира, не съм сигурен) по тези файлове се пише много и ядрото ги 'чисти' към твърдия диск. В определени случай срещнах из форуми 2-3 пъти подобрение на производителността, ако въпросната променлива сочи към RAM устройство.
За 2.1 тези файлове са стандартно в инсталационната директория, за 2.5 са в /tmp. Разчита се, че tmp е или RAM или монтирано във възможно най-лекия режим, но по неясни за мен причини, не всяка дистрибуция уважава този принцип.
Важно! Ако все пак някой реши да го мести, това не е windows! Погрижете се променливата да е зададена на всички нужни места (init scripts/cron scripts/user profiles/т.н.). Иначе се чупи база (аз си бях забравил cron-а и на първия архив ми извиха по всички станции. За щастие минах само с рестартиране на Aton и повторен запис ...)

3. Classic vs SuperClassic
Unix ядрото не прави почти никакво разграничение между нишка и процес. SuperClassic стои по-красиво, но като си настроите правилно htop ще видите, че всъщност има същия брой процеси. Следствие от това е, че харчи точно толкова RAM и при ниски товари (5-10 станции Aton) няма практическо значение.
Основна разлика е, че нишките могат да споделят по-леки синхронизиращи конструкции (процесите се обръщат към ядрото, което е 'бавно') и при 100-1000-10000 връзки въпросните закъснения се усещат.

4. 2.1 vs 2.5
В 2.5 отпада един глобален mutex, което съществено подобрява силно натоварената работа (отново, говорим за товари каквито имаме, но са рядкост).
Друг ценен момент е, че 2.5 значително по-бързо усеща мъртви връзки (предполагам, че се дължи на многонишковия режим, но не съм сигурен). Поддържа и отказ на заявки, което в 2.1 на практика го няма.
Може би с най-голямо практическо значение в 2.5 е възможността за статичен RemoteAuxPort при classic/superclassic вариантите, което позволява по-лесна/грамотна настройка на firewall, ако няма VPN.