Долго делали фичу многоядерности в firebird

Что ж, молодцы ребята, значит: написали код эффективно, что и на одном ядре прекрасно работало. Тут, скорее, жаль, что в мультипроцессинг пошли.

Разработчикам браузеров бы на заметку взять. Firefox нынче умудряется тормозить на каких-то космических конфигурациях.

По ссылке ничего такого не написано, ты что-то выдумал.

Ты неправильно прочитал. Прям в самом начале сказано про super server и classic server, которые были ещё в исходном интербейзе

задействие ядер процессора больше одного

...сильно переоценено. Очень сильно. А в RDBMS вообще имеет смысл только в параллельной расшареной обработке, что уже сродни кластеру.

А, прочитал про ClassicServer - авторы, очевидно, также думают и наоборот в дополнение к большой дуре сделали классную фичу - быстрый сервер в одном процессе.

Не знаю, как сейчас, в былые времена эта СУБД была одноядерной, да. У меня на полке стоит книжка по сабжу. Я её не читал и не собираюсь, и купил для коллекции и для поддержки автора, там речь именно как об одноядерной системе.

Поправь заголовок на нормальный, блин.

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

задействие ядер процессора больше одного появилось в версии 5

Параллельная (многопоточная) работа для резервного копирования/восстановления, развертки и создания индекса

https://firebirdsql.org/file/documentation/release_notes/html/en/5_0/rlsnotes50.html#rnfb50-new

Parallel (multi-threaded) operation for backup/restore, sweep and index creation

Ага, тоже попался, но сначала почитал википедию и release notes

https://www.firebirdsql.org/file/documentation/release_notes/html/en/3_0/rlsnotes30.html

2. New In Firebird 3.0

The primary goals for Firebird 3 were to unify the server architecture and to improve support for SMP and multiple-core hardware platforms. Parallel objectives were to improve threading of engine processes, and the options for sharing page cache across thread and connection boundaries.

Alongside these aims came new strategies to improve performance, query optimization, monitoring and scalability, and to address the demand for more security options. A number of popular features were introduced into the SQL language, including the long-awaited support for the BOOLEAN data type and the associated logical predications.

3.0. Которая тоже в этом году вышла.

А до этого комьюнити на одном ядре плясало?

Не знаю как ныне, а ранее core Firebird разрабатывал по существу один человек.

Нет, не попался, потому что:

задействие ядер процессора больше одного появилось в версии 5

😁

Да как сказать, clickhouse, например, может использовать все доступные ядра для обработки одного запроса

задействие ядер процессора больше одного появилось в версии 5

Это откуда такое?

Из ОП же. ТС так «прочитал» и сделал выводы.

А, я уж release notes все прошерстил на предмет «more than one», а там такого нет :)

Но тем не менее он прав, многопоточность появилась в 3.0, которая наравне с 4.0 и 5.0 появилась в этом году :)

ИИ всё знает

Количество ядер процессора для сервера Firebird зависит от 
профиля нагрузки и архитектуры СУБД. Firebird всегда исполняет 
один запрос на одном ядре, поэтому сложные или плохо 
оптимизированные запросы могут занимать до 100% одного ядра, 
заставляя остальные запросы переместиться на менее загруженные 
ядра. 

В версии Firebird 2.5 для распараллеливания обработки на 
несколько ядер следует использовать архитектуры Classic или 
SuperClassic. Архитектура SuperServer в этой версии может 
использовать только одно ядро на одну БД, поэтому её не следует 
применять в высоконагруженных системах. В версии Firebird 3.0 и 
SuperServer, и Classic, и SuperClassic используют возможности 
многоядерных CPU. 

Рекомендации

Учитывать преобладающие запросы. Если приложение в основном 
исполняет простые короткие SQL-запросы, все запросы хорошо 
отлажены, и не используется генерация запросов на лету (например, 
для отчётов), то CPU не будет являться узким местом 
производительности, и можно выбрать младшую модель с меньшим 
количеством ядер. Если приложение содержит генератор отчётов или 
большое количество медленных запросов, возвращающих большое 
количество данных, то необходим процессор с большим количеством 
ядер.

Учитывать количество активных соединений с БД в среднем и в 
моменты пиковой нагрузки. Для грубой оценки необходимого 
количества ядер можно пользоваться правилом: от 10 до 30 
соединений на 1 ядро:
10 соединений/ядро — приложение с преобладанием сложных и 
медленных запросов;
30 соединений/ядро — приложение с преобладанием простых, хорошо 
отлаженных запросов.

Нет, под Линукс всегда был и superserver и classicserver. И был не понятный выбор, либо каждый запрос на отдельный процесс, можно загрузить все процессоры, но у каждого свой кеш БД и его становится мало. Либо все запросы обрабатываются одним процессором (superserver), зато у всех запросов общий кеш.

А в 2004 выбор стал веселее, либо версия 1.0.3, которая старая, либо прогрессивная 1.5, откровенно сырая, глючная и зависающая...

Ты, как и автор темы, неправильно перевёл. В 3.0 улучшили уже существующую многопоточность, а не внедрили.

Ви бы сюда ишшо Mongo приплели!

И таки шо?

Не, я против хорошего распараллеливания M:N ничего не имею, но это на классе задач сабжа не часто нужно и, когда становится нужно, уже на другой сервер все переезжают.

из perplexity

То есть ты создал тему чтобы обсудить выхлоп очередного бредогенератора? Просто не используй их, и не придётся потом удивляться «что это тут написано».

Значит наоборот, под винду не было классика. Я точно помню, что под одну из платформ был только один вариант.

Точно, нашёл в википедии в примечаниях к версии 1.5 «Восстановлена архитектура Classic для Windows».

Учись читать первоисточники, а то так и останешься таким.

Ты как будто не видишь прошлые 7 ников. :-D

Вижу, они же (почти) все на моей совести.

Нормально вы так археологией занялись. Я аж прослезился, версия 4.2 была норм. А потом скатился…