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

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

Тактовая частота процессора

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

Измеряется тактовая частота в мегагерцах (MHz) и гигагерцах (GHz) . Количество тактов в секунду, выполняемых процессором, не совпадает с количеством операций, выполняемых процессором за секунду, поскольку для реализации многих математических операций требуется несколько тактов. Понятно, что в одинаковых условиях процессор с более высокой тактовой частотой должен работать эффективнее, чем процессор с более низкой тактовой частотой.

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

Объем оперативной памяти

Важным фактором, влияющим на производительность компьютера, является объем оперативной памяти и её быстродействие (время доступа, измеряется в наносекундах). Тип и объем оперативной памяти оказывает большое влияние на скорость работы компьютера.

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

Чтобы сравнить скорость работы процессора и оперативной памяти, достаточно привести только один факт: почти половину времени процессор простаивает в. ожидании ответа от оперативной памяти. Поэтому чем меньше время доступа к оперативной памяти (т. е. чем она быстрее), тем меньше постаивает процессор, и тем быстрее работает компьютер.

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

Объем жёсткого диска и скорость работы жёсткого диска

На производительность компьютера влияет скорость связи шины жёсткого диска и свободный объем дискового пространства.

Объем жёсткого диска, как правило, влияет на количество программ, которые вы можете установить на компьютер, и на количество хранимых данных. Ёмкость накопителей для жёстких дисков измеряется, как правило, десятками и сотнями гигабайт.

Жёсткий диск работает медленнее, чем оперативная память . Так как скорость обмена данными для жёстких дисков Ultra DMA 100 не превышает 100 мегабайт в секунду (133 Мбайт/сек для Ultra DMA 133). Ещё медленнее происходит обмен данными в DVD и CD-приводах.

Важными характеристиками винчестера, влияющими на Скорость работы компьютера, являются:

• Скорость вращения шпинделя;
• Среднее время поиска данных;
• Максимальная скорость передачи данных.

Размер свободного места на жёстком диске

При нехватке места в оперативной памяти компьютера Windows и многие прикладные программы вынуждены размещать часть данных, необходимых для текущей работы, на жёстком диске, создавая так называемые временные файлы (swap files) или файлы подкачки .

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

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

Дефрагментация файлов

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

Например, для выполнения дефрагментации в операционной системе Windows 7 щёлкните по кнопке Пуск и в раскрывшемся главном меню выберите последовательно команды Все программы, Стандартные, Служебные, Дефрагментация диска .

Количество одновременно работающих приложений

Windows - многозадачная операционная система , которая позволяет одновременно работать сразу с несколькими приложениями. Но чем больше приложений одновременно работают, тем сильнее возрастает нагрузка на процессор, оперативную память, жёсткий диск, и тем самым замедляется скорость работы всего компьютера, всех приложений.

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

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

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

Зависимость общей производительности системы от памяти имеет сложный характер, что затрудняет прямую оценку скорости памяти, то есть сравнения различных модулей. Например, память с частотой 1600 МГц имеет вдвое большую пропускную способность, чем 800-мегагерцовая. И синтетические тесты памяти прилежно выведут столбик в два раза выше. Но если вы протестируете целую систему с этими двумя видами памяти с помощью популярных тестовых приложений, на которых обычно тестируют процессоры, то и близко не получите двухкратной разницы в производительности. Интегральный индекс быстродействия может отличаться максимум на несколько десятков процентов.

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

Краткая теория

Чтобы понять специфику проблемы, рассмотрим принципиальную схему взаимодействия приложения, ЦП и подсистемы памяти. Уже давно для описания работы центрального процесса считается удачной аналогия с заводским конвейером. И движутся по этому конвейеру инструкции из программного кода, а функциональные модули процессора обрабатывают их словно станки. Тогда современные многоядерные ЦП будут подобны заводам с несколькими цехами. Например, работу технологии Hyper-Threading можно сравнить с конвейером, по которому едут вперемешку детали сразу нескольких автомобилей, и умные станки обрабатывают их одновременно, по метке на деталях определяя, к какой модели машины они относятся. Например, собирается красная и синяя машины, тогда красящий станок использует красную краску для деталей красной машины и синюю краску для синей. И поток деталей сразу для двух моделей позволяет лучше загрузить станки. А если аппарат для покраски будет иметь два распылителя, и сможет красить одновременно две детали в разные цвета, конвейер сможет работать на полную мощность вне зависимости от того, в каком порядке будут поступать детали. Наконец, последний писк моды, реализуемый в будущих процессорах AMD, в которых различные ядра ЦП будут иметь некоторые общие функциональные блоки, можно сравнить с идеей сделать часть особо громоздких и дорогих станков общей для двух цехов, чтобы сэкономить заводскую площадь и сократить капитальные затраты.

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

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

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

Другие же программы имеют так называемый локальный доступ к памяти, то есть они читают или пишут в близко расположенные ячейки памяти - им относительно безразлична скорость случайного доступа. Это свойство программ объясняет эффект от наращивания объемов кэш-памяти в процессорах, которая, благодаря близкому расположению к ядру, в десятки раз быстрее. Даже если программа требует, например, 512 МБ общей памяти, в каждый отдельный небольшой промежуток времени (например, миллион тактов, то есть одна миллисекунда), программа может работать только с несколькими мегабайтами данных, которые успешно помещаются в кэше. И потребуется только обновлять время от времени содержимое кэша, что, в общем, происходит быстро. Но может быть и обратная ситуация: программа занимает всего 50 МБ памяти, но постоянно работает со всем этим объемом. А 50 МБ значительно превышают типичный размер кэша существующих настольных процессоров, и, условно говоря, 90% обращений к памяти (при размере кэша в 5 МБ) не кэшируются, то есть 9 из 10 обращений идут непосредственно в память, так как необходимых данных нет в кэше. И общая производительность будет почти полностью лимитирована скоростью памяти, так как процессор практически всегда будет находиться в ожидании данных.

Время доступа к памяти в случае, когда данных нет в кэше, составляет сотни тактов. И одна инструкция обращения к памяти по времени равноценна десяткам арифметических.

«Памятенезависимые» приложения

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

Кроме того, важно, как часто в коде программы встречаются сами инструкции обращения к памяти. Если значительная часть вычислений происходит с регистрами, велик процент арифметических операций, то влияние скорости памяти снижается. Тем более что современные ЦП умеют изменять порядок выполнения инструкций и начинают загружать данные из памяти задолго до того, как те реально понадобятся для вычислений. Такая технология называется предвыборкой данных (prefetch). Качество реализации данной технологии также влияет на памятезависимость приложения. Теоретически, ЦП с идеальным prefetch не потребуется быстрая память, так как он не будет простаивать в ожидании данных.

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

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

Еще одна причина, по которой пользователь может не обнаружить разницы при смене памяти, состоит в том, что она и так слишком быстрая для используемого процессора. Если бы сейчас все процессоры вдруг замедлились в 10 раз, то для производительности системы в большинстве программ стало бы абсолютно все равно, какой тип памяти в ней установлен - хоть DDR-400, хоть DDR3-1600. А если бы ЦП радикально ускорились, то производительность значительной части программ наоборот стала бы гораздо существеннее зависеть от характеристик памяти.

Таким образом, реальная производительность памяти есть величина относительная, и определяется в том числе и используемым процессором, а также особенностями ПО.

«Памятезависимые» приложения

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

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

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

Достаточно сильно от производительности памяти могут зависеть и игры других жанров, пусть не со столь умным искусственным интеллектом, зато с собственными алгоритмами имитации виртуального мира, включая физическую модель. Впрочем, они на практике чаще всего упираются в производительность видеокарты, поэтому тестировать на них память также бывает не очень удобно. Кроме того, важным параметром комфортного игрового процесса в трехмерных играх от «первого лица» является минимальное значение fps: его возможное проседание в пылу жестокой битвы может иметь самые плачевные для виртуального героя последствия. А минимальный fps тоже, можно сказать, невозможно измерить. Опять же - из-за вариативного поведения ИИ, особенностей расчета «физики» и случайных системных событий, которые тоже могут приводить к проседанию. Как прикажете в таком случае анализировать полученные данные?

Тестирование скорости игр в демо-роликах имеет ограниченное применение еще и потому, что не все части игрового движка бывают задействованы для воспроизведения демки, и в реальной игре на скорость могут влиять иные факторы. Причем даже в таких наполовину искусственных условиях минимальный fps непостоянен, и его редко приводят в отчетах о тестировании. Хотя, повторимся, это наиболее важный параметр, и в тех случаях, когда идет обращение к данным, проседание fps весьма вероятно. Ведь современные игры, в силу своей сложности, разнообразия кода, включающего помимо поддержки физического движка и искусственного интеллекта также подготовку графической модели, обработку звука, передачу данных через сеть и пр., очень зависят как от объема, так и от производительности памяти. Кстати, будет заблуждением считать, что графический процессор обрабатывает сам всю графику: он только рисует треугольники, текстуры и тени, а формированием команд все равно занимается ЦП, и для сложной сцены это вычислительно емкая задача. К примеру, когда вышел Athlon 64 с интегрированным контроллером памяти, наибольший прирост в скорости по сравнению со старым Athlon был именно в играх, хотя там не использовались 64-битность, SSE2 и другие новые «фишки» Athlon 64. Именно существенное повышение эффективности работы с памятью благодаря интегрированному контроллеру сделало тогдашний новый процессор AMD чемпионом и лидером по производительности в первую очередь в играх.

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

Ещё одним принципиальным случаем усиленной зависимости от памяти является режим многозадачности, то есть запуск нескольких ресурсоемких приложений одновременно. Вспомним снова все тот же AMD Athlon 64 с интегрированным контроллером памяти, который к моменту анонса Intel Core выпускался уже в двухъядерном варианте. Когда вышел Intel Core на новом ядре, процессоры AMD стали проигрывать везде, кроме SPEC rate - многопоточном варианте SPEC CPU, когда запускается столько копий тестовой задачи, сколько ядер в системе. Новое интеловское ядро, обладая большей вычислительной мощностью, тупо затыкалось в этом тесте в производительность памяти, и даже большой кэш и широкая шина памяти не помогали.

Но почему это не проявлялось в отдельных пользовательских задачах, в том числе многопоточных? Главной причиной было то, что большинство пользовательских приложений, которые в принципе хорошо поддерживают многоядерность, всячески оптимизированы. Вспомним в очередной раз пакеты для работы с видео и графикой, которые больше всех получают прирост от многопоточности - всё это оптимизированные приложения. К тому же объем используемой памяти меньше, когда код параллелится внутри программы - по сравнению с вариантом, когда запускаются несколько копий одной задачи, а тем более - разные приложения.

А вот если запустить на ПК сразу несколько различных приложений, нагрузка на память возрастет многократно. Это произойдет по двум причинам: во-первых, кэш-память будет поделена между несколькими задачами, то есть каждой достанется только часть. В современных ЦП кэш L2 или L3 - общий для всех ядер, и если одна программа использует много потоков, то они все могут выполняться на своем ядре и работать с общим массивом данных в L3-кэше, а если программа однопоточна, то ей достается весь объем L3 целиком. Но если потоки принадлежат различным задачам, объем кэша будет вынужденно делиться между ними.

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

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

Типичным примером такой ситуации на ПК будет одновременный запуск игры, «скайпа», антивируса и программы кодирования видеофайла. Пусть не типичная, но совсем не фантастическая ситуация, в которой очень сложно корректно измерить скорость работы, так как на результат влияют действия планировщика в составе ОС, который при каждом замере может по-иному распределять задачи и потоки по разным ядрам и давать им различные приоритеты, временны́е интервалы и делать это в разной последовательности. И опять-таки, наиболее важным параметром будет пресловутая плавность работы - характеристика, по аналогии с минимальным fps в играх, которую в данном случае измерить еще сложнее. Что толку от запуска игры или какой-то другой программы одновременно с кодированием видеофайла, если поиграть нормально не удастся из-за рывков изображения? Пусть даже видеофайл быстро сконвертируется, поскольку многоядерный процессор в данном случае может быть и недогружен. Здесь нагрузка на систему памяти будет гораздо больше, чем при исполнении каждой из перечисленных задач по отдельности.

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

Проблемы тестирования

Сразу целая группа факторов снижает чувствительность ЦП-ориентированных тестов к скорости памяти. Очень чувствительные к памяти программы представляют собой плохие тесты ЦП - в том смысле, что они слабо реагируют на модель ЦП. Такие программы могут различать процессоры с контроллером памяти, снижающим латентность доступа к памяти, и без оного, но при этом в пределах одного семейства почти не реагировать на частоту процессора, показывая сходные результаты при работе на частоте 2500 и 3000 МГц. Часто такие приложения отбраковываются как тесты ЦП, ибо тестеру просто непонятно, что лимитирует их производительность, и кажется, что дело в «чудачествах» самой программы. Будет удивительно, если все процессоры (и AMD, и Intel) покажут в тесте одинаковый результат, но такое вполне возможно для приложения, очень сильно зависимого от памяти.

Чтобы избежать упреков в необъективности и вопросов, почему выбрана та или иная программа, в тесты стараются включать только наиболее популярные приложения, которыми все пользуются. Но такая выборка не совсем репрезентативна: наиболее популярные приложения из-за своей массовости часто очень хорошо оптимизированы, а оптимизация программы начинается с оптимизации её работы с памятью - она важнее, например, чем оптимизация под SSE1-2-3-4. Но совсем не все на свете программы так хорошо оптимизируются; попросту на все программы не хватит программистов, которые умеют писать быстрый код. Опять возвращаясь к популярным программам кодирования, многие из них были написаны при непосредственном активном участии инженеров фирм-изготовителей ЦП. Как и некоторые другие популярные ресурсоемкие программы, в частности медленные фильтры двухмерных графических редакторов и движки рендеринга студий трехмерного моделирования.

В свое время было популярно сравнивать компьютерные программы с дорогами. Эта аналогия потребовалась, чтобы объяснить, почему на некоторых программах быстрее работает Pentium 4, а на некоторых Athlon. Интеловский процессор не любил ветвления и быстрее «ехал» по прямым дорогам. Это очень упрощенная аналогия, но она удивительно хорошо передает суть. Особенно интересно, когда две точки на карте соединяют две дороги - «оптимизированная» прямая качественная дорога и «неоптимизированная» кривая ухабистая. В зависимости от выбора одной из дорог, ведущих к цели, выигрывает тот или иной процессор, хотя в каждом случае они делают одно и тоже. То есть на неоптимизированном коде выигрывает Athlon, а при простой оптимизации приложения выигрывает Pentium 4 - и сейчас мы даже не говорим о специальной оптимизации под архитектуру Netburst: в таком случае Pentium 4 мог бы посоревноваться даже с Сore. Другое дело, что хорошие «оптимизированные» дороги строить дорого и долго, и это обстоятельство во многом предопределило печальную участь Netburst.

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

Специальный тест памяти

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

Какие плюсы есть у такого подхода? Их очень много. В отличие от «натуральных» программ, возможен контроль над объемом используемой памяти, контроль над её распределением, контроль над количеством потоков. Специальное контролируемое выделение памяти позволяет нивелировать влияние особенностей менеджера памяти программы и операционной системы на производительность, чтобы результаты были не зашумлены, и можно было корректно и быстро тестировать. Точность измерения позволяет производить тест за относительно небольшое время и оценить большее количество конфигураций.

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

В качестве модельной задачи была взята модификация теста Astar из SPEC CPU 2006 Int (кстати, предложенный для включения в этот пакет автором статьи; для теста памяти использован адаптированный для графов алгоритм) и задача сортировки данных с помощью различных алгоритмов. Программа Astar имеет сложный алгоритм с комплексным доступом к памяти, а алгоритмы сортировки числового массива - базовая задача программирования, использующаяся во множестве приложений; она включена, в том числе, для дополнительного подтверждения результатов сложного теста данными производительности простой, но распространенной и классической задачи.

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

Согласно исследованиям набора тестов SPEC CPU 2006, тест Astar - один из нескольких, в наибольшей мере коррелирующих с общим результатом пакета на x86-совместимых процессорах. Но в нашем тесте памяти объем используемых программой данных был увеличен, так как со времени выпуска теста SPEC CPU 2006 типичный объем памяти возрос. Также программа приобрела внутреннюю многопоточность.

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

Программа осуществляет операции с графом, соединяющим пункты карты. То есть каждый элемент содержит ссылки на соседние, они как бы соединены дорогами. Есть два подтеста: в одном граф строится на основе двухмерной матрицы, то есть плоской карты, а во втором - на основе трехмерной матрицы, которая представляет собой некий сложный массив данных. Структура данных аналогична так называемым спискам - популярному способу организации данных в программах с динамическим созданием объектов. Такой тип адресации в целом характерен для объектно-ориентированного ПО. В частности, это практически все финансовые, бухгалтерские, экспертные приложения. И характер их обращений к памяти разительно контрастирует с типом доступа у оптимизированных на низком уровне вычислительных программ, вроде программ видеокодирования.

Каждый из подтестов имеет два варианта реализации многопоточности. В каждом из вариантов запускается N потоков, но в одном каждая из нитей осуществляет поиск пути на собственной карте, а в другом все нити ищут пути одновременно на одной карте. Так получаются несколько различных шаблонов доступа, что делает тест более показательным. Объем используемой памяти по умолчанию в обоих вариантах одинаков.

Таким образом, в первой версии теста получается 6 подтестов:

• Поиск пути на 2D-матрице, общая карта
• Поиск пути на 2D-матрице, отдельная карта для каждого потока
• Поиск пути на 3D-матрице, общая карта
• Поиск пути на 3D-матрице, отдельная карта для каждого потока
• Сортировка массива с использованием алгоритма quicksort (локальный доступ к памяти)
• Сортировка массива с использованием алгоритма heapsort (сложный доступ к памяти)

Результаты теста

Результаты теста отражают время нахождения заданного количества путей и время сортировки массива, то есть меньшее значение соответствует лучшему результату. В первую очередь качественно оценивается: реагирует ли в принципе данный процессор на заданной частоте на изменение частоты памяти или её настройки, частоту шины, тайминги и т. п. То есть отличаются ли результаты теста на данной системе при использовании различных типов памяти, или процессору хватает минимальной скорости.

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

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

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

Заключение

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

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

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

Многие пользователи задаются вопросом, что в наибольшей степени влияет на производительность компьютера?

Оказывается, однозначного ответа на этот вопрос дать нельзя. Компьютер – это набор подсистем (памяти, вычислительная, графическая, хранения), взаимодействующих друг с другом через материнскую плату и драйверы устройств. При неправильной настройке подсистем они не обеспечивают максимальную производительность, которую могли бы выдать.

Комплексная производительность складывается из программных и аппаратных настроек и особенностей.
Перечислим их.

Аппаратные факторы производительности:

1. Количество ядер процессора – 1, 2, 3 или 4
2. Частота процессора и частота системной шины (FSB) процессора – 533, 667, 800, 1066, 1333 или 1600 МГц
3. Объем и количество кэш-памяти процессора (CPU) – 256, 512 Кбайт; 1, 2, 3, 4, 6, 12 Мбайт.
4. Совпадение частоты системной шины CPU и материнской платы
5. Частота оперативной памяти (RAM) и частота шины памяти материнской платы – DDR2-667, 800, 1066
6. Объем оперативной памяти – 512 и более Мбайт
7. Используемый на материнской плате чипсет (Intel, VIA, SIS, nVidia, ATI/AMD)
8. Используемая графическая подсистема – встроенная в материнскую плату или дискретная (внешняя видеокарта со своей видеопамятью и графическим процессором)
9. Тип интерфейса винчестера (HDD) – параллельный IDE или последовательные SATA и SATA-2
10. Кэш винчестера – 8, 16 или 32 МБ.

Увеличение перечисленных технических характеристик всегда увеличивает производительность.

Ядра

На данный момент большинство выпускаемые процессоров имеют как минимум 2 ядра (кроме AMD Sempron, Athlon 64 и Intel Celeron D, Celeron 4xx). Количество ядер актуально в задачах 3D-рендеринга или кодирования видео, а также в программах, код которых оптимизирован под многопоточность нескольких ядер. В остальных случаях (например, в офисных и интернет-задачах) они бесполезны.

Четыре ядра имеют процессоры Intel Core 2 Extreme и Core 2 Quad со следующими маркировками: QX9xxx, Q9xxx, Q8xxx, QX6xxx;
AMD Phenom X3 – 3 ядра;
AMD Phenom X4 – 4 ядра.

Надо помнить, что количество ядер значительно увеличивает энергопотребление CPU и повышает требования по питанию к материнской плате и блоку питания!

А вот поколение и архитектура ядра сильно влияют на производительность любого процессора.
К примеру, если взять двухядерные Intel Pentium D и Core 2 Duo с одинаковой частой, системной шиной и кэш-памятью, то Core 2 Duo несомненно выиграет.

Частоты процессора, памяти и шин материнской платы

Также очень важно, чтобы совпадение частот различных комплектующих.
Скажем, если ваша материнская плата поддерживает частоту шины памяти 800 МГц, а установлен модуль памяти DDR2-677, то частота модуля памяти будет снижать производительность.

В то же время, если материнская плата не поддерживает частоту 800 МГц, а в то время как установлен модуль DDR2-800, то он работать будет, но на меньшей частоте.

Кэши

Кэш памяти процессора в первую очередь сказывается при работе с CAD-системами, большими базами данных и графикой. Кэш - это память с большей скоростью доступа, предназначенная для ускорения обращения к данным, содержащимся постоянно в памяти с меньшей скоростью доступа (далее «основная память»). Кэширование применяется ЦПУ, жёсткими дисками, браузерами и веб-серверами.

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

Все CPU отличаются количеством кэшей (до 3) и их объемом. Самый быстрый кэш – первого уровня (L1), самый медленный – третьего (L3). Кэш L3 имеют только процессоры AMD Phenom Так что очень важно, чтобы именно кэш L1 имел большой объем.

Мы протестировали зависимость производительности от объема кэш-памяти. Если вы сравните результаты 3D-шутеров Prey и Quake 4, являющих типичными игровыми приложениями, разница в производительности между 1 и 4 Мбайт примерно такова, как между процессорами с разницей по частоте 200 МГц. То же самое касается тестов кодирования видео для кодеков DivX 6.6 и XviD 1.1.2, а также архиватора WinRAR 3.7. Однако, такие интенсивно нагружающие CPU приложения, как 3DStudio Max 8, Lame MP3 Encoder или H.264 Encoder V2 от MainConcept не слишком сильно выигрывают от увеличения размера кэша.
Напомним, что кэш L2 гораздо больше влияет на производительность CPU Intel Core 2, чем AMD Athlon 64 X2 или Phenom, так как у Intel кэш L2 общий для всех ядер, а у AMD отдельный для каждого ядра! В этом плане, Phenom оптимальнее работают с кэшем.

Оперативная память

Как уже было сказано, оперативная память характеризуется частотой и объемом. В то же время сейчас выпускается 2 типа памяти DDR2 и DDR3, которые различаются архитектурной, производительностью, частотой и напряжением питания – то есть всем!
Частота модуля памяти должна совпадать с частотой самого модуля.

Объем оперативной памяти также влияет на производительность операционной системы и на ресурсоемкие приложения.
Расчеты просты – ОС Windows XP занимает в оперативной памяти после загрузки 300-350 МБ. Если в автозагрузке находятся дополнительные программы, то они также загружают RAM. То есть свободных остается 150-200 МБ. Туда могут поместиться только легкие офисные приложения.
Для комфортной работы с AutoCAD, графическими приложениями, 3DMax, кодированием и графикой требуется не менее 1 ГБ оперативной памяти. Если же используется Windows Vista – то не менее 2 ГБ.

Графическая подсистема

Часто в офисных компьютерах используются матерински платы, имеющие встроенную графику. Материнские платы на таких чипсетах (G31, G45, AMD 770G и т.д.) имеют букву G в маркировке.
Такие встроенные видеокарты используются часть RAM для видеопамяти, тем самым уменьшая объем доступного для пользователя пространства RAM.

Соответственно, для увеличения производительности встроенную видеокарту надо отключать в BIOS материнской платы, а в слот PCI-Express устанавливать внешнюю (дискретную) видеокарту.
Все видеокарты различаются графическим чипсетом, частотой работы его конвейеров, количеством конвейеров, частотой видеопамяти, разрядностью шины видеопамяти.

Подсистема накопителей

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

Из технических характеристик, влияющих на скорость доступа к файлам надо отметить Тип интерфейса винчестера (HDD) – параллельный IDE или последовательные SATA и SATA-2 и кэш винчестера – 8, 16 или 32 МБ.
На данный момент рекомендуется устанавливать винчестеры только с интерфейсом SATA-2, имеющим наибольшую пропускную способность и с наибольшим кэшем.

Программные факторы производительности:

1. Количество установленных программ
2. Фрагментация файловой системы
3. Ошибки файловой системы, bad-секторы
4. Фрагментация реестра ОС
5. Ошибки реестра ОС
6. Размер файла подкачки (объем виртуальной памяти)
7. Включенные элементы визуализации графического интерфейса ОС
8. Программы и службы Windows, загружающие в автозагрузке

Это далеко не полный список, но именно эти особенности ОС Windows могут сильно тормозить её работу.
Но об этих характеристиках, настройках и параметрах мы поговорим в следующей статье.

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

В то время, как при производстве накопителей используется множество других метрик, чтоб описать и гарантировать должную производительность, на рынке систем хранения и дисковых накопителей, принято использовать IOPS, как сравнительную метрику, с целью «удобства» сравнения. Однако производительность систем хранения, измеряемая в IOPS (Input Output Operations per Second), операциях ввода / вывода (записи / чтения), подвержена влиянию большого множества факторов.

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

Начнем с того, что IOPS вовсе не IOPS и даже совсем не IOPS, так как существует множество переменных, которые определяют сколько IOPS мы получим в одних и других случаях. Также следует принять во внимание, что системы хранения используют функции чтения и записи и обеспечивают различное количество IOPS для этих функций в зависимости от архитектуры и типа приложения, в особенности в случаях, когда операции ввода / вывода происходят в одно и тоже время. Различные рабочие нагрузки предъявляют различные требования к операциям ввода / вывода (I/O). Таким образом, системы хранения, которые на первый взгляд должны были бы обеспечивать должную производительность, в действительности могут не справится с поставленной задачей.

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

Для того, чтоб приобрести полноценное понимание в вопросе, начнем с основ. IOPS, пропускная способность (MB/s или MiB/s) и время отклика в миллисекундах (мс) являются общепринятыми единицами измерения производительности накопителей и массивов из них.

IOPS обычно рассматривают в ключе измерения способности устройства хранения производить чтение / запись блоками размером 4-8КБ в случайном порядке. Что типично для задач онлайн-обработки транзакций, баз данных и для запуска различных приложений.

Понятие пропускной способности накопителя обычно же применимо при чтении / записи крупного файла, к примеру, блоками 64КБ и более, последовательно (в 1 поток, 1 файл).

Время отклика - время, которое необходимо накопителю для того, чтоб начать производить операцию записи / чтения.

Преобразование между IOPS и пропускной способностью может быть выполнено следующим образом:

IOPS = пропускная способность / размер блока;
Пропускная способность = IOPS * размер блока,

Где размер блока - количество информации, переданное на протяжении одной операции ввода / вывода (I/O). Таким образом, зная такую характеристику жесткого диска (HDD SATA), как пропускную способность - мы с легкостью можем вычислить количество IOPS.

К примеру, возьмем стандартный размер блока - 4КБ и стандартную пропускную способность, заявленную производителем для последовательной записи или чтения (I/O) - 121 Мбайт / с. IOPS = 121 МБ / 4 КБ, в результате чего получим значение порядка 30 000 IOPS для нашего жесткого диска SATA . Если же размер блока увеличить и сделать равным 8 КБ, значение будет порядка 15 000 IOPS, то есть снизится практически пропорционально увеличению размера блока. Однако нужно четко понимать, что тут мы рассматривали IOPS в ключе последовательной записи или чтения.

Все меняется драматическим образом для традиционных жестких SATA дисков, если чтение и запись будут случайными. Тут начинает играть роль задержка (latency), которая очень критична в случае жестких дисков HDD s (Hard Disk Drives) SATA / SAS, а порой даже и в случае твердотельных накопителей SSD (Solid State Drive). Хотя последние зачастую обеспечивают производительность на порядки лучшую, чем у «вращающихся» накопителей, за счет отсутствия движущихся элементов, но все же могут возникать ощутимые задержки при записи, в виду особенностей технологии, и, как следствие, при использовании их в массивах. Глубокоуважаемый amarao провел довольно полезное исследование по использованию твердотельных накопителей в массивах, как выяснилось, производительность будет зависеть от latency самого медленного из дисков. Более подробно с результатами Вы можете ознакомиться в его статье: SSD + raid0 - не всё так просто .

Но вернемся к производительности отдельно взятых накопителей. Рассмотрим случай с «вращающимися» накопителями. Время, требуемое для выполнения одной случайной операции ввода / вывода будет определятся такими составляющими:

T(I/O) = T(A)+T(L)+T(R/W),

Где T(A) - время доступа (access time или seek time), также известное, как время поиска, то есть время, требуемое для того, чтоб считывающая головка, была помещена на дорожку с нужным нам блоком информации. Зачастую в спецификации диска производителем указываются 3 параметра:

Время, требуемое, чтоб переместиться с самой дальней дорожке к самой ближней;
- время, требуемое для перемещения между смежными дорожками;
- среднее время доступа.

Таким образом мы приходим к волшебному выводу, что показатель T(A) может быть улучшен, если мы размещаем наши данные на как можно более близких дорожках, а все данные располагаются как можно дальше от центра пластины (требуется меньше времени для перемещения блока магнитных головок, а на внешних дорожках данных больше, так как больше длина дорожки и она вращается быстрее, нежели внутренняя). Теперь становится понятно почему дефрагментация может быть так полезна. Особенно с условием размещения данных на внешних дорожках в первую очередь.

T(L) - задержка, вызванная вращением диска, то есть время, требуемое для того, чтоб считать или записать конкретный сектор на нашей дорожке. Легко понять, что оно будет лежать в пределах от 0 до 1/RPS, где RPS - количество оборотов в секунду. К примеру при характеристике диска в 7200 RPM (оборотов в минуту) мы получим 7200/60 = 120 оборотов в секунду. То есть один оборот происходит за (1/120) * 1000 (количество миллисекунд в секунде) = 8,33 мс. Средняя же задержка в этом случае, будет равна половине времени, затрачиваемому на один оборот - 8,33/2 = 4,16 мс.

T(R/W) - время чтения или записи сектора, которое определяется размером выбранного при форматировании блока (от 512 байт и до… нескольких мегабайт, в случае с более емкими накопителями - от 4 килобайт, стандартный размер кластера) и пропускной способностью, которая указана в характеристиках накопителя.

Среднюю задержку вращения, которая приблизительно равна времени, затраченному на половину оборота, зная скорость вращения 7200, 10 000 или 15 000 RPM, легко определить. И выше мы уже показали как.

Остальные же параметры (среднее время поиска чтения и записи) определить сложнее, они определяются уже в результате тестов и указываются производителем.

Для расчета количества случайных IOPs жесткого диска возможно применить следующую формулу, при условии когда количество одновременных операций чтения и записи одинаково (50%/50%):

1/(((среднее время поиска чтения + среднее время поиска записи) / 2) / 1000) + (средняя задержка вращения / 1000)).

Многие интересуются, почему именно такое происхождение формулы? IOPS - количество операций ввода или вывода в секунду. Именно потому мы делим в числителе 1 секунду (1000 миллисекунд) на время с учетом всех задержек в знаменателе (выраженное также в секундах или миллисекундах), требуемое для осуществления одной операции ввода или вывода.

То есть формула может быть записана и таким образом:

1000 (мс) / ((среднее время поиска чтения (мс) + среднее время поиска записи (мс)) /2) + средняя задержка вращения (мс))

Для накопителей с различным количеством RPM (вращений в минуту), мы получим следующие значения:

Для 7200 RPM накопителя IOPS = 1/(((8,5+9,5)/2)/1000) + (4,16/1000)) = 1/((9/1000) +
(4,16/1000)) = 1000/13,16 = 75,98;
Для 10K RPM SAS накопителя IOPS = 1/(((3,8+4,4)/2)/1000) + (2,98/1000)) =
1/((4,10/1000) + (2,98/1000)) = 1000/7,08 = 141,24;
Для 15K RPM SAS накопителя IOPS = 1/(((3,48+3,9)/2)/1000) + (2,00/1000)) =
1/((3,65/1000) + (2/1000)) = 1000/5,65 = 176,99.

Таким образом мы видим драматические изменения, когда с десятков тысяч IOPS при последовательном чтении или записи, производительность падает до нескольких десятков IOPS.

И уже, при стандартном размере сектора в 4КБ, и наличию столь малого числа IOPS, мы получим значение пропускной способности отнюдь не в сотню мегабайт, а менее, чем в мегабайт.

Эти примеры также иллюстрируют причину незначительных изменений в номинальных дисковых IOPS от разных производителей для дисков с одним и тем же показателем RPM.

Теперь становится понятным, почему данные производительности, лежат в довольно широких диапазонах:

7200 RPM (Rotate per Minute) HDD SATA - 50-75 IOPS;
10K RPM HDD SAS - 110-140 IOPS;
15K RPM HDD SAS - 150-200 IOPS;
SSD (Solid State Drive) - десятки тысяч IOPS на чтение, сотни и тысячи на запись.

Однако номинальный дисковый IOPS остается все же далеко неточными, так как не учитывает различий в характере нагрузок в отдельно взятых случаях, что очень важно понимать.

Также, для лучшего понимания темы, рекомендую ознакомиться еще с одной полезной статьей от amarao : Как правильно мерять производительность диска , благодаря которой становиться также понятным, что latency вполне не фиксирована и также зависит от нагрузки и ее характера.

Единственное, хотелось бы добавить:

При расчете производительности жесткого диска можно пренебречь снижением количества IOPS при увеличении размера блока, почему?

Мы уже поняли, что для «вращающихся» накопителей, время, требуемое для случайного чтения или записи, складывается из следующих компонент:

T(I/O) = T(A)+T(L)+T(R/W).

И далее даже рассчитали производительность при случайном чтении и записи в IOPS. Вот только параметром T(R/W) мы там по сути пренебрегли, и это не случайно. Мы знаем, что допустим, последовательное чтение может быть обеспечено на скорости в 120 мегабайт в секунду. Становится понятным, что блок в 4КБ, будет считан за примерно 0,03 мс, время на два порядка меньшее, нежели время остальных задержек (8 мс + 4 мс).

Таким образом, если при размере блока в 4КБ мы имеем 76 IOPS (основная задержка была вызвана вращением накопителя и временем позиционирования головки, а не самим процессом чтения или записи), то при размере блока в 64КБ, падение IOPS будет не в 16 раз, как при последовательном чтении, а лишь на несколько IOPS . Так как время, затрачиваемое на непосредственно чтение или запись, возрастет на 0,45 мс, что составляет лишь порядка 4% от общего времени задержки.

В результате мы получим 76-4% = 72,96 IOPS, что согласитесь, совсем не критично при расчетах, так как падение IOPS не в 16 раз, а лишь на несколько процентов! И при расчетах производительности систем куда важнее не забыть учесть другие важные параметры.

Волшебный вывод: при расчете производительности систем хранения, основанных на жестких дисках, следует подбирать оптимальный размер блока (кластера), для обеспечения нужной нам максимальной пропускной способности в зависимости от типа данных и используемых приложений, причем падением IOPS при увеличении размера блока с 4КБ до 64КБ или даже 128КБ можно пренебречь, либо учитывать, как 4 и 7% соответсвенно, если в поставленной задаче они будут играть важную роль.

Также становится понятным, почему не всегда есть смысл использовать очень большие блоки. Скажем, при видеостриминге, двухмегабайтный размер блока может оказаться далеко не самым оптимальным вариантом. Так как падение количества IOPS будет более, чем в 2 раза. Помимо прочего добавятся другие деградационные процессы в массивах, связанные с многопоточностью и вычислительной нагрузкой при распределении данных по массиву.

Оптимальный размер блока (кластера)

Оптимальный размер блока нужно учитывать в зависимости от характера нагрузки и типа используемых приложений. Если идет работа с данными небольшого размера, к примеру с базами данных - следует выбрать стандартные 4 КБ, если же речь идет о стриминге видеофайлов - размер кластера лучше выбирать от 64 КБ и более.

Следует помнить, что размер блока не столь критичен для SSD, сколько для стандартных HDD, так как позволяет обеспечить нужную пропускную способность в виду небольшого количества случайных IOPS, количество которых снижается незначительно при увеличении размера блока, в отличии от SSD, где наблюдается практически пропорциональная зависимость.

Почему стандарт 4 КБ?

Для многих накопителей, в особенности твердотельных, значения производительности, к примеру записи, начиная с 4 КБ, становятся оптимальными, это видно из графика:

В то время, как на чтение, скорость также довольно существенна и более менее сносна начиная с 4 КБ:

Именно по этой причине 4 КБ размер блока очень часто применяют за стандартный, так как при меньшем размере идут большие потери производительности, а при увеличении размера блока, в случае работы с небольшими данными, данные будут распределены менее эффективно, занимать весь размер блока и квота накопителя будет использоваться не эффективно.

Уровень RAID

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

Так, при RAID0, на каждую операцию ввода будет расходоваться лишь 1 IOPS, ведь данные будут распределены по всем накопителям без дублирования. В случае же зеркала (RAID1, RAID10), каждая операция записи будет потреблять уже 2 IOPS, так как информация должна быть записана на 2 накопителя.

В более высоких уровнях RAID потери еще существеннее, к примеру в RAID5 штрафной коэффициент будет уже 4, что связано с тем, каким образом данные распределяются по дисках.

RAID5 используется вместо RAID4 в большинстве случаев, так как распределяет четность (контрольные суммы) по всем дискам. В массиве RAID4 один из дисков ответственен за всю четность, в то время как данные распространены более чем на 3 диска. Именно потому мы применяем штрафной коэффициент 4 в массиве RAID5, так как мы читаем данные, читаем четность, затем пишем данные и пишем четность.

В массиве RAID6 все аналогично, за исключением того, что мы вместо вычисления четности единожды, делаем это дважды и таким образом имеем 3 операции чтения и 3 записи, что дает нам уже штрафной коэффициент 6.

Казалось бы, что в таком массиве, как RAID-DP все будет аналогично, так как это по сути модифицированный массив RAID6. Но не тут то было… Хитрость заключается в том, что применяется отдельная файловая система WAFL (Write Anywhere File Layout), где все операции записи последовательны и производятся на свободное место. WAFL в основном напишет новые данные в новое местоположение на диске и затем переместит указатели на новые данные, устраняя таким образом операции чтения, которые должны иметь место. Кроме того идет запись журнала в NVRAM, который отслеживает транзакции записи, инициирует запись и может восстановить их при необходимости. Идет запись в буфер в начале, а затем они уже «сливаются» на диск, что ускоряет процесс. Вероятно эксперты в NetApp могут просветить нас более подробно в комментариях, за счет чего достигается экономия, я пока что еще не до конца разобрался в этом вопросе, но запомнил, что штрафной коэффициент RAID будет всего лишь 2, а не 6. «Хитрость» весьма существенна.

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

Теперь, зная о потерях IOPS в результате применения того либо другого уровня RAID, мы можем рассчитать производительность массива. Однако, пожалуйста, примите к сведению, что другие факторы, такие как пропускная способность интерфейса, неоптимальное распределение прерываний по ядрах процессора и т.п., пропускная способность RAID-контроллера, превышение допустимой глубины очереди - могут оказывать негативное влияние.

В случае пренебрежения этими факторами, формула будет следующей:

Функциональные IOPS = (Исходные IOPS * % операций записи / штрафной коэффициент RAID) + (Исходные IOPS * % чтения), где Исходные IOPS = усредненный IOPS накопителей * количество накопителей.

Рассчитаем для примера производительность массива RAID10 из 12 дисков HDD SATA, если известно, что одновременно происходит 10% операций записи и 90% операций чтения. Допустим, что диск обеспечивает 75 случайных IOPS, при размере блока 4КБ.

Исходные IOPS = 75*12 = 900;
Функциональные IOPS = (900*0,1/2) + (900*0,9) = 855.

Таким образом видим, что при малой интенсивности записи, что в основном наблюдается в системах, рассчитанных на отдачу контента, влияние штрафного коэффициента RAID минимально.

Зависимость от приложений

Производительность нашего решения очень сильно может зависеть от приложений, которые будут исполнятся впоследствии. Так это может быть обработка транзакций - «структурированных» данных, которые организованы, последовательны и предсказуемы. Зачастую в этих процессах можно применить принцип пакетной обработки, распределив эти процессы во времени так, когда нагрузка минимальна, тем самым оптимизировав потребление IOPS. Однако в последнее время появляется все больше и больше медийных проектов, где данные «не структурированы» и требуют совсем иных принципов их обработки.

По этой причине подсчет необходимой производительности решения для конкретного проекта может стать весьма сложной задачей. Некоторые из производителей сторедж-хранилищ и экспертов утверждают, что IOPS не имеют значения, так как клиенты в подавляющем большинстве используют до 30-40 тысяч IOPS, в то время, как современные системы хранения обеспечивают сотни тысяч и даже миллионы IOPS. То есть современные хранилища удовлетворяют нужды 99% клиентов. Тем не менее это утверждение может быть справедливо далеко не всегда, лишь для бизнес-сегмента, который размещает хранилища у себя, локально, но не для проектов, размещаемых в дата-центрах, которые зачастую, даже при использовании готовых решений хранения, должны обеспечивать довольно высокую производительность и отказоустойчивость.

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

Как видим из графика:

Менее, чем 5% систем хранения, настроены с применением блока менее 10 КБ и менее, чем 15% используют блоки с размером менее 20 КБ. Кроме того, даже для определенного приложения, редко когда возникает потребления I/O лишь одного типа. К примеру у базы данных будут различные профили I/O для различных процессов (файлы с данными, логирование, индексы …). А значит, заявленные синтетические тесты производительности систем, могут быть далекими от истины.

А что на счет задержек?

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

Таким образом мы приходим к еще одному волшебному выводу, что не только размер блока является не очень хорошей характеристикой при измерении производительности IOPS систем, но и latency может оказаться вполне бесполезным параметром.

Хорошо, если ни IOPS, ни время ожидания не являются хорошей мерой измерения производительности системы хранения, то что тогда?

Только реальный тест исполнения приложения на конкретном решении…

Этот тест будет тем реальным методом, который наверняка позволит понять, насколько производительным будет решение для Вашего случая. Для этого понадобится запустить копию приложения на отдельно взятом хранилище и симулировать нагрузку за определенный период. Только так можно получить достоверные данные. И разумеется, нужно измерять не метрики хранилища, а метрики приложения.

Тем не менее учет приведенных выше факторов, влияющих на производительность наших систем, может быть весьма полезным при подборе хранилища или построении определенной инфраструктуры на основе выделенных серверов. С определенной степенью консерватизма становится возможным подобрать более-менее реальное решение, исключить некоторые технические и программные изъяны в виде не оптимального размера блока при разбивке или не оптимальной работы с дисками. Решение, конечно, не будет на 100% гарантировать расчетную производительность, но в 99% случаев можно будет говорить, что решение справится с нагрузкой, особенно, если добавлять консерватизм в зависимости от типа приложения и его особенностей в расчет.

Презентацию к лекции Вы можете скачать .

Упрощенная модель процессора

Дополнительная информация:

Прототипом схемы служит отчасти описание архитектуры фон Неймана, которая имеет следующие принципы:

1. Принцип двоичности
2. Принцип программного управления
3. Принцип однородности памяти
4. Принцип адресуемости памяти
5. Принцип последовательного программного управления
6. Принцип условного перехода

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

Упрощенная модель процессора

• устройство управления ( Control Unit , CU)
• арифметико-логическое устройство ( Arithmetic and Logic Unit , ALU )
• системные регистры
• системная шина (Front Side Bus, FSB )
• память
• периферийные устройства

Устройство управления (CU):

• выполняет дешифрацию инструкций, поступающих из памяти компьютера.
• управляет ALU .
• осуществляет пересылку данных между регистрами ЦП, памятью, периферийными устройствами.

Арифметико-логическое устройство:

• позволяет производить арифметические и логические операции над системными регистрами.

Системные регистры:

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

Системная шина:

• используется для пересылки данных между ЦП и памятью, а также между ЦП и периферийными устройствами.

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

Высокая производительность МП (микропроцессора)– один из ключевых факторов в конкурентной борьбе производителей процессоров.

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

Очень условно:

Производительность = Кол-во инструкций / Время

Мы будем рассматривать производительность процессоров на базе архитектур IA32 и IA32e. (IA32 with EM64T ).

Факторы влияющие на производительность процессора:

• Тактовая частота процессора.
• Объем адресуемой памяти и скорость доступа к внешней памяти.
• Скорость выполнения и набор инструкций.
• Использование внутренней памяти, регистров.
• Качество конвейеризации .
• Качество упреждающей выборки.
• Суперскалярность .
• Наличие векторных инструкций.
• Многоядерность.

Что такое производительность ? Сложно дать однозначное определение производительности. Можно формально привязать его к процессору – сколько, инструкций за единицу времени может выполнять тот или иной процессор . Но проще дать сравнительное определение – взять два процессора и тот, который выполняет некий набор инструкций быстрее, тот более производительный. То есть, очень условно, можно сказать, что производительность – это количество инструкций на время выполнения . Мы здесь в основном будем исследовать те микропроцессорные архитектуры, которые выпускает Intel, то есть архитектуры IA32, которые сейчас называются Intel 64. Это архитектуры, которые с одной стороны поддерживает старые инструкции из набора IA32, с другой стороны имеют EM64T – это некое расширение, которое позволяет использовать 64 битные адреса, т.е. адресовать большие размеры памяти, а также включает в себя какие-то полезные дополнения, типа увеличенного количества системных регистров, увеличенное количество векторных регистров.

Какие факторы влияют на производительность ? Перечислим все, которые приходят в голову. Это:

• Скорость выполнения инструкций, полнота базового набора инструкций.
• Использование внутренней памяти регистров.
• Качество конвейеризации .
• Качество предсказания переходов.
• Качество упреждающей выборки.
• Суперскалярность .
• Векторизация , использование векторных инструкций.
• Параллелизация и многоядерность.

Тактовая частота

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

Объем адресуемой памяти

Тактовая частота.

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

Объем адресуемой памяти и скорость доступа к памяти.

Объем памяти - необходимо, чтобы памяти хватало для нашей программы и наших данных. То есть, технология EM64T позволяет адресовать огромное количество памяти и на данный момент вопрос с тем, что нам не хватает адресуемой памяти не стоит.

Поскольку на эти факторы разработчики в общем случае не имеют возможности влиять, то я только упоминаю о них.

Скорость выполнения и набор инструкций

Производительность зависит от того, насколько качественно реализованы инструкции, насколько полно базовый набор инструкций покрывает все возможные задачи.

CISC,RISC (complex, reduced instruction set computing)

Современные процессоры Intel® представляют собой гибрид CISC и RISC процессоров, перед исполнением преобразуют CISC инструкции в более простой набор RISC инструкций.

Скорость выполнения инструкций и полнота базового набора инструкций.

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

Использование регистров и оперативной памяти

Время доступа к регистрам наименьшее, поэтому кол-во доступных регистров влияет на производительность микропроцессора.

Вытеснение регистров ( register spilling ) – из-за недостаточного кол-ва регистров велик обмен между регистрами и стеком приложения.

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

Существуют две характеристики для описания свойств памяти:

• Время отклика ( latency ) – число циклов процессора необходимых для передачи единицы данных из памяти.
• Пропускная способность ( bandwidth ) – количество элементов данных которые могут быть отправлены процессору из памяти за один цикл.

Две возможные стратегии для ускорения быстродействия– уменьшение времени отклика или упреждающий запрос нужной памяти.

Использование регистров и оперативной памяти.

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

Следующая часть памяти – это обычная оперативная память . С ростом производительности процессоров стало ясно, что самым узким местом производительности является доступ к оперативной памяти. Для того, чтобы добраться до оперативной памяти, нужны сотня, а то и две сотни тактов процессора. То есть, запросив какую-то ячейку памяти в оперативной памяти, мы будем ждать двести тактов, а процессор будет простаивать.

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

Кэширование

Кэш-память служит для уменьшения времени доступа к данным.

Для этого блоки оперативной памяти отображаются в более быструю кэш-память.

Если адрес памяти находится в кэше – происходит "попадание" и скорость получения данных значительно увеличивается.

В противном случае – "промах" (cache miss)

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

Можно выделить следующие виды кэш-памяти:

• полностью ассоциативная кэш-память (каждый блок может отображаться в любое место кэша)
• память с прямым отображением (каждый блок может отображаться в одно место)
• гибридные варианты (секторная память, память с множественно-ассоциативным доступом)

Множественно-ассоциативный доступ – по младшим разрядам определяется строка кэша, куда может отображаться данная память, но в этой строке может находиться только несколько слов основной памяти, выбор из которых проводится на ассоциативной основе.

Качество использования кэша – ключевое условие быстродействия.

Дополнительная информация: в современных IA32 системах размер кэш-линии 64 байта.

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

Существуют разные реализации кэш -памяти. Бывает полностью ассоциативная кэш - память , когда каждый блок может отображаться в любое место кэша. Существует память с прямым отображением, когда каждый блок может отображаться в одно место , также существуют различные гибридные варианты – например кэш с множественно-ассоциативным доступом. В чем разница? Разница во времени и сложности проверки на наличие нужного адреса в кэш -памяти. Предположим, что нам нужен определенный адрес . В случае с ассоциативной памятью нам нужно проверить весь кэш – убедиться, что этого адреса в кэше нет. В случае с прямым отображением нам нужно проверить только одну ячейку. В случае с гибридными вариантами, например, когда используется кэш с множественно-ассоциативным доступом, нам нужно проверить, к примеру, четыре или восемь ячеек. То есть, задача определить есть ли адрес кэша – тоже важна. Качество использования кэша – важное условие быстродействия. Если нам удастся написать программу так, чтобы как можно чаще те данные, с которыми мы собирались работать, находились в кэше, то такая программа будет работать гораздо быстрее.

Характерные времена отклика при обращении к кэш памяти для Nehalem i7:

• L1 - latency 4
• L2 - latency 11
• L3 - latency 38

Время отклика для оперативной памяти > 100

Упреждающий механизм доступа к памяти реализован при помощи механизма упреждающей выборки (hardware prefetching ).

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

Для примера возьмем наш последний процессор Nehalem: i7.

Здесь мы имеем не просто кэш , а некий иерархический кэш . Долгое время он был двухуровневый, в современной системе Nehalem он трехуровневый – совсем немного очень быстрого кэша, чуть побольше кэша второго уровня и достаточно большое количество кэша третьего уровня. При этом, эта система построена так, что если какой-то адрес находится в кэше первого уровня, он автоматически находится во втором и в третьем уровнях. Это и есть иерархическая система. Для кэша первого уровня задержка – 4 такта, для второго – 11, третьего – 38 и время отклика оперативной памяти – больше 100 тактов процессора.