Испытания 32-разрядных ОС на надежность и предельные нагрузки
Испытания, проводившиеся в условиях повышенных нагрузок, предоставили в наше распоряжение факты, необходимые для сравнения надежности и функциональных возможностей четырех соперничающих операционных систем.
В течение продолжительного времени, предшествовавшего выходу системы Windows 95 в свет, ее архитектура подвергалась тщательному исследованию. Действительно ли она более устойчива, чем Windows 3.1? Насколько она надежна по сравнению с Windows NT Workstaion 3.51 или OS/2 Warp 3.0 фирмы IBM? Успешно ли она справляется с некорректными 16- и 32-разрядными прикладными программами? Мы разработали небольшой набор прикладных программ, чтобы с их помощью подвергнуть Windows 95 и ее основных конкурентов тестам на выживаемость.
Результаты тестов (см. врезки "Бомбовый удар" и "Краткий обзор ограничений") свидетельствуют, что Windows 95 защищена несколько лучше, чем ее 16-разрядные предшественницы. Однако в OS/2 Warp предусмотрена значительно более надежная модель безопасности, нежели в Windows 95, а Windows NT оказалась совершенно неуязвимой к любым попыткам испортить ее. Функциональные возможности Windows 95, характеризуемые наличием доступных системных ресурсов, резко улучшились по сравнению с 16-разрядными версиями Windows.
Тестовый набор состоит из семи прикладных программ. 16-разрядная программа BOMB16 и 32-разрядная программа BOMB32 пытаются вызвать аварийный сбой операционной системы, производя несанкционированную запись в критические области памяти. Прикладная программа THRDTEST, которая выполняется только в среде Windows 95, контролирует влияние потоков на свободные системные ресурсы. W16MTX16 и W16MTX32 исследуют влияние на систему прикладных программ, которые недостаточно быстро уступают управление ЦП. WNDTST16 и WNDTST32 определяют предельно допустимое число окон, одновременно появляющихся на экране в данной системе.
16-разрядные прикладные программы выполняются в среде всех пяти испытуемых операционных систем (OS/2 работает с программами Win16 в рамках изолированного сеанса Win-OS/2). Все 32-разрядные тесты (за исключением THRDTEST, предназначенного специально дл среды Windows 95) выполняются под управлением всех ОС, кроме Windows 3.1 и Windows for Workgroups 3.11.
Исходный текст и исполнимые файлы этих программ могут быть загружены из Web-архива PC Magazine Labs (http://www.zdnet.com/~pcmag/pclabs/pclabs.htm) или из библиотеки PC Labs форума Utilities/Tips сети ZD Net (GO ZNT:TIPS в CompuServe). Если вы хотите детально ознакомиться с принципами работы тестовых прикладных программ, смотрите статью "Операционные системы: тестирование на надежность" в этом номере журнала.
Прикладная программа BOMB16 разделяется на три самостоятельных теста. Первый тест вызывает нарушение защиты общего характера (GPF), пытаясь произвести запись в предназначенные только для чтения сегменты памяти. Каждая операционная система правильно распознавала исключительную ситуацию, выводила на экран диалоговое окно с извещением об ошибке и завершала вызвавшую ошибку прикладную программу. Тест доказывает, что обычные ошибки, встречающиеся в 16-разрядных прикладных программах, вовсе не обязательно приводят к краху менее стабильные операционные системы.
Второй тест BOMB16 переписывает первые 64 Кбайт обычной памяти DOS. Когда этот тест был выполнен, Windows 3.1x незамедлительно "рухнула" прекратила работу, выдав на экран системное приглашение DOS, а Windows 95 зависла, и вывести ее из этого состояни удалось лишь с помощью "холодной" перезагрузки. Обе эти ОС направляют вызовы в ядро DOS, лежащее в их основе, и весьма восприимчивы к проведению подобных операций. Windows NT и OS/2, напротив, легко справились с этой задачей. OS/2 закрыла свой 16-разрядный сеанс Win-OS/2, а Windows NT просто завершила программу-нарушителя.
Последний тест BOMB16 ищет ключевую системную DLL и записывает нули в ее область данных. Результаты этого теста были похожи на полученные в тесте перезаписи нижней памяти DOS; Windows 3.1x и Windows 95 зависли, и их пришлось перезапускать, тогда как Windows NT и OS/2 элегантно завершили 16-разрядный сеанс, в котором выполнялась BOMB16.
Эти тесты продемонстрировали, почему эксперты по операционным системам так превозносят отдельные, защищенные адресные пространства. В Windows 3.1x и Windows 95 некоторые жизненно важные области данных были сделаны доступными для всех прикладных программ, с тем чтобы повысить эффективность выполнени программного кода. Однако недоработанные программы, содержащие ошибки, могут нарушить работу таких систем. В противоположность этому такие операционные системы, как Windows NT и OS/2, делают упор на более развитые средства защиты адресных пространств, лишая прикладные программы-нарушители доступа к важным областям данных. Прикладные программы, содержащие ошибки, в этих системах могут саморазрушаться или вызывать завершение программ, выполняющихся в одном сеансе с ними, но не могут разрушить ядро операционной системы. Создателям операционных систем приходилось идти на компромиссы между производительностью и обратной совместимостью, с одной стороны, и надежностью - с другой. При выборе ОС вам придется решить для себя, каковы ваши приоритеты.
Как и BOMB16, программа BOMB32 разделяется на несколько разных тестов. Первый создает исключительную ситуацию, вызванную ошибкой обработки страниц (page fault), похожую на те, что возникают в неправильно написанных 32-разрядных прикладных программах. Как и во время теста нарушения GPF в программе BOMB16, все 32-разрядные операционные системы - Windows 95, Windows NT и OS/2 - вывели на экран сообщение об ошибке, а затем завершили программу. Это нормальное поведение, соответствующее ожидаемому.
Второй и третий тесты BOMB32 пытаются произвести запись в первый мегабайт памяти. Два теста потребовались потому, что в Windows 95 эта область разделена на две половины. Нижняя часть, котора используется системой DOS и драйверами устройств, загружаемыми с помощью CONFIG.SYS и AUTOEXEC.BAT, начинается с адреса 0. Система не позволяет прикладным программам Win32 осуществлять запись извне в эту область памяти. Когда BOMB32 попыталась осуществить такую запись, Windows 95 распознала ошибочную операцию и завершила программу.
Верхняя часть первого мегабайта, которая содержит ключевые области данных и системный код Windows 95, расположена непосредственно над защищенным нижним пространством. Однако для того, чтобы избежать существенного снижения производительности, эта область не защищена от некорректных 32-разрядных прикладных программ; BOMB32 произвела перезапись в эту область и испортила систему.
Windows NT и OS/2 не хранят критические системные данные в обычной памяти ниже границы 1 Мбайт и защищают эти адреса. Поэтому они не пострадали от попыток несанкционированной записи, предпринятых программой BOMB32; как Windows NT, так и OS/2 завершили тест и продолжили нормальную работу.
Как и в программе BOMB16, заключительный тест BOMB32 ищет область данных в ключевых системных DLL и портит их содержимое. Поскольку в среде Windows 95 эта область данных совместно используется всеми 32-разрядными прикладными программами, BOMB32 быстро поставила эту операционную систему на колени. В среде Windows NT, однако, каждая прикладная программа имеет свою собственную копию заглушек для перенаправлени обращений к области данных. Когда BOMB32 попыталась записать данные в эту область, другие прикладные программы, выполнявшиеся в системе, не пострадали. В OS/2 Warp не защищены страницы данных некоторых важных библиотек DLL; разновидность этого теста для OS/2 смогла испортить PMWIN.DLL, вызвав крах системы.
В конце периода бета-тестирования системы Windows 95 стало ясно, что прикладные программы, создававшие большое число потоков, приводили к истощению системных ресурсов. Корпорация Microsoft заявляет, что она справилась с этой проблемой при подготовке окончательной версии своей системы; наша прикладна программа THRDTEST показывает, что это утверждение небезосновательно.
THRDTEST - написанная специально для Windows 95 программа, которая создает системные потоки и контролирует их влияние на ресурсы модулей USER и GDI. Системные потоки делятся на две основные категории: потоки с очередями сообщений и без очередей сообщений. Потоки с очередями могут обмениваться информацией с другими прикладными программами, а потоки без очередей выполняются автономно. THRDTEST позволяет пользователю создавать потоки обоих типов и одновременно вести учет свободных системных ресурсов.
Применение THRDTEST для создания многочисленных потоков без очередей не оказало влияния на величину доступных ресурсов Windows 95. В противоположность этому свободные системные ресурсы убывали на 1% на каждые восемь потоков с очередями. Расход ресурсов был вызван тем, что каждой очереди сообщений требуетс выделить 96-байт блок из 64-Кбайт хипа модуля USER. Поскольку первые 10 Кбайт 64-Кбайт сегмента используются для хранения глобальных переменных, размер хипа составляет примерно 54 тыс. байт и может вместить 560 потоков с очередями. Так как другие компоненты также борются за долю ресурсов в хипе USER, на практике максимальное число потоков оказывается около 450. Теоретически в среде Windows NT и OS/2 можно создать неограниченное число потоков, на деле же очень немногим пользователям может потребоваться даже 450 потоков; система становится слишком медленной для нормального функционирования.
Во многих операционных системах активная прикладна программа, которая не освобождает вовремя ЦП, может стать источником проблем. W16MTX16 и W16MTX32 исследуют влияние такой прикладной программы на окружающую ее систему. Каждый тест запускает два экземпляра часов, показывающих в разных окнах текущее время. Выводимое на экран время обновляется каждую секунду. С помощью меню пользователь может запустить в одном из окон блокирующий цикл, который выполняется в течение 10 с, и наблюдать за поведением другого окна.
В среде Windows 3.1x после блокирования одного окна обновление второго окна полностью прекращается. На самом деле W16MTX16 приостановила также выполнение всех прочих программ в системе; они не реагировали на ввод с мыши и клавиатуры до тех пор, пока выполнение цикла не завершилось. Windows 3.1x - система с кооперативной многозадачностью, где предполагается, что прикладна программа быстро выполнит свою работу и передаст управление другим задачам. Однако некорректна программа может монополизировать всю систему.
Вследствие того что программный семафор Win16Mutex был постоянно взведен, результат выполнения W16MTX16 в среде Windows 95 оказался точно таким же. Поскольку только одна прикладная программа может обращаться к 16-разрядному системному коду в каждый момент времени, программам Win16 не разрешается вытеснять друг друга. Это, безусловно, стало проблемой для Windows 95, которая должна выполнять 16-разрядные прикладные программы в своей вытесняющей, многопотоковой среде. Решение было найдено с помощью семафора Win16Mutex. Дл того чтобы начать выполняться в среде Windows 95, 16-разрядная прикладная программа должна выставить программный семафор, и новые задачи не могут быть запущены до тех пор, пока семафор не будет освобожден. Любые 32-разрядные потоки, не обращающиеся к 16-разрядному системному коду, продолжат свою работу, но контроль над мышью, клавиатурой и обновлением экрана будет утерен.
Программа W16MTX16 создала похожие проблемы в среде Windows NT и OS/2. Поскольку оба окна с часами были созданы в одном 16-разрядном сеансе, второе окно не могло получить свою долю процессорного времени, тогда как первое окно располагало ресурсами и было заблокировано. (Однако если два окна созданы в разных сеансах Win16, то в среде Windows NT и OS/2 Warp вторые часы могут продолжить свою работу.)
Тест W16MTX32 показал совершенно иные результаты. В среде Windows 95 и Windows NT вторые часы продолжали нормально функционировать, после того как первые часы вошли в свой цикл. В среде Windows 95 полностью 32-разрядной программе для того, чтобы выполняться, не нужно обладать семафором Win16Mutex, и система Windows NT не требует наличия этого семафора.
В среде OS/2 результаты выполнения теста W16MTX32 были не столь впечатляющими; после того как первое окно с часами было заблокировано, отсчет времени на вторых часах не остановился, но замедлился. Ядро OS/2 Warp имеет систему ввода, напоминающую Windows 3.1x; собственная прикладная программа OS/2, не уступающа процессор, не даст другим программам выполнять код, отвечающий за интерфейс с пользователем. Однако OS/2 Warp пытается определить ситуации, когда прикладные программы не передают управление. Если необходимо, система приостанавливает неуступчивую прикладную программу и пытается передать управление следующей программе в соответствии с порядком наложения друг на друга окон на экране (Z-order). Этот метод, однако, несовершенен; лишь прикладная программа, занимающа вторую очередь, имеет шанс когда-нибудь продолжить работу, все остальные останутся заблокированными до тех пор, пока первая программа не уступит управление.
С помощью прикладных программ WNDTST16 и WNDTST32 мы выясняли, как много окон может быть создано одновременно. Тесты пытаются создать до 1600 кнопочных оконных объектов, но прекращают свою работу, если ресурсы системы оказываются исчерпанными прежде, чем достигнут этот предел.
В среде Windows 3.1x с помощью теста WNDTST16 было создано около 850 окон. Эта цифра может показатьс большой, но каждая кнопка, диалоговое окно, пиктограмма и орган управления редактированием в операционной системе, оснащенной ГИП, могут быть отдельным оконным объектом. Во время создания этих 850 окон свободные системные ресурсы модуля USER уменьшились с 83% до 0; для каждого окна, создаваемого в среде Windows 3.1x, требуется примерно 60 байт из 64-Кбайт хипа модул USER.
Так как экземпляр Windows 3.1x выполняется в сеансе Win-OS/2, WNDTST16 показала похожие результаты в среде OS/2; тестовая программа создала немногим более 800 окон, а свободные системные ресурсы модуля USER уменьшились с 85% до 0.
В отличие от этого WNDTST16 создала все 1600 окон как в среде Windows 95, так и Windows NT без какого бы то ни было влияния на свободные системные ресурсы. В Windows 95 максимальное теоретически возможное число одновременно открытых окон немного меньше 16 384, а в Windows NT их число ограничивается только доступной памятью. И наконец, 32-разрядная программа WNDTST32 создала 1600 окон в среде Windows 95, Windows NT и OS/2.
В заключение отметим, что Windows 95 обладает очевидным, хотя иной раз и скромным преимуществом перед Windows 3.1x в устойчивости к возникающим ошибкам и широте функциональных возможностей. Больший выигрыш можно получить, используя систему OS/2 Warp, хотя в ее архитектуре тоже имеются некоторые просчеты, отрицательно сказывающиеся на ее надежности. Из четырех прошедших испытания ОС лишь Windows NT выделяется как высоконадежная и не скованная ограничениями система.
Бомбовый удар
Насколько хорошо Windows 3.1x, Windows 95, OS/2 Warp и Windows NT защищают память от несанкционированной записи?
N/A - неприменимо; 16-разрядные версии Windows не могут выполнять 32-разрядные прикладные программы в собственной системе команд.
Windows 3.1 Windows for Workgroups 3.11 Windows 95 OS/2 Warp 3.0 Windows NT 3.51 16-разрядные программы BOMB16 Общее нарушение защиты (GPF) Легко восстанавливается Легко восстанавливается Легко восстанавливается Легко восстанавливается Легко восстанавл ивается Несанкционированная запись в обычную память ниже области размещения Windows Крах Крах Крах Завершает 16-разр. сеанс и легко восстанавливается Легко восстанавливается Несанкционированная запись в системную DLL Крах Крах Крах Завершает 16-разр. сеанс и легко восстанавливается Завершает 16-разр. сеанс и легко восстанавливается 32-разрядные программы BOMB32 Ошибка обработки страниц N/A N/A Легко восстанавливается Легко восстанавливается Легко восстанавливается Несанкционированная запись в обычную память ниже области размещения Windows N/A N/A Легко восстанавливается Легко восстанавливается Легко вос станавливается Несанкционированная запись в обычную память выше области размещения Windows N/A N/A Крах Легко восстанавливается Легко восстанавливается Несанкционированная запись в системную DLL N/A N/A Крах Крах* Легко восстанавливается
* Версия этого теста для OS/2 пытается произвести несанкционированную запись в системную DLL PMWWIN.DLL.
Краткий обзор ограничений
Каким образом наличие большого числа окон и потоков с очередями сообщений влияет на потребление ресурсов в Windows 3.1x, Windows 95, OS/2 Warp и Windows NT?
N/A* - неприменимо: Windows 3.1x и Windows for Workgroups не работают с потоками.
Windows 3.1 Windows for Workgroups 3.11 Windows 95 OS/2 Warp 3.0 Windows NT 3.51 Макс. число потоков с очередями сообщений N/A* N/A* Около 450 Не ограничено Не ограничено Свободные ресурсы модуля USER с макс. числом потоков N/A* N/A* 0% N/A** N/A** Число генерируемых оконных объектов (максимум 1600) 848 843 16-разр.: 1600; 32-разр.: 1600 Win-OS/2: 837; собств. программы OS/2: 1600 16-раз р.: 1600; 32-разр.: 1600 Свободные системные ресурсы после создания окон 0% 0% 16-разр.: 92%; 32-разр.: N/A** Win-OS/2: 0%; собств. программы OS/2: N/A** 16-разр.: 90 %; 32-разр.: N/A**
N/A** - неприменимо: мы не измеряли свободные системные ресурсы в среде 32-разрядных операционных систем. В OS/2 и Windows NT отсутствуют ограничения системных ресурсов.