Распараллеливание на несколько процессоров
Многие разработчики представляют себе понятие распараллеливания по разному поэтому надо внести ясность, что имеется в виду под этим термином в случае InterBase 7. Прежде всего уточним, что речь идет о выполнении SQL-запросов, посылаемых пользователем. И тут обычно начинаются разночтения.
Одни считают, что распараллеливание - это когда разные части одного и того же SQL-запроса обрабатываются на различных процессорах. Другие считают, что распараллеливание - это когда разные соединения с пользователями "рассаживаются" по разным процессорам и все запросы от пользователя внутри них независимо выполняются на том процессоре, на котором выполняется обработка данного соединения (такой подход реализован в архитектуре Classic Server).
Однако в архитектуре SuperServer, реализованной в InterBase 7, в чистом виде не используется ни тот ни другой тип распараллеливания.
Чтобы понять, как InterBase 7 использует несколько процессоров, давайте немного углубимся в его архитектуру и рассмотрим процесс обслуживания запросов пользователя.
Когда пользователь посылает запрос на соединение, то этот запрос обрабатывается глобальным менеджером соединений и в случае правильности имени пользователя и пароля регистрируется в списке обслуживаемых клиентов.
Отдельного потока (thread) для индивидуального обслуживания только что подсоединенного клиента не запускается. Это легко можно проверить, написав простенькое приложение, которое откроет несколько сотен соединений с сервером, - и если эти соединения простаивают, то информация о процессе ibserver.exe в Task Manager показывает, что открыто всего 5-8 потоков.
Далее как только подсоединенный пользователь пожелает выполнить какой- либо SQL-запрос, сервер запускает поток, который обслужит данный запрос. После обслуживания данного запроса поток через некоторое время завершает свою работу. Если этот же пользователь снова выполнит другой SQL-запрос, то совершенно не обязательно, что его будет обслуживать ют же самый поток, что и в первый раз.
На самом деле, потоки не запускаются/уничтожаются исключительно по желанию пользователя — InterBase отслеживает среднюю загрузку/частоту выполнения SQL-запросов и держит постоянно открытым пул потоков, содержащий оптимальное число потоков, готовых обработать запросы пользователей.
Такая схема работы не только чрезвычайно экономична - позволяет держать оптимальное количество потоков, но и позволяет (точнее сказать - создает предпосылки для выполнения) выполнять в одном соединении несколько параллельных запросов (например, MSSQL этого не позволяют, требуя открытия отдельного соединения для параллельного выполнения SQL-запросов с одного клиента)
Теперь читатели наверняка догадались, как работает распараллеливание в InterBase, - каждый запускающийся поток будет привязан к наименее загруженному процессору, который и обработает (целиком!) SQL-запрос пользователя Таким образом, разные запросы от одного пользователя могут быть выполнены (в том числе и параллельно) на разных процессорах.
Итак, 7-я версия InterBase - это масштабируемый сервер архитектуры SuperServer. Если вы внимательно читали главу "Classic и SuperServer", то знаете, что главным недостатком архитектуры SuperServer была невозможность эффективно использовать несколько процессоров. В 7-й версии InterBase эта проблема была разрешена, и теперь у InterBase есть возможность работать на многопроцессорных серверах.
Не имея исходных кодов семерки, можно лишь с относительно высокой долей вероятности предположить, что разработчики этой версии пошли по пути оптимизации существующего кода, т е InterBase 7 не переписывался "с нуля". Учитывая огромный объем исходного кода сервера, очевидно, что изменить InteiBase 6.x для поддержки распараллеливания, а затем отследить и протестировать эти изменения - это грандиозная работа, за которую пока не взялся никто, кроме разработчиков из Borland.
Как бы то ни было, InterBase 7 может использовать мощь нескольких процессоров одновременно, а также более эффективно обрабатывает одновременно выполняющиеся SQL-запросы даже на однопроцессорных машинах. Это значительно расширяет сферу его применения и увеличивает ту долю рынка, которую InterBase может забрать у других, гораздо более "монстровидных" СУБД.
InterBase 7 предоставляет средства распределения загрузки по нескольким процессорам. Например, вы можете выделить InterBase только 2 из 4 процессоров, а оставшиеся загрузить другими, не менее важными делами. Для управления привязкой InterBase к процессорам используется специальный параметр CPU_AFFINITY в файле конфигурации сервера ibconfig. В документации к InterBase 7 приведена таблица, показывающая, какое значение должен иметь данный параметр для привязки к желаемым процессорам, и мы здесь ее повторять не будем.
Также в ibconfig появился параметр MAX_THREADS, который устанавливает число одновременно открытых в пуле потоков, готовых к обслуживанию запросов. Изменение этого параметра позволяет управлять загрузкой процессоров - чем меньше потоков, тем меньше процессорного времени будет потреблять InterBase. Для однопользовательских приложений рекомендуется установить этот параметр в 1. Максимальное значение этого параметра - 100.
Важно отметить, что MAX_THREADS не ограничивает число возможных соединений (т. е. обслуживаемых клиентов) с сервером, а лишь устанавливает максимальное значение активных потоков. Таким образом, можно "подсказать" серверу, чтобы он не слишком "экономил" и не закрывал потоки при отсутствии загрузки, т е другими словами, был готов к резкому увеличению количества клиентов.
