Содержание к диссертации
Введение
Глава 1. Обзор моделей оценки производительности файловых систем 7
1.1. Типы нагрузок 7
1.2. Пакеты тестирования 11
1.2.1. Andrew Benchmark 12
1.2.2. PostMark 13
1.2.3. Iozone 15
1.2.4. HBench-FS 16
1.2.5. Другие 19
1.3. Резюме 19
Глава 2. Общая методика моделирования производительности файловых систем 21
2.1. Постановка задачи 21
2.2. Модель для нагрузки web-сервера 22
2.2.1. Файловый кэш 23
2.2.2. Нагрузка web-сервера со статическим содержимым 29
2.3. Требования к модели 35
Глава 3. Низкоуровневое моделирование производительности NTFS 36
3.1. Технология 37
3.2. Чтение 45
3.2.1. Модель двух хранилищ 45
3.2.2. Фрагментация 54
3.2.3. Множественная регрессия 64
3.3. Запись 72
3.4. Обработка метаданных 88
3.5. Проверка результатов 93
3.6. Практическое применение 96
Заключение 100
Благодарности 101
Список литературы 102
Введение к работе
Файловая система - это неотъемлемая часть операционной среды, которая отвечает за работу с данными, хранящимися во внешней памяти [Карпов, Коньков, 2004]. Для конечного пользователя одной из наиболее важных характеристик файловой системы является производительность, поскольку от нее зависит скорость работы того или иного приложения, а также операционной среды в целом.
Многочисленные исследования показали, что оценку быстродействия файловых систем необходимо осуществлять в контексте нагрузок, генерируемых приложениями [Нижник и др., 2006, С. 89-113]. Под термином «нагрузка» обычно понимается способ обращения к данным, который использует та или иная программа. Большинство существующих инструментов тестирования файловых систем имеет узкую специализацию, т.е. предназначено для оценки производительности при нагрузке, отражающей специфику конкретного приложения или класса приложений. Кроме того, практически все эти инструменты предполагают непосредственное тестирование интересующих пользователя нагрузок. Однако с точки зрения минимизации затрачиваемого времени и ресурсов (как программных, так и аппаратных) более важной является задача прогнозирования производительности. Решение этой задачи позволило бы оценивать быстродействие той или иной файловой системы на основе предварительно выведенной зависимости характеристики производительности от параметров нагрузки и тем самым ускорить процесс планирования вычислительной нагрузки в центрах данных предприятий.
Целью настоящей работы является разработка методики создания моделей, предназначенных для прогнозирования производительности файловых систем при произвольных нагрузках.
В главе 1 содержится обзор основных исследований, посвященных различным типам нагрузок. Дается описание существующих инструментов для
оценки производительности файловых систем, перечисляются их достоинства и недостатки. В главе 2 формулируется постановка задачи, предлагается общая методика ее решения, а также приводятся результаты применения методики для создания «высокоуровневой» (уровня пользовательских приложений) математической модели прогнозирования производительности файловой системы NTFS при нагрузке, генерируемой web-сервером. Глава 3 посвящена «низкоуровневому» (уровня драйвера файловой системы) моделированию производительности NTFS при нагрузках чтения, записи и обработки метаданных. Также в этой главе приводятся результаты практических экспериментов, подтверждающие состоятельность модели, а также описываются примеры ее практического применения.
Типы нагрузок
Доступ к внешним устройствам хранения данных (например, к жестким дискам) осуществляется значительно медленнее, чем к оперативной памяти. Поэтому одна из главных задач файловой системы состоит в том, чтобы скрыть этот недостаток при помощи таких технологий как кэширование (cache), опережающее чтение (speculative read), отложенная запись (lazy write) и др. [Таненбаум, 2004] Даже для выполнения синхронных запросов создатели файловых систем стараются минимизировать задержки путем расположения связанных данных в одной области диска. Эта и другие оптимизации базируются на предположениях о способах доступа к данным пользовательских приложений. К примеру, web-серверы часто обращаются к произвольным файлам небольшого размера, в то время как серверы потокового видео последовательно считывают большие файлы. Разные способы доступа к данным или, другими словами, разные типы нагрузок, создаваемых приложениями, требуют разных оптимизаций файловой системы.
Многие исследователи проводили анализ типов нагрузок, генерируемых приложениями в различных вычислительных средах. Некоторые пытались сделать обобщение касательно какого-то одного типа нагрузки; другие сравнивали нагрузки, создаваемые разными классами приложений; третьи исследовали типы нагрузок на файловые системы в разных операционных средах (например, Windows NT и UNIX); четвертые акцентировали внимание на изменении нагрузок во времени.
Все эти исследования подтвердили необходимость тестирования, отражающего специфику конкретного применения. Другими словами, технология тестирования производительности файловых систем должна позволять оценивать производительность в контексте нагрузок конкретных приложений, необходимых пользователю. Кроме того, она также должна адаптироваться к изменениям нагрузки, возникающим с течением времени.
Приведем обзор публикаций по основным исследованиям, касающимся классификации типов нагрузок на файловую систему. К.К. Рамакришнан и его коллеги в 1992 году изучали модели доступа к файлам в коммерческих вычислительных средах, используя платформу VAX/VMS [Ramakrishnan et al., 1992]. Эти среды включали следующие типы нагрузок: 1) разработка программного обеспечения; 2) управление офисом; 3) обработка транзакций; 4) пакетная обработка. Авторам удалось обнаружить существенные отличия между этими типами нагрузок. Например: - средний размер файлов при обработке транзакций и пакетной обработке был в 5-Ю раз больше, чем при других нагрузках, в то время как общее количество файлов было меньше; - при всех нагрузках в течение дня активности доступ осуществлялся к 10-30% данных (в байтах), за исключением обработки транзакций, при которой доступ происходил к 59-86% данных; - пакетная обработка имела самый высокий показатель отношения прочитанных данных к записанным данным (в байтах), второе место занимала обработка транзакций; - за 12-часовой период во всех нагрузках был осуществлен доступ к 25% файлов, тогда как база данных имела доступ к 82.2% файлов.
Таким образом, Рамакришнан и его коллеги выяснили, что, не смотря на схожесть во многих характеристиках доступа к файлам, среди исследуемых типов нагрузок сильно выделялась обработка транзакций. Еще одно исследование провели Смит и Зельцер [Smith, Seltzer, 1994]. В течение 10 месяцев они собирали информацию о 50 файловых системах, работающих на серверах SunOS 4.1.3. Основной упор делался на физическое расположение файлов на диске. Это позволило авторам выявить различия фрагментации в файловых системах, а также отследить изменение фрагментации с течением времени.
Смит и Зельцер обнаружили, что файловая система сервера новостей, на котором происходило частое создание и удаление файлов небольшого размера, была сильно фрагментирована. Тогда как файловая система, на которой хранились системные исполняемые файлы, напротив, была почти не фрагментирована.
В 1994 году Джефри Кёнинг и его коллеги из Университета Калифорнии в Лос-Анджелесе опубликовали исследование моделей доступа к файлам в коммерческих средах, работающих в операционной системе DOS [Kuenning et al., 1994]. Задачей ученых было придумать алгоритм, предсказывающий, какие файлы могут понадобиться портативному компьютеру в то время, когда он отключен от сети, с тем чтобы предварительно скачать эти файлы на диск. В процессе исследования авторы выделили три типа нагрузок: 1) персональная нагрузка (электронная почта, планирование проектов, календарь и т.д.); 2) программирование; 3) коммерческая нагрузка (бухгалтерский учет и т.п.). Кёнинг и его сотрудники выяснили, что доступ к наибольшему количеству данных в течение дня осуществляется в коммерческой среде: 18.2 МБ против 0.3-1.0 МБ при других нагрузках. Также выяснилось, что в коммерческой среде наибольший показатель так называемых конфликтов - одновременных обращений к одним и тем же данным разными пользователями в течение небольшого промежутка времени (4.3 на одного пользователя в день против 0-1.2). Дрю Розелли и ее коллеги в 1990 году осуществляли сбор информации о некоторых вычислительных средах. Среди них были UNIX-кластеры, участвующие в образовательной и научной деятельности Университета Калифорнии (Беркли), web-сервер, обслуживающий большую базу данных изображений, а также 8 рабочих станций с офисными приложениями, работающими на Windows NT [Roselli et al„ 2000].
Пакеты тестирования
Существуют различные пакеты тестирования производительности файловых систем, так называемые file system benchmarks. Традиционно они разделяются на две категории: микротесты (microbenchmarks) и макротесты (macrobenchmarks) [Smith, 2001]. Микротесты измеряют одну специфичную характеристику поведения файловой системы, например, время создания или удаления файла. Макротесты измеряют производительность всей файловой системы при определенной нагрузке. Макротест может использовать реальное приложение для создания нагрузки (например, компилятор и компоновщик программы) или сам являться приложением, создающим нагрузку на файловую систему. Макротест позволяет определить, какая файловая система дает лучшую производительность при заданной нагрузке. В то время как микротест помогает выявить детальные отличия производительности файловых систем (например, одна система может иметь более высокую пропускную способность ввода/вывода, чем другая).
С микротестами связаны две основных проблемы. Первая проблема заключается в том, что при использовании микротестов довольно легко исказить результаты. Поскольку не существует стандартных микротестов, каждый исследователь пишет свою программу, чтобы показать, как улучшился тот или иной аспект файловой системы. При этом не учитывается тот факт, что данное улучшение могло негативно повлиять на другие аспекты, и таким образом производительность всей системы могла уменьшиться. Вторая проблема микротестов - отсутствие реальной нагрузки при тестировании. В этом случае группа операций может дать результат, отличный от результата одной и той же операции, произведенной несколько раз [Tang, 1995].
Ниже приведено описание основных макротестов для измерения производительности файловых систем, принципы их работы, а также основные трудности, возникающие при их использовании.
Одним из первых инструментов оценки производительности файловых систем, относящимся к категории макротестов, является Andrew Benchmark. Он был разработан в Университете Карнеги-Меллона в 1988 году и предназначался для сравнения производительности Andrew File System (AFS) с другими распределенными файловыми системами [Howard et al., 1988].
Макротест Andrew Benchmark имитирует нагрузку, создаваемую при разработке программного обеспечения. Входными данными является исходный код некоторой программы, насчитывающей порядка 70 файлов общим объемом примерно 300 КБ. Тестирование проходит в 5 этапов: 1. Создание иерархии директорий. 2. Копирование исходных кодов программы в эту иерархию. 3. Чтение метаданных каждого файла (stat). 4. Чтение данных каждого файла (grep, wc)1. 5. Компиляция и компоновка программы. Результатом работы Andrew Benchmark является время выполнения каждой фазы тестирования. Первая фаза определяет скорость записи метаданных. Вторая - скорость одновременного чтения/записи метаданных и обычных 1 grep, stat, wc - команды UNIX. Справочная информация по ним содержится в UNIX man pages. данных. Третья - скорость чтения кэшированных метаданных. Четвертая -скорость чтения кэшированных данных. Пятая - скорость чтения кэшированных данных и асинхронной записи данных.
Основная проблема Andrew Benchmark заключается в отсутствии масштабируемости. Во времена создания теста входные данные такого размера создавали солидную нагрузку на систему, и время выполнения теста составляло десятки минут [Howard et al., 1988]. Однако на современном оборудовании тест выполняется в сотни раз быстрее, тем самым затрудняется подсчет скорости на каждом этапе тестирования, а также увеличивается погрешность. Кроме этого, существует проблема выполнения пятой фазы, поскольку тест использует устаревшие библиотеки и заголовочные файлы.
Большинство известных макротестов измеряет производительность файловой системы, используя большие и относительно долговременные файлы. Однако современные файловые серверы предоставляют такие услуги как электронная почта, новости, разного рода коммерческие сервисы, спецификой которых является работа с небольшими и кратковременными файлами. К примеру, анализ почтовых (особенно использующих протокол SMTP) и новостных серверов показал, что обычно такие машины обслуживают миллионы файлов небольшого размера (от 1 до 100 КБ), причем в каждый момент времени создается, читается, записывается и удаляется большое количество файлов, расположенных в различных частях дисковых разделов.
PostMark - это макротест, предназначенный для оценки производительности файловых систем именно в таких условиях. Он был спроектирован таким образом, чтобы измерять скорость транзакций для нагрузки, аппроксимирующей нагрузку большого почтового сервера. Подробное описание и некоторые результаты теста можно найти в статье его автора Джефри Кэтчера [Katcher, 1997]. PostMark работает следующим образом: 1. Создается совокупность текстовых файлов случайного размера. Количество файлов, а также минимальный и максимальный размер файлов задаются пользователем при конфигурировании теста. 2. С полученными файлами производится некоторое количество транзакций (это количество также можно указывать перед запуском теста). Каждая транзакция состоит из пары следующих операций: - создание или удаление; - чтение или запись. Типы транзакций, а также файлы, которые в них участвуют, выбираются случайным образом с целью избежать кэширования, опережающего чтения и других оптимизаций. Как часто будет выполняться та или иная операция, определяют соответствующие параметры конфигурации. 3. По окончании всех транзакций оставшиеся файлы удаляются. Результатом теста является отчет, содержащий следующие параметры производительности: - общее время работы; - общее время и средняя скорость выполнения транзакций (файл/сек); - общее количество созданных файлов и средняя скорость создания (файл/сек); - количество файлов, созданных на стадии 1, и средняя скорость создания (файл/сек); - количество файлов, созданных на стадии 2, и средняя скорость создания (файл/сек); - общее количество прочитанных файлов и средняя скорость чтения (файл/сек); - общее количество записанных файлов и средняя скорость записи (файл/сек); - общее количество удаленных файлов и средняя скорость удаления (файл/сек); - количество файлов, удаленных на стадии 3, и средняя скорость удаления (файл/сек); - количество файлов, удаленных на стадии 2, и средняя скорость удаления (файл/сек); - общее количество прочитанных данных и средняя скорость чтения (Б/сек); - общее количество записанных данных и средняя скорость записи (Б/сек).
В отличие от Andrew Benchmark пакет PostMark является масштабируемым, поскольку все необходимые параметры нагрузки (размер файлов, их количество и т.п.) можно конфигурировать перед запуском теста. Однако главный недостаток состоит в том, что данный пакет пригоден лишь для определенного типа нагрузки.
Например, в качестве эксперимента PostMark был запущен на файловой системе NTFS для одного файла размером 500 МБ и с количеством транзакций равным 1. При таких условиях на этапе выполнения транзакции происходит аварийное завершение программы. Значит, существуют конфигурации, для которых тест не способен выдать никаких (даже неверных) результатов. Это доказывает узкую специализацию PostMark, который оперирует только большим количеством маленьких файлов.
Модель для нагрузки web-сервера
Поскольку одним из наиболее распространенных и показательных типов нагрузок является web-сервер, исследование было начато именно с него. Тестирование web-серверов обычно осуществляется с помощью так называемых static и dynamic тестов, которые предназначены для определения производительности сетевых ресурсов со статическим и динамическим содержимым. Статическое содержимое включает в себя текстовые файлы, изображения, видео и другие данные, неизменяемые при обращении клиента к серверу. В свою очередь динамическое содержимое подразумевает исполнение сценариев и изменение отсылаемых данных при обработке клиентских запросов.
Для создания нагрузки в работе использовалась утилита httpjoad3. Данная программа выполняет множество одновременных HTTP запросов к серверу и в качестве результата возвращает такие характеристики как число полученных за время тестирования байтов, скорость выполнения запросов и т.д. Также httpjoad позволяет задавать размер и количество файлов, запрашиваемых на сервере, количество параллельных соединений, время продолжительности теста и другие параметры.
Эксперименты проводились на компьютере Intel Pentium 4 3.0 ГГц, DDR 1 ГБ с диском WDC WD400JB-00ENA0 объемом 37.27 ГБ и сетевой картой Marvell Yukon 88Е8001/8003/8010 PCI Gigabit Ethernet Controller. Тестовой операционной системой послужила Microsoft Windows ХР Professional 5.1.2600 Service Pack 2 с файловой системой New Technology File System (NTFS) v3.1 (v5.1) и web-сервером Microsoft Internet Information Server (MS IIS) v5.1. Такой выбор обусловлен, прежде всего, популярностью перечисленных продуктов, простотой их конфигурирования и удобством подсчета характеристик производительности. Тестовый клиент, на котором запускалась утилита httpload, и тестовый сервер находились в соседних подсетях Fast Ethernet. Первым экспериментом был static тест, создающий солидную нагрузку на web-сервер. На сервере было размещено 100 текстовых файлов объемом 1 КБ (К=100), 100 объемом 1 МБ (М=100) и параллельно выполнялось 100 запросов (F=100) к файлам в произвольном порядке. Одновременно с этим замерялись следующие характеристики системы: скорость чтения данных с диска (КБ/с) и скорость отправки данных клиенту (КБ/с). Объем оперативной памяти в этом тесте был равен 1 ГБ (RAM=1024). На рис. 2 представлен полученный график скорости чтения данных с диска и скорости отправки данных в зависимости от времени (средние значения за минуту). Чтобы объяснить вид этих функций, необходимы некоторые сведения о работе подсистемы файлового кэша Windows.
Встроенный файловый кэш Windows существенно влияет на производительность этой операционной системы, а также многих приложений, в частности web-сервера MS IIS. Файловый кэш - это особая зарезервированная область виртуального пространства в диапазоне адресов системной памяти [Руссинович, Соломон, 2005]. Из названия понятно, что файловый кэш оперирует с файлами или, точнее, частями файлов. Когда происходит обращение к частям файла, они отображаются в упомянутую область виртуальной памяти диспетчером кэша (Cache Manager). Такое отображение происходит прозрачно для приложения, читающего или пишущего данный файл (это значит, что функции кэширования скрыты от приложений). Система управляет памятью, используемой под файловый кэш, точно так же, как любой другой областью памяти из системного рабочего набора. Файлы, обращение к которым осуществляется часто, автоматически стремятся остаться в кэш памяти, поэтому не требуется никакой дополнительной настройки для того, чтобы инициировать кэширование в Windows.
Основная идея резидентного (постоянно находящегося в физической памяти) файлового кэша заключается в том, чтобы ускорить доступ к долгосрочным данным, хранящимся на диске. Доступ к файловым сегментам, находящимся в физической памяти, происходит намного быстрее, чем при обращении к диску или CD-ROM. Однако важно понимать, что кэширование не является безусловной гарантией увеличения скорости доступа к файлам. Например, кэширование файла, читаемого приложением один раз от начала и до конца, почти не дает увеличения производительности, поскольку блоки данных, связанные с файлом, все равно сначала должны быть последовательно считаны в физическую память. Файловый кэш Windows пытается ускорить реагирование на последовательную активность путем предварительного считывания (prefetching) блоков данных с диска «в предчувствии» следующего запроса. Такой подход повышает оперативность реагирования приоритетных приложений, таких как Microsoft Word. К примеру, когда пользователь листает документ, данные, которые должны обновляться на экране, уже загружены с диска в физическую память.
Как только файл считывается повторно, преимущества кэширования становятся очевидными. Поскольку запрашиваемые блоки данных уже являются резидентными, последовательные запросы ввода/вывода разрешаются непосредственно из памяти без выполнения операций с диском. Файл, к которому осуществляют коллективный доступ несколько пользователей (например, по сети), однажды сохраняется в кэш. После того как первый пользователь инициировал обращение к файлу на диске, данные файла помещаются в физическую память. Остальные пользователи оказываются в более выгодном положении, поскольку доступ к данному файлу теперь будет осуществляться намного быстрее.
Использование файлового кэша Windows более эффективно для работы многопользовательских серверных приложений, чем для однопользовательских программ. MS IIS является хорошим тому примером: файлы, часто запрашиваемые пользователями web-серверов, кэшируются в физическую память, позволяя MS IIS обрабатывать данные, не обращаясь к физическому диску.
В Windows NT размер файлового кэша на платформе х86 ограничен 512 МБ виртуальной памяти, в Windows 2000/ХР/2003 - 960 МБ [Pentakalos, Friedman, 2002]. Однако диспетчер кэша способен кэшировать в физической памяти гораздо больший объем файловых данных, чем может содержаться в рабочем наборе. Предположим, что все виртуальное пространство файлового кэша занято, тогда при последующих операциях чтения файлов, не находящихся в кэше, будет отменяться проецирование представлений для старых файлов и выполняться проецирование для новых. Когда диспетчер кэша отменяет проецирование какого-либо представления, диспетчер памяти (Memory Manager) не отбрасывает файловые данные в рабочем наборе кэша, соответствующие этому представлению, а перемещает их в список простаивающих страниц. В отсутствие запросов на выделение физической памяти под другие задачи список простаивающих страниц может занимать почти всю физическую память за вычетом системного рабочего набора. Повторное обращение к файлам, проецирование которых было отменено и страницы которых являются простаивающими, будет осуществляться почти также быстро, как и к файлам находящимся в кэше. Таким образом, общий объем кэшируемых данных напрямую зависит от размера оперативной памяти [Руссинович, Соломон, 2005].
Теперь (возвращаясь к рис. 2) становится понятно, что вид функций обусловлен насыщением файлового кэша. Уже на четвертой минуте теста дисковая активность равна нулю, а это означает, что все запрашиваемые файлы находятся в физической памяти. Приблизительно в это же время устанавливается максимальный уровень скорости отправки данных: его значение 8 МБ/с, скорее всего, объясняется особенностями реализации утилиты http_load либо сервера MS IIS, т.к. пропускная способность канала составляет 12.5 МБ/с.
Поскольку в реальной жизни размер данных, запрашиваемых на сервере, может быть соизмерим с объемом оперативной памяти или превышать его, было решено исследовать зависимость поведения файлового кэша от общего размера данных и количества оперативной памяти.
Модель двух хранилищ
В Windows NT кэшируемые запросы на чтение, поступающие в драйвер файловой системы (ntfs.sys) из пользовательских приложений, в первую очередь передаются диспетчеру кэша (Cache Manager). Если запрошенные данные присутствуют в кэше, диспетчер кэша копирует их в пользовательский буфер, и управление передается обратно: сначала драйверу файловой системы, а затем приложению, инициировавшему запрос (рис. 13). Если же данных в кэше не оказалось, попытка их копирования приведет к исключительной ситуации «ошибка страницы» (page fault) [Рихтер, 2001], которую обрабатывает диспетчер памяти (Memory Manager): он выполняет повторный, но уже некэ-шируемый запрос к драйверу файловой системы, передаваемый непосредственно драйверу диска (disk.sys). Драйвер диска в свою очередь копирует данные с устройства в кэш, и управление передается обратно по цепочке драйверу файловой системы, диспетчеру памяти и диспетчеру кэша. Очевидно, что кэшированные данные обрабатываются гораздо быстрее, чем не кэшированные [Таненбаум, 2004]. То есть, можно сказать, что файловая система работает с двумя хранилищами данных: быстрым (кэш) и медленным (диск), поэтому ее производительность напрямую зависит от того, сколько запрашиваемых данных находится в каждом из хранилищ. На самом деле существует три сценария чтения данных (рис. 15): 1) при обработке кэшируемого запроса данные были найдены в кэше; 2) при обработке кэшируемого запроса данные не были найдены в кэше, и потребовалось обращение к диску; 3) при обработке некэшируемого запроса данные были прочитаны с диска без обращения к кэшу. Поскольку обращение к кэшу происходит намного быстрее, чем обращение к диску, запросы второго и третьего типа выполняются примерно за одинаковое время, поэтому можно объединить их в одну группу и считать их дисковыми (медленными) запросами. Пусть С - множество запросов, при которых данные берутся только из кэша (т.е. к быстрому хранилищу), a D - множество запросов, требующих обращения к диску (т.е. к медленному хранилищу). Тогда нагрузка на файловую систему представляет собой последовательность запросов из множества CUD, причем для чтения С Г) D = 0.
Для проверки гипотезы (3.3) был проведен ряд экспериментов, заключавшихся в поиске некоторой подстроки в файлах заданной директории при помощи файлового менеджера Far10 и исследовании журнала запросов, составленного драйвером filespy. Причем при оценке Tdr (времени чтения данных с диска) каждый эксперимент проводился только после перезагрузки компьютера с целью очистки файлового кэша, тогда как для вычисления Тсг (времени чтения данных из памяти) замеры осуществлялись лишь после нескольких процедур поиска, чтобы гарантировать отсутствие обращений к диску. Кроме того, в случае оценки Тсг общий размер директории не должен был превышать размер системного файлового кэша.
Марквардта (Levenberg-Marquardt Algorithm, LMA) [Ranganathan, 2004]. LMA решает задачу нелинейной оптимизации методом наименьших квадратов. Данный алгоритм является комбинацией простейшего градиентного метода и метода Гаусса-Ньютона, а также может рассматриваться как метод доверительных интервалов. Хотя LMA является не оптимальным, а эвристическим алгоритмом, он очень хорошо работает на практике. Выбор LMA в работе обусловлен главным образом быстротой сходимости и популярностью практического применения.
