Представляємо IOMeter від Intel
Раніше з усіх синтетичних тестів ми воліли ThreadMark 2.0. Однак, досить скоро ми помітили, що простежується певна взаємозв'язок між результатами в ThreadMark і швидкістю передачі послідовних даних, вимірюваної тестом WinBench. Ніде це не виявлялося так явно як при тестуванні ThreadMark'ом продуктивності конфігурацій RAID 0 (на відміну від дуже незначного приросту в WinBench) і при тестуванні з жорсткими дисками сімейства Quantum Bigfoot, які хоча і славляться своєю повільністю, але все ж демонструють більш-менш прийнятну швидкість передачі послідовних даних. Ми вже давно подумували про те, щоб відмовитися від використання цього тесту. Проте кожного разу, коли ми обережно натякали на наше рішення, ми отримували гору листів, в яких користувачі благали нас не відмовлятися від цього тесту, оскільки він, нібито, дуже точно відображав дійсність. Останньою краплею, що переповнила чашу нашого терпіння, стала вельми несподівана реакція самих розробників ThreadMark, представників компанії Adaptec: їх помітно розвеселив той факт, що ми використовували ThreadMark в якості повноцінного бенчмарка для наших досліджень. Рада, що ми отримали від них, ще раз підтверджує. Що ми з самого початку були на правильному шляху: фахівці з компанії Adaptec порекомендували нам скористатися IOMeter від Intel.
Хоча інтерфейс IOMeter далеко не найзручніший, цю утиліту безумовно відрізняє виняткова гнучкість у використанні. На відміну від WinBench 99, який використовує реальні програми, IOMeter працює в чисто синтетичному середовищі. Однак саме синтетична природа цього тесту обумовлює його гнучкість і зручні налаштування на конкретні цілі і завдання.
Можливості, які відкриває перед нами ця програма, виходять далеко за рамки звичайного тестування на одній платформі, до чого ми вже звикли тут, на StorageReview. Ця утиліта дозволяє тестувати багатопроцесорні конфігурації, так само як і конфігурації з декількома жорсткими дисками і навіть мережі з декількох укомплектованих систем. У цій статті ми зупинимося на тестуванні індивідуальної системи, побудованої на одному жорсткому диску.
IOMeter може створювати кілька робочих програм (Intel рекомендує використовувати одну програму для тестування системи з одним процесором). Кожна програма працює або з неразбітие на розділи "фізичним диском", або з розділом (ами) в межах одного диска. Також, кожній програмі приписується певна "модель доступу", що представляє собою набір параметрів, які обумовлюють доступ програми до тестованого елементу.
Змінні, що становлять модель доступу, включають:
Розмір запиту на передачу даних. Це мінімальна одиниця, з якої працює програма. Оскільки дані передаються послідовно, це значення буде подвоюватися, потроюватися, і т.п.
Випадкове / послідовний розподіл (в%). Ця змінна означає, який відсоток запитів носить випадковий характер. Якщо запит не випадковий, то, відповідно, він відноситься до розряду послідовних.
І нарешті останній параметр, про який хотілося б сказати кілька слів, це кількість окремих операцій введення / виводу. тобто такий параметр, який може бути приписаний кожній робочій програмі, що тим самим дозволить моделювати унікальну навантаження на тестований елемент в кожному конкретному случае.Что, заплуталися? Дійсно, все це дещо складно пояснити на пальцях. Але, повірте, сама програма зовсім не така складна, як може здатися. Однак один факт напевно сумнівів не викликає. З огляду на виняткову настраиваемость утиліти мимоволі постає питання: що ж показує насправді модель доступу і навантаження?
Спробуємо оцінити продуктивність різних жорстких дисків в умовах роботи в серверах і робочих станціях. Перший випадок досить простий для реалізації, оскільки IOMeter комплектується вже складеної моделлю звернення до даних. Що ж стосується другого пункту, робочих станцій, то тут, як це не дивно, ні Intel, ні виробники жорстких дисків, до яких ми зверталися, не погодилися надати необхідні дані для моделювання цих умов тестування.
Загалом, цілком очевидно, що в разі робочої станції переважає випадкове (чи не послідовність) звернення до даних (саме тому ThreadMark і був відкинутий, як тест). Навіть результати, отримані в WinBench, підтверджують цю думку. Питання: наскільки великий повинен бути відсоток випадкових звернень?
Хоча спочатку завантаження exe-файлів, DLL і інших бібліотек являє собою послідовний процес, всі наступні звернення носять випадковий характер. Навіть незважаючи на те, що файли можуть бути досить великого розміру, частини файлів постійно посилаються в файл підкачки (swapfile) і вилучаються з нього. Сильно фрагментовані звернення до цього файлу випадкові. Exe-файли викликають інші важливі файли з графічними зображеннями, звуком, і т.п. Хоча самі по собі ці файли можуть являти собою великі ланцюжки даних, звернення до яких відбувається послідовно, сукупний відсоток все одно буде менше відсотка випадкових звернень та обміну даними між системними файлами. А якщо ще й врахувати те, що, на жаль, існує таке прикре явище, як фрагментація файлів на вінчестері, то прийнята нами модель здається нам найбільш реалістичною.
Також під питанням і співвідношення операцій читання і запису. У більшості систем в режимах введення / виведення домінують операції читання. Операції запису мають місце в разі установки додатків, під час запису файлів даних, і, що особливо важливо, під час запису файлів підкачки (swapfiles). Тільки в разі запису великих обсягів даних в режимі реального часу (A / V) операції записи можуть стати переважаючими.
StorageReview.com працював з такими моделями доступу:
Патерни IOMeter від StorageReview
% Of Access Specification
64 KB або більше
В основному, модель звернень допускає панування випадкових звернень в 8Кбайтовом кластері так само як і з'являються час від часу послідовні звернення, яким вдається уникнути попадання в файл підкачки (swapfile) і / або природної фрагментації. Модель також передбачає, що в основному будуть мати місце операції читання, тоді як операції запису будуть в більшості своїй доводиться на запис в файл підкачки (swapfile). Це саме та модель, до якої ми звертаємося кожен раз, говорячи про оцінку продуктивності робочої станції за допомогою IOMeter'а.
Модель звернення до бази даних називається саме так ( "Database" Access Pattern), тому що модель встановлена в IOMeter за замовчуванням описується як "модель типової навантаження при роботі з базами даних" за винятком розміру блоків даних (2Кбайта). Звернення до 8Кбайтовим блокам теоретично мають на увазі дуже великі затримки, однак, на практиці, різниця в часі, яке необхідно для передачі 8Кбайт в порівнянні з 2Кбайтамі (при швидкості передачі рівній 20Мбайт в секунду), просто мізерна. Набагато більше часу йде на переміщення приводу вінчестера в потрібне місце на пластині і на зчитування даних з пластини або запис на неї. Незважаючи на те, що ми назвали цю модель саме так, багато хто визнає, що вона найбільш вдало представляє функціонування типової робочої станції саме завдяки тому, що в ній переважають випадкові звернення до даних.
Кількість ізольованих операцій введення / виводу - завантаження IOMeter'а
Деяка кількість ізольованих операцій введення / виводу, що працюють паралельно, безумовно впливають на сукупну завантаження тестованого жорсткого диска. У разі всього одного звернення ми отримуємо лінійну навантаження, яка при 100% випадковості звернень дає нам можливість виміряти середній час випадкового доступу при роботі з моделлю бази даних. Однак такий випадок не можна назвати репрезентативним для всіх видів доступу до даних. Візьмемо, наприклад, 4 звернення, що працюють паралельно. В цьому випадку ми отримуємо модель елементарних операцій, таких, як наприклад, запуск калькулятора в Windows. За допомогою файлу Win2k perfmon.exe ми змогли зафіксувати сплески в інтервалі від 30 до 50 операцій введення / виводу, що працюють паралельно при запуску деяких програм. Сплески понад 100 операцій введення / виводу мають місце в разі підвищеної інтенсивності звернень до жорсткого диска, наприклад, при його дефрагментації.
В результаті, ми вирішили протестувати кожну з трьох перерахованих вище моделей доступу з 5-ма варіантами навантаження:
1 Outstanding I / O
4 Outstanding I / Os
16 Outstanding I / Os
64 Outstanding I / Os
256 Outstanding I / Os
Якщо ніяких відповідних змін параметрів не проводилося, то IOMeter буде працювати до тих пір, поки користувач в ручну не перерве програму. Ми встановили час виконання кожного тесту дорівнює 10 хвилинам. А всього було проведено 15 тестів (3 моделі, по 5 разів для кожної). Зверніть увагу, що перші тридцять секунд кожного тесту відводилися на так званий "розгін" і результати на цьому часовому відрізку не враховувалися. Таким чином ми спробували уникнути істотного розкиду значень і впливу початкових непоказовим результатів на загальну картину.
На виході утиліти IOMeter, ми отримуємо дуже велику кількість всіляких результатів, багато з яких доповнюють один одного і являють собою різні варіанти тестування одних і тих же параметрів. Деякі результати мають сенс тільки для випадків з багатопроцесорними системами або мережами. Ми виділив кілька параметрів, які представляють для нас особливий інтерес:
Загальна кількість операцій введення / виводу в секунду. Це найбільш значущий результат. Він показує скільки звернень було виконано за 1 секунду. Зрозуміло, кожне звернення складається з декількох дій, виконаних послідовно: переміщення приводу, обертання диска, зчитування або запис 8Кбайтового блоку для робочої станції / бази даних або блоку розміром від 0.5 до 64Кбайт в разі моделі сервера.
Загальна кількість переданих мегабайт в секунду. Це не що інше як екстраполяція попереднього параметра. У разі для моделі робочої станції або бази даних значення цього параметра дорівнює: [кількість операцій введення / виводу в секунду] x 8KB / 1024. Для моделі файлового сервера значення виходить трохи складніше через переданого розміру змінної.
Середній час реакції системи на кожну операцію введення / виводу. На лінійному рівні (1 окрема операція) це значення просто інакше відображає кількість операцій введення / виводу в секунду. Простіше кажучи, кількість операцій введення / виводу в секунду це 1000міллісекунд поділені на середній час реакції системи на кожну операцію введення / виводу. З ростом кількості окремих операцій, здійснюваних паралельно, обчислення ускладнюються. Середній час реакції системи на кожну операцію введення / виведення зростає, але не лінійно по відношенню до зростання кількості операцій введення / виводу. Цим ми зобов'язані оптимізації firmware, підтримуваного інтерфейсу / шини, а також оптимізації процедури доступу до диска.
Завантаження процесора. У більшості випадків ми не наводимо це значення в наших базах даних. Це не що інше, як відсоток процесорних тактів, залучених в обробку звернень. Це число дуже невелике для 700МГц процесора. Це число також невелике для 266МГц процесора. У будь-якому випадку, набагато важливіше ...
Кількість операцій вводу / виводу на певний відсоток завантаження процесора. Це так звана "ефективність процесора" по IOMeter'у. Значення виходить в результаті ділення кількості операцій введення / виводу в секунду на коефіцієнт завантаження процесора (що в більшості випадків становить менше 1%, що призводить до зростання продуктивності). Порівняння результатів за цим параметром для декількох дисків є більш правильним, ніж порівняння безпосередньо коефіцієнтів завантаження процесорів.
Що таке Картка покупця
Реєстрація в Клубі постійних покупців надає можливість покупцеві:
Карта діє як при покупці в інтернет, так і в роздрібних магазинах.
Замовлення з доставкою в точки Евросеть / Зв'язковий
- працює тільки для приватних осіб;
- оформляється за роздрібними цінами поточного прайс-листа;
- повинен бути на суму не менше 100 руб і не більше 15 000 руб, в іншому випадку Вам запропонують оплатити додатково вартість страховки Товару (0,8% від вартості Кошики) або скористатися альтернативними способами доставки;
- повинен бути менше 8 кг, включаючи упаковку Товару;
- оплата при отриманні готівкою або пластиковою карткою;
- Сума двох будь-яких сторін посилки не повинна бути більше 1,200 м;
- відправка товару з доставкою в точки Евросеть / Зв'язковий здійснюється щодня, в 12-00, крім вихідних та святкових днів. Якщо Ваше замовлення сформований у вихідні або святкові дні, оператор буде з Вами зв'язуватися не раніше наступного робочого дня;
- термін зберігання замовлення в точці видачі - сім днів.
Купівля за списком артикулів