Выбор Unix для сервера на платформе Intel

На рынке операционных систем для серверов баз данных на платформе Intel происходят существенные изменения - на смену SCO OpenServer приходит UnixWare, большие ожидания компьютерной общественности связаны со свободно распространяемой операционной системой Linux. Насколько оправданны эти ожидания и каковы возможности миграции существующих приложений на новые платформы? Приведенные в данной статье результаты тестирования, полученные путем решения практических задач с использованием различных клонов UNIX, дают хотя и не исчерпывающие, но вполне конкретные ответы на эти вопросы.

До недавнего времени лидером рынка коммерческих систем - Unix на платформе Intel была SCO OpenServer, однако, выпустив версию 5.0.5 этой системы, компания Santa Cruz объявила о смене приоритетов в пользу более современной системы UnixWare. Это не означает, что OpenServer прекращает свое существование - в планах SCO выпуск версии 5.0.6. Однако некоторые технологии, например, поддержка кластеров, в OpenServer уже не появятся. Другой сигнал, свидетельствующий о подвижках на рынке Unix для Intel, поступил от Oracle, которая объявила о том, что версия 8 СУБД этой фирмы не будет портироваться на платформу OpenServer. Все это означает, что перед армией разработчиков и конечных пользователей SCO рано или поздно встанет вопрос о смене платформы.

Однако UnixWare - не единственная альтернатива. Не только Oracle, но и большинство основных производителей коммерческих СУБД объявили о поддержке Linux.

Большой популярностью среди разработчиков пользуется также операционная система Solaris. Правда, в первую очередь это относится к платформе SPARC, но данная ОС доступна и для процессоров Intel. Кроме этого, та же Oracle выбрала недавно Solaris для проекта Raw Iron - облегченной версии операционной системы для СУБД Oracle на платформе Intel.

Кандидаты

Какой же путь миграции выбрать, например, пользователям SCO OpenServer? Чтобы ответить на этот вопрос, мы, сотрудники компании «Бизнес-Консоль», провели тестирование четырех операционных систем: SCO OpenServer версии 5.0.5; SCO UnixWare версии 7.0.1; Red Hat Linux версии 5.2, версия ядра 2.2.5; Sun Solaris Intel Edition версии 7.0.

В число претендентов не попали различные клоны BSD, которые хотя и пользуются определенной популярностью среди провайдеров Internet, не поддерживаются основными поставщиками коммерческих СУБД.

Система «Фигаро»

Информационная система «Фигаро» изначально проектировалась с прицелом на решение задач полноценного управленческого учета и планирования на производственном предприятии. Сегодня система внедрена на ряде крупных промышленных предприятий. Имеющиеся инсталляции «Фигаро» работают на предприятиях со штатом от 500 до 6000 человек, обслуживают от 20 до 200 рабочих мест и оперируют базами данных размером до 4 Гбайт.

В основе архитектуры «Фигаро» лежит несколько простых принципов, общих для многих систем такого класса: единая база данных с разграничением доступа и регистрация первичной информации в документах. В большинстве других информационных систем взаимодействие модулей строится на импорте-экспорте данных между ними, причем пользователь вполне может ввести данные по своему участку учета уже после того, как они экспортированы. Так появляются расхождения, с которыми справляются или не справляются пользователи. В «Фигаро» после выверки данных на этапе внедрения проблемы нестыковки данных не возникает: система обеспечивает автоматическую синхронизацию данных, а противоречивые данные просто не вносит.

Взаимодействие модулей строится не по принципу «каждый с каждым», а через универсальные шины данных. Это позволяет унифицировать систему и упростить работу с ней.

Еще одна особенность «Фигаро»: модулем в ней является не бизнес-процесс (например, взаимозачеты), а хозяйственные объекты со специфическим поведением: ядро, кадры, основные средства и т.п. Бизнес-процессы моделируются в неограниченном количестве с помощью настроек в рамках одного или нескольких модулей. Такая архитектура делает ненужным специализированный модуль, например, взаимозачетов.

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

В ходе расчетов запускается около сотни отдельных программ. Некоторые из них вызываются неоднократно, причем самая трудоемкая операция - цикл расчета стоимостей, где все документы рассматриваются последовательно и выясняется, можно ли рассчитать стоимость товаров, услуг, затрат. В момент закрытия учетного периода на сервер ложится колоссальная нагрузка - этот режим оказывается более требовательным к характеристикам сервера и его ОС, чем, например, режим OLTP. Поэтому для оценки производительности различных версий Unix использовался тест, основанный на проведении полного расчета на реальной базе данных (тест номер два),

Для тестирования использовался сервер на платформе Intel SC450NX в следующей конфигурации: два процессора Pentium II Xeon/400Мгц с кэшем второго уровня емкостью 1 Мбайт; оперативная память 256 Мбайт buffered EDO ECC; интегрированный на материнской плате сдвоенный контроллер Ultra2-Wide SCSI Symbios 53c896; RAID-контроллер Mylex AcceleRAID 250 с кэшем 8Мбайт; 6 дисков Seagate Cheetah по 9 Гбайт с интерфейсом Ultra2-Wide SCSI; сетевая карта 3Com 3C905B 10/100 Мбит/с. Наличие двух контроллеров (Symbios и Mylex) обеспечивало возможность маневра для подключения дисков к одному или к другому - это весьма пригодилось нам впоследствии.

Первые впечатления

При оценке процедуры установки мы мало обращали внимание на то, насколько быстро можно установить ту или иную операционную систему - в конце концов, это дело вкуса и привычки.

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

В нашем случае наибольшие проблемы возникли с драйвером для SCSI-адаптера Symbios, что неудивительно, поскольку это относительно новая модель (как и вообще технология Ultra2-Wide SCSI). С контроллером Mylex справились все протестированные нами операционные системы.

SCO OpenServer. Как и следовало ожидать, поддержка аппаратных компонент для SCO OpenServer оказалась наилучшей - морально устаревшая операционная система является и самой зрелой.

Вообще благодаря распространенности этой ОС маловероятно, что у вас возникнут проблемы. Если же это все-таки произошло, то по адресу http://www.sco.com/ta имеется архив «технических статей», оснащенный поисковым механизмом. В 99 случаях из 100 вы найдете здесь решение своей проблемы, причем, в отличие от служб поддержки других производителей, контракт на сопровождение для доступа к ресурсам службы сопровождения компании SCO не требуется.

Итоговая оценка - 5 (по пятибалльной шкале)

SCO UnixWare. Драйвер для Symbios 53c896 в дистрибутиве присутствует, но для интегрированного контроллера он не подошел. Окончательно это выяснилось при обращении к службе сопровождения SCO: заполнив на Web-узле специальную форму, мы в течение часа получили подтверждение о принятии нашего запроса. А на следующий день пришло письмо, в котором сообщалось, что указанная нами проблема известна и устранена в новой версии драйвера. Контракт на сопровождение не потребовался и в этом случае.

Впечатления от процедуры установки в целом благоприятные, но некоторые моменты вызвали недоумение.

• Способ установки по умолчанию - выбор компонентов в зависимости от введенной лицензии. Казалось бы - ввел лицензию и можешь не о чем не беспокоиться. Однако, как выяснилось, программный компонент, обеспечивающий поддержку симметричной многопроцессорной обработки SMP, по умолчанию не устанавливается, даже если вы лицензируете конфигурацию Departamental или Enterprise, в которых предусмотрены лицензии, соответственно, на 2 или на 4 процессора.
• Разработчики уверяют, что утилиты администратора (scoadmin) перенесены из OpenServer в UnixWare. И это действительно так, за некоторыми исключениями - подключение новых дисков может быть выполнено только утилитой diskadd.
• Локализация системы (поддержка русского языка) проведена под стандарт ISO. При всем уважении к международным стандартам, де-факто стандартом для Unix-платформ в России является КОИ-8.

Итоговая оценка - 4

Linux. Данную ОС можно установить практически на любое «железо», но занятие это не для слабонервных.

Действительно, количество пользователей Linux во всем мире, видимо, еще больше, чем у SCO, однако надо учитывать, что в основном они устанавливают эту операционную систему вовсе не на серверы. Задав в телеконференции вопрос, как установить Linux на PC-386 с двумя мегабайтами оперативной памяти, вы получите намного больше откликов, чем если спросите, как установить ее на сервер с двумя гигабайтами.

В итоге нам удалось установить Linux с поддержкой SMP и обоих дисковых контроллеров, но для этого пришлось установить самую свежую на тот момент версию ядра (2.2.5). Следом потянулись замены различных программных пакетов: системных библиотек, компилятора gcc, утилит mount, ps, hostname и других, обеспечивающих корректную работу всего системного окружения с данной версией ядра.

В то же время все большее число производителей аппаратных компонентов объявляют о поддержке Linux, так что можно надеяться, что процесс установки со временем перестанет быть искусством. Например, компания Mylex приняла такое решение как раз тогда, когда мы проводили наши эксперименты. А вскоре после их завершения на свет появился новый дистрибутив RedHat 6.0. Стандартное ядро, использующееся в нем, как раз версии 2.2.5. Приобретая этот дистрибутив, вы получаете Linux с поддержкой SMP, ранее отсутствовавшими драйверами и другими усовершенствованиями, которые обеспечивают лучшую поддержку высококлассных платформ.

Итоговая оценка - 4,5.

Sun Solaris. Для версии 7.0 отсутствует драйвер контроллера Symbios 53c896. С другими аппаратными компонентами, в том числе с контроллером Mylex, проблем не возникло.

Сама программа установки производит неплохое впечатление, особенно ее графический вариант. Тем не менее, ей присущи определенные недостатки. Например, если вы используете систему NIS, то возможность указать адрес соответствующего сервера имеется, а если у вас есть только служба DNS, то адрес нужного сервера указать нельзя.

Рис.1. Оценка процедуры установки по пятибалльной шкале

«Честная» установка привела к зависанию графического login и, как следствие, к невозможности дальнейшей работы. Как выяснилось, этот дефект пользователям Solaris известен. Подобной ситуации можно избежать, если при помощи специальных ухищрений добиться того, чтобы графический login не запускался.

Итоговая оценка - 3,5 балла

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

Двоичная совместимость

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

Тестирование на двоичную совместимость мы проводили на реальной база данных, а результаты, полученные для OpenServer, принимались за эталон.

В ОС Linux двоичная совместимость с OpenServer обеспечивается модулем iBCS, поэтому никаких проблем с эксплуатацией исполняемых модулей у нас не возникло. Некоторая шероховатость наблюдается между диалектами shell - в Linux основной командный интерпретатор - это bash, но данное препятствие легко преодолимо, а проблема скорее является следствием нестандартности диалекта shell, реализованного в OpenServer.

Как утверждают представители SCO, разработчики компании приложили значительные усилия для обеспечения двоичной совместимости OpenServer и UnixWare, однако стопроцентной гарантии нет. (Надо полагать, что идея обеспечения полной двоичной совместимости ценой сохранения морально устаревших и нестандартных интерфейсов себя не оправдала.) Тем не менее, проверка совместимости нашего приложения не выявила каких-либо проблем. Что касается версий shell, то в каталоге /OpenServer/bin находится версия sh, идентичная по поведению командному процессору OpenServer.

Заставить работать исполняемые модули OpenServer в ОС Solaris нам не удалось, поэтому, не без некоторого сожаления пришлось отказаться от проведения части тестов с этой операционной системой.

Методика тестирования на быстродействие

При использовании результатов стандартных тестов всегда присутствует элемент неопределенности - неясно, как соотносятся условия модельного тестирования с условиями реальной эксплуатации конкретной прикладной системы, особенно для SQL-СУБД: количество одновременных клиентских сессий, соотношение вычислительных операций и операций ввода/вывода. Чтобы избежать неопределенности, мы проводили тестирование, проводя хронометраж расчетов на эталонной базе, в качестве которой была взята реальная база данных одного из крупных пользователей системы «Фигаро».

Достоинство такого способа - полная ясность в том, что может дать смена платформы нашим пользователям. С оговорками результаты можно распространить и на другие приложения, базирующиеся на Unify DataServer ELS - в частности, на «АС Филиал» Сбербанка России, что было в то время весьма актуально для нас. Недостаток же его в том, что для широкого круга пользователей OpenServer полученные нами результаты могут быть полезны только как ориентир; результаты на других приложениях могут отличаться.

Система «Фигаро» имеет архитектуру «хост-терминал». Все таблицы хранятся в одном файле, размер которого для эталонной базы данных составлял

1 Гбайт. По нашим наблюдениям, критичным для «Фигаро» был не режим OLTP (интерактивный ввод первичных данных), а пакетные процедуры: проведение расчетов, массовая загрузка, перестроение индексов, резервное копирование. Именно поэтому мы не стали моделировать многопользовательскую нагрузку, а ограничились простым набором следующих тестов.

• Последовательное чтение файла базы данных. Тест моделирует операцию резервного копирования.
• Проведение полного расчета по итогам месяца. Этот тест сочетает интенсивный ввод-вывод и вычисления как с целыми так и вещественными числами.
• Перестроение ссылок в базе данных. Эта операция выполняется утилитой СУБД и основная нагрузка при ее выполнении ложится на дисковую подсистему.

Как уже отмечалось, Solaris не поддерживает двоичную совместимость с OpenServer, поэтому из перечисленных тестов на платформе Solaris был выполнен только первый.

Настройка производительности

Щекотливый момент сравнительного тестирования операционных систем связан с тем, насколько тщательно проводилась их настройка перед тестированием, ведь очевидно, что небрежно выполненная настройка может полностью исказить результаты. С другой стороны, качество работы ОС определяется, в числе прочего, и доступностью средств диагностики для нее. В этом аспекте за эталон можно принять OpenServer: в стандартный комплект поставки входит утилита тюнинга Doctor Lite. Документация, также штатно поставляемая в виде файлов HTML, содержит обширный раздел под названием Performance Guide.

В онлайновой документации по UnixWare также присутствует обширное руководство по настройке производительности, в разделе «System Management - Monitoring and tuning the system - Managing system performance». Очень полезна утилита мониторинга системы rtpm - Real Time Performance Monitor.

Что касается Linux, то здесь надо быть готовым к тому, что документацию придется искать в разрозненных источниках, а для мониторинга системы пользоваться «спартанскими» утилитами sar и vmstat.

Тестирование проводилось в монопольном, а не многопользовательском режиме, что несколько упростило задачу, так как мы могли ограничиться ее настройкой кэша и подбором оптимальной схемы RAID. В OpenServer размер дискового кэша был увеличен до 128 Мбайт (половина объема оперативной памяти), в двух других операционных системах кэш динамический и поэтому не требует специальной настройки.

Оптимизация массива RAID

Для достижения максимальной производительности мы провели большую работу по подбору оптимальных дисковых конфигураций. Нас интересовало, какой выигрыш дает использование массива RAID по сравнению с обычными дисками. Точкой отсчета послужила самая простая конфигурация, в которой файловые системы располагались непосредственно на дисках, подключенных к контроллеру SCSI (в дальнейшем эту конфигурацию будем обозначать HD). Время прохождения тестов на различных вариантах массива RAID сравнивалось с результатом соответствующего теста, проведенного в конфигурации HD.

К сожалению, уже на этом этапе возникли затруднения с UnixWare и Solaris из-за проблем с драйвером Symbios. Поэтому везде, где речь идет о конфигурации HD для этих систем, диски на самом деле подключались через RAID-контроллер Mylex по схеме RAID-7 (без их объединения). Фактически, в этом варианте Mylex использовался как кэширующий SCSI-контроллер, что давало UnixWare и Solaris некоторое преимущество в быстродействии.

Рис.2. Соотношение времени выполнения тестов в конфигурации Hardware RAID-0

Первым вариантом организации RAID-массива был аппаратный RAID уровня 0 на трех дисках (Hardware RAID-0). На рис. 2 показаны пропорции времени выполнения тестов в этой конфигурации по отношению к конфигурации HD. Если использование RAID-массива дает лучший результат, то это соотношение меньше единицы. Результат тем лучше, чем меньше соотношение времени прохождения тестов.

К нашему удивлению, только для ОС Linux использование Hardware RAID дало ощутимое преимущество (отношение времени выполнения меньше 1 для всех тестов). Очевидно, это свидетельствует о более высоком качестве драйвера Mylex для Linux.

Вероятно, в многопользовательском режиме распределение нагрузки по трем дискам дало бы определенный эффект, но при монопольном доступе результаты оказались откровенно слабыми. Объясняется это, возможно, невысокой тактовой частотой процессора Intel i960, используемого в контроллере - всего 66 Мгц (по сравнению с 400 Мгц основного процессора). Справедливости ради надо заметить, что модель AcceleRAID - не самая производительная в семействе продуктов Mylex.

Рис.3. Соотношение времен прохождения тестов в конфигурации Software RAID-0

Другой вариант - это Software RAID, также на трех дисках. В этой схеме логику распределения данных по дискам берет на себя операционная система. Результаты, представленные на рис.3, говорят сами за себя: с точки зрения производительности эта конфигурация - наилучшая для всех операционных систем. Относительно небольшой выигрыш на втором тесте - следствие того, что нагрузка на дисковую подсистему в этом тесте меньше, чем в остальных.

Не следует, правда, забывать, что аппаратный массив RAID имеет преимущество с точки зрения надежности. Например, при размещении на RAID-1 или RAID-5 не возникнет проблем с загрузкой системы, если выйдет из строя один из дисков. Некоторые реализации Software RAID-1 тоже позволяют добиться такого результата, но это требует дополнительных усилий, а в некоторых случаях - и дополнительных затрат на приобретение соответствующих лицензий.

Что касается программной реализации массива RAID-0 в системе Solaris, то нас снова поджидал неприятный сюрприз: оказалось, что необходимые для этого средства отсутствуют в стандартном комплекте поставки. Для организации в Solaris массивов RAID программным способом требуется приобретение дополнительного ПО Solstice DiskSuite.

Известно, что на скорость работы массива RAID существенное влияние оказывает размер блока данных, запись или чтение которого распределяется на все диски массива. Этот размер, обычно называемый stripe size, задается при инициализации массива. Согласно теории, для приложений типа баз данных следует задавать его небольшим - скажем, равным 8 Кбайт. Однако в наших тестах максимальная производительность достигалась при максимальном stripe size. Видимо, для современных высокопроизводительных дисков эту теоретическую рекомендацию можно уже считать устаревшей. Подтверждение этому выводу мы нашли и в документации по Software RAID для Linux («how-to»), где также рекомендуется выбирать максимальный размер stripe size для любых типов приложений. При использовании Software RAID в Linux для достижения максимальной производительности следует также особым образом размечать файловую систему.

Результаты тестирования на быстродействие

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

Рис.4. Тест 1 - время чтения файла размером 1 Гбайт (секунды)

При проведении первого теста (рис.1) принимались меры к тому, чтобы данные выбирались непосредственно с диска, а не из кэша операционной системы. Рекордный показатель скорости чтения был достигнут на ОС Linux и составил 46,8 Мбайт/с.

Основной результат выполнения второго теста приведен на рис.5 - UnixWare и Linux выполнили приложение OpenServer почти в два раза быстрее, чем OpenServer. При этом Linux незначительно превзошел UnixWare по быстродействию.

Рис.5. Тест 2 - подведение итогов (часы:минуты)

С учетом того, что используемая СУБД не имеет развитых механизмов кэширования, решающую роль в этом тесте играет эффективность дискового кэша операционной системы. Поскольку при подведении итогов используются, в основном, данные текущего периода, через некоторое время в ходе расчетов активная часть база данных целиком оказывалась в оперативной памяти.

В OpenServer размер кэша задается статически (мы задавали этот параметр равным 128 Мбайт), а в современных версиях ОС Unix, к которым относятся UnixWare и Linux, под дисковый кэш выделяются свободные страницы из общего пула памяти. Стратегия синхронизации кэша теперь тоже ушла далеко вперед от классической схемы синхронизации через каждые 30 секунд.

В ходе расчетов мы наблюдали за картиной использования памяти. ОС UnixWare и Linux всю свободную память использовали под дисковые буфера. На Linux наблюдалась даже активность подкачки (swap) - неактивные задачи выгружались на диск, а освободившаяся память использовалась опять-таки под буфера обмена.

Таким образом, в эффективности дискового кэша OpenServer явно проигрывает современным версиям Unix. Этим, видимо, и объясняются результаты теста номер два.

Третий тест - перестроение ссылок - представляет собой профилактическую процедуру, выполняемую специальной утилитой СУБД. По результатам третьего теста (рис.6) ОС UnixWare вновь продемонстрировала двукратную по сравнению с OpenServer производительность.

Рис.6. Тест 3 - перестроение ссылок (часы:минуты)

В отличие от второго теста, где для обработки выбираются только данные текущего периода, в тесте 3 «перелопачивается» вся база данных, причем в режиме случайного доступа. Видимо, это потребовало более сложного алгоритма кэширования и здесь ОС Linux оказалась не на высоте. В правильности этой догадки нас убедили результаты тестирования при увеличенном объеме памяти (до 1 Гбайт). В этой, более комфортной, ситуации, когда объем оперативной памяти сравнялся с размером БД, показатели Linux стали приемлемыми. Однако при большем размере базы такое простое решение невозможно, поскольку Linux в штатном варианте пока не поддерживает больше 1 Гбайт оперативной памяти. (UnixWare уже в конфигурации Departmental поддерживает до 4 Гбайт.)

Итоговые оценки

OpenServer. Несмотря на то, что программное обеспечение, применявшееся в тестах, было создано именно для этой ОС, она оказалась самой медленной при проведении расчета и в полтора-два раза уступала UnixWare при перестроении ссылок. А результаты теста на чтение вообще были совершенно неожиданными.

UnixWare. Эта ОС показала неплохие результаты при проведении расчетов, немного уступив Linux. В тесте по перестроению ссылок она оказалась лучшей. Система, показавшая высокие результаты во всех тестах, представляется весьма стабильной. Безусловно, имеющая богатый опыт работы с оборудованием Intel компания SCO довела ОС UnixWare до очень хорошего уровня. В ней много технологических новинок, например, файловая система Veritas или Online Data Manager, позволяющий выполнять резервное копирование файловой системы в «горячем» режиме.

Linux. ОС Linux показала рекордные результаты на чтении, а также при проведении расчетов, и очень плохие результаты при перестроении ссылок. Подобная непредсказуемость может отпугнуть пользователей, привыкших к стабильности коммерческих вариантов Unix.

Solaris. Что касается этой операционной системы, то нам сложно сделать какие-либо окончательные выводы, поскольку ряд тестов, которые были выполнены на других платформах, оказалось невозможно запустить на Solaris. Кроме того, у нас отсутствовала лицензия на программу Solstice DiskSuite, средствами которой возможна организация массивов software RAID в системе Solaris.

Тем не менее, мы можем поделиться некоторыми интересными наблюдениями. Так, проводя Тест 1 (скорость последовательного чтения файла база данных), мы обнаружили, что команда cat file.db > /dev/null выполняется за время, близкое к нулю. Видимо, в Solaris эта команда обладает довольно развитым интеллектом. Когда же мы оценивали загруженность процессоров во время простоя системы, нам пришлось удивиться еще раз - она находилась в пределах 27-50% системного времени.

... и комментарии

Если сравнивать ОС Linux с UnixWare, то стоит отметить такие преимущества Linux, как лучшая поддержка различных аппаратных компонентов, за исключением таких, как, например, экзотические модели RAID-контроллеров. Кроме того, для Linux существует гораздо больше свободно распространяемого ПО. В различных дистрибутивах Linux уже присутствует значительное число (от 500 до 2000) подобных пакетов. Кроме того, обращаем внимание пользователей на более развитую поддержку различных сетевых протоколов в этой системе.

Тем не менее, по ряду параметров UnixWare пока еще существенно опережает Linux. Когда мы перешли от тестирования в монопольном режиме к реальной эксплуатации системы «Фигаро», при большом числе одновременно работающих пользователей (на уровне 60-70) Linux стала постоянно «зависать». Вообще, возможности этой операционной системы пока еще не совсем соответствуют возникшему вокруг нее ажиотажу - одним из главных минусов является недостаточная поддержка high-end платформ архитектуры Intel. К сожалению, выход ядра версии 2.2 не решил многих проблем в этой области. Правда, в данной версии появилась поддержка SMP на достаточно стабильном, а не экспериментальном уровне, как это было с ядрами версии 2.0, однако специалисты признают, что реализация SMP еще далека от совершенства. В отличие от UnixWare, где SMP реализована на весьма высоком уровне. Тем не менее, известно, что Linux достаточно хорошо функционирует на 14-ти процессорных системах UltraSPARC.

UnixWare больше приспособлена для работы с такими требовательными приложениями, как базы данных размерами до терабайта. Максимальный же размер файла в Linux ограничен двумя гигабайтами, тогда как в UnixWare поддерживаются файлы размером до 1 Тбайт.

Серьезным недостатком Linux является отсутствие поддержки больших объемов оперативной памяти. Конечно, эта проблема коренится в архитектуре Intel, в которой поддержка оперативной памяти размером более 2 Гбайт представляет определенные сложности. Но с другой стороны, в системе UnixWare, в отличие от Linux, эта проблема решена - UnixWare поддерживает 4 Гбайт в конфигурации Departmental и 16 Гбайт в конфигурации Enterprise. Linux штатно поддерживает только 1 Гбайт. Можно поднять это ограничение в два раза, если внести изменения в исходные коды ядра, но вряд ли в этом случае система будет работать стабильно.

С появлением новой версии ядра Linux - 2.4, можно ожидать существенного улучшения поддержки высокопроизводительных платформ. Прежде всего, в этой версии будет переработана поддержка SMP. Кроме того, ожидается появление еще одного важного новшества, а именно файловой системы XFS от SGI, которая передала компьютерной общественности исходные коды этой файловой системы. Как утверждают представители SGI, XFS является файловой системой нового поколения по отношению к системам Veritas, Tolerant и IBM JFS. XFS является 64-разрядной файловой системой, что позволяет решить проблему работы с большими файлами и увеличить производительность. Кроме того, XFS обладает такими нововведениями, как гарантированная скорость доступа, резервное копирование в «горячем» режиме и быстрое восстановление после сбоев.

Выводы

До недавнего времени вопрос выбора варианта Unix в качестве операционной системы для сервера базы данных на платформе Intel решался довольно просто. Если была необходима высокопроизводительная платформа для приложений, работающих с современной СУБД, то существовал практически единственный вариант - OpenServer. Сегодня ситуация в корне изменилась: приоритетным продуктом SCO становится UnixWare, а ведущие производители СУБД и аппаратных компонентов объявляют о поддержке еще одной версии Unix на платформе Intel - Linux.

Проведенное нами исследование показало перспективность обеих платформ, причем не только при развертывании новых систем. Переход на новые технологии дает новый импульс прикладным системам, которые уже вышли на верхнюю ступень производительности. При этом UnixWare демонстрирует пока еще большую устойчивость и масштабируемость, чем ОС Linux.

Об авторах