Оценка нагрузки в отсутствие системы

Если для проведения измерений существующая система не доступна, часто оказывается возможной примерная оценка, основанная на предполагаемом использовании системы. Выполнение такой оценки требует понимания того, каким объемом данных будет манипулировать клиент. Этот метод достаточно точен, если приложение попадает в категорию систем с интенсивным использованием данных. Некоторая разумная оценка обычно может быть также сделана и для среды с интенсивным использованием атрибутов, но множество факторов делает такую оценку несколько менее точной.

Оценка среды с интенсивным использованием данных

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

Например, рассмотрим клиентскую рабочую станцию, выполняющую приложение, которое осуществляет поиск областей с заданной температурой в некотором объеме жидкости. Типовой набор данных для решения этой задачи составляет 400 Мбайт. Обычно он читается порциями по 50 Мбайт. Каждая порция проходит полную обработку прежде, чем приложение переходит к следующей. Обработка каждого сегмента занимает примерно 5 минут времени ЦП, а результирующие файлы, которые записываются на диск имеют размер около 1 Мбайта. Предположим, что в качестве сетевой среды используется FDDI. Максимальная нагрузка на NFS будет возникать, когда клиент читает каждую порцию объемом 50 Мбайт. При максимальной скорости 2.5 Мбайт/с клиент будет полностью активным примерно в течение двадцати секунд, выполняя 320 операций чтения в секунду. Поскольку каждый запуск программы занимает примерно 40 минут (или 2400 секунд) времени, и на один прогон требуется (400 + 1) Мb х 125 ops/Mb = 50,125 ops, средняя скорость равна примерно 20 ops/sec. Сервер должен будет обеспечивать обслуживание пиковой скорости запросов (320 ops/sec) в течение примерно 20 секунд из каждых 5 минут, или примерно в течение 7% времени. Из этого упражнения можно извлечь три порции полезной информации: среднюю скорость активных запросов (20 ops/sec), пиковую скорость запросов (320 ops/sec) и вероятность того, что пиковая скорость требуется. На базе этой информации может быть сформирована оценка общей скорости запросов. Если в конфигурации системы будет 10 клиентов, то средняя скорость запросов составит 200 ops/sec. (Эту скорость не следует сравнивать с результатами теста LADDIS, поскольку в данном случае смеси операций очень отличаются). Вероятность того, что два клиента будут требовать работы с пиковой скоростью одновременно составляет примерно 0.07 х 0.07 = 0.049, или примерно 5%, а три клиента будут требовать пикового обслуживания только в течение 0.034% времени. Таким образом, из этой информации разумно вывести следующие заключения:

• Поскольку вероятность того, что три клиента будут одновременно активными, намного меньше 1%, максимальная нагрузка будет превышать индивидуальную пиковую нагрузку в 2-3 раза.
• Требуется только одна сеть, поскольку максимальная предполагаемая нагрузка составляет только 3 х 2.5 Mb/sec = 7.5 MB/s, т.е. намного ниже максимальной полосы пропускания сети FDDI (12.5 MB/sec).
• Поскольку в любой момент времени полностью активными будут только два или три клиента, требуется по крайней мере от 3 до 6 дисковых накопителей (хотя для типовых файлов размером по 400 MB очень вероятно, что потребуется более 6 дисков просто для хранения данных).
• Требуется по крайней мере два главных адаптера SCSI.
• Поскольку в состав системы входит одна высокоскоростная сеть, то рекомендуется использовать сервер с двумя процессорами SuperSPARC/SuperCashe.
• Поскольку маловероятно, что очень большой кэш файлов окажется полезным для работы такого сервера, требуется минимальный объем основной памяти - 128 Мбайт вполне достаточно.
• Если требуется сравнительно небольшая ферма дисков, например, объемом около 16 Гбайт, то система SPARCstation 10 Model 512 очень хорошо сможет справиться с этой задачей, поскольку один слот SBus требуется для интерфейса FDDI, а оставшиеся три слота могут использоваться для установки главных адаптеров SCSI, чтобы обеспечить в общей сложности 4 интерфейса FSBE/S, к каждому из которых подключается дисковые накопители общей емкостью по 4.2 Гбайт. Однако для этого приложения может лучше подойти система SPARCserver 1000, которая обеспечит большую емкость памяти: система с двумя системными платами позволяет создать конфигурацию с семью главными адаптерами SCSI и емкостью дисковой памяти более 28 Гбайт (по одному многодисковому устройству емкостью 4.2 Гбайт на каждую плату FSBE/S, не считая четырех встроенных дисков емкостью по 535 Мбайт). В случае, если потребуется большая емкость дисков, можно сконфигурировать систему SPARCcenter 2000 с двумя системными платами, чтобы обеспечить реализацию шести интерфейсов DWI/S и до 12 шасси с дисками емкостью по 2.9 Гбайт - примерно 208 Гбайт памяти.
• Во все предлагаемые системы можно установить NVSIMM без использования слотов SBus, и все они легко поддерживают установку двух требуемых процессоров. Использование NVSIMM вообще не очень важно, поскольку пропорция операций записи слишком мала (меньше, чем 1:400, или 0.25%).

Заметим, что при выборе конфигурации системы для приложений с интенсивным использованием данных вообще говоря не очень полезно сравнивать предполагаемые скорости запросов с рейтингом предполагаемого сервера по SPECsfs_097, поскольку смеси операций отличаются настолько, что нагрузки нельзя сравнивать. К счастью, такая оценка обычно оказывается достаточно точной.

Оценка среды с интенсивным использованием атрибутов

В предыдущем примере предполагалось, что нагрузка NFS от операций с атрибутами была пренебрежимо мала по сравнению с операциями с данными. Если же это не так, например, в среде разработки программного обеспечения, необходимо сделать некоторые предположения относительно предполагаемой смеси команд NFS. В отсутствии другой информации, в качестве образца можно принять, например, так называемую смесь Legato. В тесте SPECsfs_097 (известной также под названием LADDIS) используется именно эта смесь, в которой операции с данными включают 22% операций чтения и 15% операций записи.

Рассмотрим клиентскую рабочую станцию, наиболее интенсивная работа которой связана с перекомпиляцией программной системы, состоящей из исходного кода объемом 25 Мбайт. Известно, что рабочие станции могут скомпилировать систему примерно за 30 минут. В процессе компиляции генерируется примерно 18 Мбайт промежуточного объектного кода и двоичные коды. Из этой информации мы можем заключить, что клиентская система будет записывать на сервер 18 Мбайт и читать по крайней мере 25 Мбайт (возможно больше, поскольку почти треть исходного кода состоит из файлов заголовков, которые включены посредством множества исходных модулей). Для предотвращения повторного чтения этих файлов включений может использоваться кэширующая файловая система. Предположим, что используется CFS. Во время "конструирования" необходимо передать 33 Мбайт действительных данных, или 33 Мb х 125 ops/Mb = 4125 операций с данными за 30 минут (1800 секунд), что примерно соответствует скорости 2.3 ops/sec. (Здесь предполагается, что каждая операция выполняется с данными объемом 8 Kb, поэтому для пересылки 1 Mb данных требуется 125 операций). Поскольку эта работа связана с интенсивным использованием атрибутов, необходимо оценить существенное количество промахивающихся операций с атрибутами. Предположив, что смесь операций соответствует смеси Legato, общая скорость будет примерно равна:

Объем читаемых данных * 125

NFSops/sec = или
22%

Объем записываемых данных * 125

NFSops/sec = .
15%

В данном случае скорость равна: (25 Мb по чтению х 125ops/Mb) / 22% / 1800 секунд, или 7.89 ops/sec. Для проверки мы также имеем (18 Мb по записи х 125 ops/Mb) / 15% / 1800 секунд, или 8.33 ops/sec. В данном случае соотношение операций чтения и записи очень похоже на смесь Legato, но это может быть и не так, например, если были открыты файлы программы просмотра исходного текста (размер файлов программы просмотра исходного текста (source brouser files) часто в 4-6 раз превосходит размер исходного кода). В этом случае у нас нет способа оценки пиковой нагрузки.

Если имеются двадцать рабочих станций, работающие в описанном выше режиме, мы можем составить следующие заключения:

• Даже при совершенно невероятном условии, когда все двадцать рабочих станций полностью активны все время, общая скорость запросов составляет 8.33 ops/sec x 20 клиентов, или 166 ops/sec, т.е. ниже максимума в 200 ops/sec, который поддерживает Ethernet. Осторожные люди сконфигурируют для такой нагрузки две сети, но если материально-технические соображения заранее это исключают, то и одной сети вероятно будет достаточно.
• Поскольку нагрузка относительно легкая, система SPARCstation 10 Model 40 оказывается более, чем адекватной. (Даже в самом плохом случае, имеются только две сети). Процессорной мощности системы SPARCclassic также обычно вполне достаточно.
• Хотя общее количество данных очень невелико (25 Мбайт исходного кода и 18 Мбайт объектного кода; даже двадцать полных копий составляют только 660 Мбайт), то в рекомендуемую конфигурацию дисков можно включить два диска по 535 Мбайт. В предположении, что используется CFS, может быть достаточно и одного диска, поскольку файлы заголовков не будут часто читаться с сервера (они будут кэшироваться клиентами).
• При одном или двух дисках данных одной шины SCSI полностью достаточно.
• Объем данных очень маленький и большинство из них будут читаться и пересылаться многим клиентам многократно, поэтому конечно стоит сконфигурировать достаточно памяти, чтобы все эти данные кэшировать: 16 Мбайт базовой памяти под ОС, плюс 25 Мбайт для кэширования исходных кодов в конфигурации 48-64 Мбайт.
• Поскольку в этой среде операции записи достаточно часты, NVSIMM или PrestoServe являются существенными.
• Для окончательного варианта системы можно выбрать либо станцию начального уровня SPARCstation 10, либо хорошо сконфигурированную станцию SPARCclassic. Для контроля с точки зрения здравого смысла заметим, что максимальная скорость запросов в 166 ops/sec на 75% меньше показателей SPARCclassic (236 ops/sec) на тесте LADDIS (вспомните, что скорость 166 ops/sec предполагала, что все 20 клиентов полностью активны все время, хотя реальные журналы использования систем показывают, что этого никогда не бывает); Максимальная требуемая нагрузка наполовину меньше той, которую показывает SPARCstation 10 Model 40 на тесте LADDIS (411 ops/sec). Сравнение с показателем LADDIS соответствует ситуациям с интенсивным использованием атрибутов, поскольку результаты LADDIS используют интенсивную по атрибутам смесь операций.

Таблица 4.3. Показатели LADDIS для различных NFS-серверов Sun под управлением Solaris 2.3. Немного (на 5%) более высокие скорости достижимы при использовании FDDI,
немного меньшие скорости - при использовании 16 Мбит Token Ring.

Последняя возможность: использование похожей нагрузки

Если отсутствует система для проведения измерений и поведение приложения не очень хорошо понятно, можно сделать оценку базируясь на похожей прикладной нагрузке, показанной в таблицах 4.4 - 4.6. Эти данные дают некоторое представление и примеры измеренных нагрузок NFS. Это не означает, что они дают определенную картину того, какую нагрузку следует ожидать от определенных задач. В частности, заметим, что приведенные в этих таблицах данные представляют собой максимальные предполагаемые нагрузки от реальных клиентов, поскольку эти цифры отражают только тот период времени, когда система активно выполняет NFS-запросы. Как отмечено выше в разд. 3.1.4, системы почти никогда не бывают полностью активными все время. Примечательным исключением из этого правила являются вычислительные серверы, которые в действительности представляют собой непрерывно работающие пакетные машины. Например, работа системы 486/33, выполняющей 1-2-3, показана в таблице 4.2 и на рис. 4.2. Хотя представленная в таблице пиковая нагрузка равна 80 ops/sec, из рисунка ясно, что общая нагрузка составляет меньше 10% этой скорости и что средняя за пять минут нагрузка значительно меньше 10 ops/sec. При усреднении за более длительный период времени, нагрузка ПК примерно равна 0.1 ops/sec. Большинство рабочих станций класса SPARCstation2 или SPARCstation ELC дают в среднем 1 op/sec, а большинство разумных эквивалентов клиентов SPARCstation 10 Model 51, Model 512, HP 9000/735 или RS6000/375 - 1-2 ops/sec. Конечно эти цифры существенно меняются в зависимости от индивидуальности пользователя и приложения.

Таблица 4.4. Оценка нагрузки полностью активных клиентов NFS на бизнес-приложениях (операция/с и продолжительность этапов)

Таблица 4.5. Оценка нагрузки полностью активных клиентов NFS на приложениях САПР (операция/с и продолжительность этапов)

Таблица 4.6. Оценка нагрузки полностью активных клиентов NFS на приложениях разработки ПО (операция/с и продолжительность этапов)

[Предыдущая глава] [Оглавление] [Следующая глава]