Показаны сообщения с ярлыком storage. Показать все сообщения
Показаны сообщения с ярлыком storage. Показать все сообщения

понедельник, 8 апреля 2013 г.

Solaris. Смотрим работу multipathing

Частый вопрос - а работает ли у меня multipathing ?
Давайте посмотрим по шагам:
#fcinfo hba-port
тут мы увидим много интересного. Но для справки в основном.

#luxadm -e port
Посмотрим, что устройства в фабрике, состояние у них два - Connected или Not Connected.
Для нас нужно что были CONNECTED хотя бы два.

Я кстати напомню, что если мы имеем дело с массивом Active-Passive, то два пути напрямую в массив от сервера (а обычно все делают так - один кабель в первый контроллер, второй кабель во второй контроллер) - не дает никакой балансировки нагрузки. Массивы этой группы балансируют нагрузку исключительно на одном контроллере только. Далее вы увидите, что ПО Multipath эту ситуацию отслеживает и на пути, что подключены к контроллеру, который не является владельцем тома, трафик направлен не будет без причины (Tresspath, fail). Поэтому правильное подключение либо через коммутаторы либо 4 провода (по два в каждый контроллер).

#luxadm probe -p
Тут мы увидим устройства, что подключены и видны нам по нашим путям. Будет показано дерево. Если в пути физического устройства видим scsi_vhci - это как раз наш пациент, и это значит, что том под управлением драйвера Multipathing. Например:

Found Fibre Channel device(s):
  Node WWN:50060e80103ec920  Device Type:Disk device
    Logical Path:/dev/rdsk/c0t60060E80103EC920057FB7620000000Ad0s2
    Physical Path:
     /devices/scsi_vhci/ssd@g60060e80103ec920057fb7620000000a:c,raw

#luxadm display /dev/rdsk/c0t60060E80103EC920057FB7620000000Ad0s2
устройство взято из примера выше (Logical path).
Вот вывод для массива HDS HUS130:

DEVICE PROPERTIES for disk: /dev/rdsk/c0t60060E80103EC920057FB7620000000Ad0s2
  Vendor:               HITACHI
  Product ID:           DF600F        
  Revision:             0000
  Serial Num:           92256098000A  
  Unformatted capacity: 1048576.000 MBytes
  Write Cache:          Enabled
  Read Cache:           Enabled
    Minimum prefetch:   0x0
    Maximum prefetch:   0x0
  Device Type:          Disk device
  Path(s):


/dev/rdsk/c0t60060E80103EC920057FB7620000000Ad0s2
  /devices/scsi_vhci/ssd@g60060e80103ec920057fb7620000000a:c,raw
   Controller           /devices/pci@0/pci@0/pci@8/pci@0/pci@9/SUNW,emlxs@0/fp@0,0
    Device Address              50060e80103ec920,3
    Host controller port WWN    10000000c96b5d01
    Class                       primary
    State                       ONLINE
   Controller           /devices/pci@0/pci@0/pci@8/pci@0/pci@9/SUNW,emlxs@0/fp@0,0
    Device Address              50060e80103ec929,3
    Host controller port WWN    10000000c96b5d01
    Class                       primary
    State                       ONLINE
   Controller           /devices/pci@0/pci@0/pci@8/pci@0/pci@1/SUNW,emlxs@0/fp@0,0
    Device Address              50060e80103ec921,3
    Host controller port WWN    10000000c96b5e08
    Class                       primary
    State                       ONLINE
   Controller           /devices/pci@0/pci@0/pci@8/pci@0/pci@1/SUNW,emlxs@0/fp@0,0
    Device Address              50060e80103ec928,3
    Host controller port WWN    10000000c96b5e08
    Class                       primary
    State                       ONLINE

Обратите внимание на строки State - ONLINE и Class - PRIMARY.
Вот для массива типа Active-Passive мы увидим на одной паре Class - Standby и эти пути не будут получать трафик без причины.
В нашем случае у нас массив Active-Active и все пути работают.

Идем далее:
iostat - у нас есть две опции X и Y для просмотра статистики по путям.
#iostat -zX 5

                  extended device statistics                
device      r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b
ssd1.fp2  572.7  927.0 1512.6 30438.0  0.0  0.0    0.0   0   0
ssd1.fp4  576.9  866.4 1489.5 30486.8  0.0  0.0    0.0   0   0

#iostat -zY 5


                    extended device statistics                  
device          r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b
ssd1.t1.fp2   237.6  340.7  648.0 14646.4  0.0  0.0    0.0   0   0
ssd1.t2.fp2   241.0  321.9  621.5 14752.7  0.0  0.0    0.0   0   0
ssd1.t3.fp4   242.6  269.6  646.6 10917.1  0.0  0.0    0.0   0   0
ssd1.t4.fp4   247.0  333.5  653.4 13982.3  0.0  0.0    0.0   0   0


fp2 и fp4 - это наши пути, которые работают одновременно на трафик с массивом.






четверг, 15 ноября 2012 г.

Storwize V7000. Сервисные заметки

Сервисные операции можно выполнить зайдя браузером по адресам контроллеров
https://node SA IP/service (по умолчанию адреса напоминаю - 192.168.70.121 и 122).

Зайти можно только пользователем superuser (passw0rd по умолчанию)

Так же можно зайти и через CLI. Сервисные команды из групп sainfo и satask.

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

При инициализации можно включить режим Call Home. Этот режим повышает уровень поддержки или менять его. Всего 4-е уровня - локальный, Европа, США, разработчики.
По умолчанию многие не делают этого и далее все по накатанной - звонок в Москву, если там не решают - передают проблему дальше. Когда Call Home включен, то проблема передаётся на все 4-е уровня сразу и тот кто первый ответит тот и будет решать.
При включеном Call Home и необходимости поиграть и потестить и что бы не напрягать людей в поддержке, то надо включить режим сервиса:
svctask chiogrp -maintenance yes
пока этот режим включен, в поддержку ничего не отправляется.

Журнал ошибок хранится на массиве но может так же копироваться на syslog сервер удаленный. Журнал хранится пока не разрушен кластер.

Если в Events есть проблема, можно выполнить процедуру  Run Fix Procedure. Если проблему не решить в течении 25-ти часов, то у нее меняется приоритет.

Журналы событий можно скачать с массива (Settings -> Support).
Журнал аудита ведется с начала создания кластера! И ведется с записью всех команд группы svctask.

Обновление прошивки. По соглашению с ИБМ что выдается при первой инсталляции, говорится что заказчик должен поддерживать актуальное состояние прошивки.  Но будьте бдительны. При выходе новой версии прошивки, качаем Release Notes, читаем что поправили и если не критично - не обновляемся. Ждем следующую.

Если требуется обновить прошивки дисков..... Да уж... КАЖДЫЙ ДИСК ОБНОВЛЯЕТСЯ в РУЧНУЮ и ПО ОЧЕРЕДИ!

ВНИМАНИЕ, прошивка SSD всегда переводит его в OFFLINE! Обновление HDD в OnLine.

Прошивку ставим через прогон Upgrade test utility.
Обновление прошивки идет около 20 минут. Для одной ноды. Далее идет ожидание перехода томов и отработки мультипасинг-драйверов - 30 минут. И только потом обновляется вторая нода - еще 20 минут.

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

Если в кластере 4 узла (две io_group), обновление будет производиться так - первой node2 в группе 0 (20 минут), далее - node3 в группе 1 (20 минут), 10 минут пауза, далее node1 из группы 0 (20 минут) и в этот момент node2 стала Configuration Node, далее node4 группы 1 (20 минут).

Откат на предыдущую прошивку осуществляется либо автоматом при ошибке, либо в ручную. Время на откат такое же как на обновление.

  Обновление прошивки дисков:
- не должно быть алертов, снижаем нагрузку на диски.
Время на обновление диска - 15... 20 секунд.
Использовать пока только CLI.

Резервное копирование конфигурации массива.
svcconfig backup

На самом деле в 01:00 каждый день массив сам делает это.
В бэкап входит три файла. Именно они и нужны будут для восстановления если что.
Это файл xml, sh, log.




Storwize V7000. Easy Tier. Заметки

Easy Tear (далее EA) включена в базу массива.

EA собирает статистику в течении 24 часов каждые пять минут. Далее формируется список Top Extents по условиям - IO запросы не более 64 КБ и эти запрос только на чтение!

Далее происходит миграция (перенос) Extents из списка, который был составлен на базе собранной статистики, но не более 2ТБ в 24 часа. Далее собранная за следующие 24 часа статистика накладывается и совмещается с предыдущей и происходит вновь перемещение горячих Extents на SSD, но заметим, что не происходит обратного перемещения с SSD на HDD без необходимости. То есть если Extent перемещен был когда то по статистике на SSD, то он там и останется пока не потребуется освободить место на SSD, и если этот Extent не находится в новом совмещенном TOP Extents списке. Это значит, что за выходные (когда например нет ввода-вывода), в понедельник не будет торможения, ибо не будет принудительного перемещения на HDD.
Еще раз обращаю внимание на то, что приложения с блоком ввода-вывода более 64 КБ не будут участвовать в EA.

Для дисков Thin Provision в EA будут участвовать только заполненные Extents.

EA может быть включено как для Storage Pool так и для каждого тома. Причем, если SSD дисков нет вообще и включим EA (определенным образом) то можно включить режим сбора статистики. А после сбора статистики используя инструмент STAT (Storage Tier Advisor Tool) - бесплатно с сайта ИБМ под Windows можно получить отчет о том приросте производительности, который даст покупка SSD. Файл статистики после начала сбора, находится в /dump/dpa_heat/. Его надо забрать и скормить STAT-у.





среда, 14 ноября 2012 г.

Storwize V7000. Виртуализация внешних систем хранения

Для памяти и пояснений - будем внимательны при работе со StorWize V7000 и виртуализации внешних систем через него.

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

Далее, конечно проверяем зонирование...

Далее на сторвайзе надо провести операцию Detect MDisks. Это позволит найти наши тома с внешней системы. Будут созданы объекты MDisk Unmanage. На этих объектах давим правой кнопкой мышки и говорим - Import! НО!

Прежде чем это сделать подумайте вот над чем. IMPORT делает исключительно ПЕРЕНОС данных в другой пул (обычно на внутренние диски сторвайза). Это маркетинговое ограничение GUI интерфейса. Запускается операция миграции как она делается обычно - блоками по 16 МБ (блокируя на время операции и чтение и запись, изменения копятся в кэше и после переноса блока 16МБ в новое место, накатывается блок измененных данных на перенесенный в новое место блок данных а старый блок помечается как пустой).

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

Команда mkvdisk с параметром -vtype image - это и есть условие создания такой конфигурации.

ЛИБО вариант два - используем Migration Wizard (Pools -> System Migration -> Start New Migration)

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

Export Wizard - это операция обратная - когда нужно со сторвайза данные слить на внешнюю систему. Тут делается изменение представления тома из формата сторвайза (который базируется на Extents) в последовательный блочный вариант. Mdisk после завершения будет типа Image. Это на этом MDisk был том, то в конце операции удаляем это том - это не удаляет данные а удаляет только ссылку на данные. Далее просто мы делаем мапинг уже нового местоположения данных.







понедельник, 30 июля 2012 г.

IBM Storwize. Заметки

IP адреса на сервисных портах по умолчанию: 192.168.70.121 и 122 /24
User: superuser, password: passw0rd

Документация для старта: http://pic.dhe.ibm.com/infocenter/storwize/ic/index.jsp

В комплекте с железкой идет флешка. На ней два файла InitTool.exe и autorun.inf.
Флешку втыкаем в ноут, запускаем InitTool. Оно запросит IP адрес (я вводил сервисные умолчательные). Давим Finish. Был создан текстовый файл satask.txt. В нем одна строка с адресом, шлюзом и маской. Далее вставляем флешку в USB порт на массиве (любой из 4-х сзади). Начинает моргать оранжевый индикатор со знаком !

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


Удалить кластерную конфигурацию можно только переведя канистры в сервисный режим. Более того , надо удалить имя старого кластера (Configure Enclosure).

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

Лицензирование делается по количеству полок. External Virtualization - это количество полок на внешних массивах. Именно полок.

Для мультипассинга под винды и аикс - нужно ставить драйверы SDD.
Для остальных ОС работают родные.

На каждом диске резервируется 512 МБ кусок при инициализации для нужд кворума. Для кворум предпочтение отдается дискам Spare. Но место резервируется на всех дисках. 

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

Система не является Active-Active. Драйвер мультипасинга работает по алгоритму round-robin. И это накладывает следующее разумное объяснение - минимум ДВА FC порта с КАЖДОГО контроллера должно быть подключено.
То есть именно по этим двум путям к одному контроллеру и будет отработан round-robin а ни как на оба контроллера.

Надо понять так же систему распределения нагрузки по дискам. Помним, что есть верхняя сущность - VDISK (Volume), которая суть набор неких Extents. Каждый Extent это ссылка на Mdisk (хоть внешний хоть внутренний). Размер Extent-а от 16 МБ до 8 ГБ. По сути это определяет объем который может быть доступен для управления массивом. Это зашито в прошивке - 4 млн extents на систему. Механизм отработки понятен - блок данных пришел в массив, собрался в кэше (может быть), и далее будет записан в текущий Extent (пока не заполнится) со страйпом на Mdisk (а страйп у нас по умолчанию 256 Кб и есть еще второй вариант - 128 Кб и все). Если VDisk сделан на базе Storage Pool, в который входят несколько Mdisk , то extent будет записываться на один MDisk пока не заполнится, после чего переключится на следующий Mdisk. 

Storage Pool по умолчанию собирается в режиме страйпа.

ЦПУ в массиве 4-х ядерные, и оптимально нагружать в 4 потока. 1 поток обрабатывается одним ядром. 

Кэш тут работает по "честному" - всем поровну. Кусок кэша выделяется каждому Storage Pool. Не регулируется. На контроллере 8 ГБ кэша, в сумме 16 ГБ, зеркалируется только кэш на запись. Кэш так же используется и для хранения сумм CRC для рейдов (если используются).
Кэш на запись и чтение не могут быть выключены. При создании нового пула, кэш тут же распределится в пропорциях , особенно забавно что для продакшн системы (если она была до этого) мы уменьшим размер кэша при этом.

Статья по производительности от одного из разработчиков - ТУТ.


iSCSI крайне ограничен. Не поддерживаются VLAN, нет бондов и порт 1Гб...
Надо глянуть нет ли расширения iSCSI в версии Unified. Репликации нет по iSCSI, Volume Mirror - нет.

В одну систему можно добавить в сумме 10 полок (одна из них это голова).
Причем из-за особенностей строения SAS на первую цепь - 5 полок, на вторую - 4.






понедельник, 19 марта 2012 г.

EMC VNX5300. Часть 1. Начало

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

Тем кому нужны какие-то ответы по массиву, или задачки надо проверить - добро пожаловать в комментарии, буду по мере возможности отвечать, пробовать.
Что планирую пробовать и замерять сам:
1. Работу FAST Cache vs FAST VP vs Flash HDD
2. Работу Thin Provision vs raid groups vs StoragePools
3. Update software под нагрузкой
4. Мультипасинг под нагрузкой


Массив пришел в составе:
VNX5300, два контроллера, только блочный доступ, 2 EFD 100GB, остальные 600ГБ SAS 10000 rpm.
ПО полностью весь комплект, можно пробовать разные вещи.

Собрать в стойку очень просто. Сначала батарейный блок (два модуля), сверху массив.
Умолчательные адреса на контроллерах 1.1.1.1 и 1.1.1.2.

Утилитка  Unisphere Storage Initialization под Windows 7 у  меня ни разу не сработала (не нашла ни одного массива даже в условиях одного хаба). Под XP работает и находит.

Поэтому простое решение - в одну сетку, браузером на адрес 1.1.1.1 и меняем адреса на нужные. ПОльзователя создайте в scope Global (sysadmin). По сути именно это и делает не рабочая у меня утилитка.

четверг, 27 мая 2010 г.

IBM p550 AIX 5.3 в связке с Sun STK 6140

Для рабочей связке потребовался RDAC драйвер от SUN. Он вот здесь

Устанавливаем драйвер только после прочтения документа, что скачиваем по той же ссылке. Обратить внимание на то, что нужно вынести драйвер DPF если он там был.

На массиве делаем инициаторов и хост по типу AIX_FO.

Делаем том и отдаем AIX.
После установки драйвера получим набор интсрументов в /usr/lpp/sundac.
Не забыв запустить cfgmgr сначала, смотрим что есть. По идее, есть dar - массив и dac0,dac1 - адаптеры. Перед тем как создать дисковую группу в AIX с томом с массива, запустить сценарий /usr/lpp/sundac/setSUNdac. А именно он установит глубину очереди в 32 вместо 10.

вторник, 8 декабря 2009 г.

CX4-120. EFD vs FC. Часть 5 - Стенд 5xEFD RAID5, Solaris,ZFS

Часть 5. CX4-120. EFD vs FC. Часть 5 - Стенд 5xEFD RAID5, Solaris,ZFS

Часть 1. Описание. Массив CX4-120. EFD (Flash), FC. UFS/ZFS
Часть 2. CX4-120. EFD vs FC. Часть 2 - Стенд 10xFC RAID10, Solaris, RAW
Часть 3. CX4-120. EFD vs FC. Часть 3 - Стенд 10xFC RAID10, Solaris,UFS
Часть 4. CX4-120. EFD vs FC. Часть 4 - Стенд 5xEFD RAID5, Solaris,RAW, UFS


Стенд был перестроен на работу с ZFS. Параметры ZFS:
ssd_big/db1 type filesystem -
ssd_big/db1 creation Tue Nov 3 17:34 2009 -
ssd_big/db1 used 218G -
ssd_big/db1 available 14.3G -
ssd_big/db1 referenced 218G -
ssd_big/db1 compressratio 1.00x -
ssd_big/db1 mounted yes -
ssd_big/db1 quota none default
ssd_big/db1 reservation none default
ssd_big/db1 recordsize 8K local
ssd_big/db1 mountpoint /ssd_big/db1 default
ssd_big/db1 sharenfs off default
ssd_big/db1 checksum on default
ssd_big/db1 compression off default
ssd_big/db1 atime off local
ssd_big/db1 devices on default
ssd_big/db1 exec on default
ssd_big/db1 setuid on default
ssd_big/db1 readonly off default
ssd_big/db1 zoned off default
ssd_big/db1 snapdir hidden default
ssd_big/db1 aclmode groupmask default
ssd_big/db1 aclinherit secure default
ssd_big/db1 canmount on default
ssd_big/db1 shareiscsi off default
ssd_big/db1 xattr on default

1. Первый тест на чтение 100 файлов по 1 ГБ каждый в 100 потоков. Сначала эти файлы создаём (первые строки будут как раз об этом) а уж потом только читаем.
fsd=fsd1,anchor=/ssd_big/db1/fs1,depth=1,width=1,files=100,size=1g fwd=fwd1,fsd=fsd1,xfersize=8k,fileio=random,fileselect=random,operation=read,threads=100
rd=rd1,fwd=fwd1,fwdrate=max,format=yes,elapsed=900,interval=1
Vdbench:

IOSTAT: (правда тут только часть на чтение)

SWAT:


2. 10 больших файлов (10 ГБ каждый) и 15 потоков. 80/20 (чтение/запись)
sd=sd1,lun=/ssd_big/db1/fs2/file_1
sd=sd2,lun=/ssd_big/db1/fs2/file_2
sd=sd3,lun=/ssd_big/db1/fs2/file_3

sd=sd4,lun=/ssd_big/db1/fs2/file_4

sd=sd5,lun=/ssd_big/db1/fs2/file_5

sd=sd6,lun=/ssd_big/db1/fs2/file_6

sd=sd7,lun=/ssd_big/db1/fs2/file_7

sd=sd8,lun=/ssd_big/db1/fs2/file_8

sd=sd9,lun=/ssd_big/db1/fs2/file_9

sd=sd10,lun=/ssd_big/db1/fs2/file_10

wd=rg-1,sd=sd*,rdpct=80,rhpct=0,whpct=0,xfersize=8k,seekpct=80
rd=rd_rg-1,wd=rg-1,interval=1,iorate=max,elapsed=900,forthreads=(15)

KSTAT:
kstat zfs:0:arcstats:size
module: zfs instance: 0
name: arcstats class: misc
size 3020269568

zpool iostat:
pool used avail read write read write
---------- ----- ----- ----- ----- ----- -----
ssd_big 134G 102G 106 15 1.15M 1.77M
ssd_big 134G 102G 4.24K 303 99.5M 22.5M
ssd_big 134G 102G 3.56K 145 87.0M 11.0M
ssd_big 134G 102G 7.63K 29 180M 493K
ssd_big 134G 102G 7.76K 12 177M 59.9K
ssd_big 134G 102G 6.62K 23 159M 2.88M

IOSTAT:


Vdbench:


SWAT:


3. 100 файлов по 1ГБ каждый, 8кб блок и 100 потоков (80% чтение, 20% запись)
sd=sd*,lun=/ssd_big/db1/fs3/file_*,count=(1,100)
wd=rg-1,sd=sd*,rdpct=80,rhpct=0,whpct=0,xfersize=8k,seekpct=80

rd=rd_rg-1,wd=rg-1,interval=1,iorate=max,elapsed=900,forthreads=(100)


KSTAT:
kstat zfs:0:arcstats:size
module: zfs instance: 0
name: arcstats class: misc
size 2420348928

ZPOOL IOSTAT:
capacity operations bandwidth
pool used avail read write read write
---------- ----- ----- ----- ----- ----- -----
ssd_big 114G 122G 2.98K 502 38.8M 39.3M
ssd_big 114G 122G 9.53K 290 85.6M 27.4M
ssd_big 114G 122G 9.56K 284 88.5M 30.1M
ssd_big 114G 122G 9.71K 285 86.9M 30.2M
ssd_big 114G 122G 10.7K 313 94.5M 27.2M
ssd_big 114G 122G 11.4K 271 99.4M 24.5M
ssd_big 114G 122G 9.34K 277 83.1M 29.3M

Vdbench:


SWAT:


Navisphere:


CX4-120. EFD vs FC. Часть 4 - Стенд 5xEFD RAID5, Solaris,RAW, UFS

Часть 4. CX4-120. EFD vs FC. Часть 4 - Стенд 5xEFD RAID5, Solaris,RAW, UFS

Часть 1. Описание. Массив CX4-120. EFD (Flash), FC. UFS/ZFS
Часть 2. CX4-120. EFD vs FC. Часть 2 - Стенд 10xFC RAID10, Solaris, RAW
Часть 3. CX4-120. EFD vs FC. Часть 3 - Стенд 10xFC RAID10, Solaris,UFS
Часть 5. CX4-120. EFD vs FC. Часть 5 - Стенд 5xEFD RAID5, Solaris,ZFS

Стенд собран с дисками EFD (FLASH) 73GB в RAID5. Эти устройства оптимизированы для случайного чтения и я ожидаю от них прорыв именно в тестах на чтение. С записью... Ну видно будет на графиках. Кэш на массиве ОТКЛЮЧЕН на все операции.

1. Без файловой системы. 64 потока блоками 8к. Чтение - 80%.
Sd=sd1,lun=/dev/rdsk/c3t600601600B10230068A759006BC8DE11d0s0,threads=64
Wd=wd1,sd=sd1,xfersize=8k,rdpct=80,seekpct=random
rd=run1,wd=wd1,iorate=max,elapsed=900,interval=1

IOSTAT:

Vdbench:

NaviSphere:

SWAT:




2. Файловая системы UFS на том устройстве, что участвовало в предыдущем стенде как RAW.
Вот такой тест:
fsd=fsd1,anchor=/u/fs1,depth=1,width=1,files=100,size=1g fwd=fwd1,fsd=fsd1,xfersize=8k,fileio=random,fileselect=random,operation=read,threads=100 rd=rd1,fwd=fwd1,fwdrate=max,format=yes,elapsed=900,interval=1
Здесь замечу, стоит параметр format=yes. То есть тест сначала создаёт эти файлы (я намеренно включил это и в статистику). Сначала создаём 100 файлов по 1 ГБ, а потом в 100 потоков читаем случайно. Первые строки результатов как раз показывают процесс создания, а потом уже чтение...
Результаты с NaviSphere не привожу. Как показала практика, они совпадают с Vdbench.
Vdbench:

IOSTAT:

SWAT:




3. Вот такой тест:
sd=sd1,lun=/u/fs2/file_1
sd=sd2,lun=/u/fs2/file_2
sd=sd3,lun=/u/fs2/file_3
sd=sd4,lun=/u/fs2/file_4

sd=sd5,lun=/u/fs2/file_5

sd=sd6,lun=/u/fs2/file_6

sd=sd7,lun=/u/fs2/file_7

sd=sd8,lun=/u/fs2/file_8

sd=sd9,lun=/u/fs2/file_9

sd=sd10,lun=/u/fs2/file_10

wd=rg-1,sd=sd*,rdpct=80,rhpct=0,whpct=0,xfersize=8k,seekpct=80

rd=rd_rg-1,wd=rg-1,interval=1,iorate=max,elapsed=900,forthreads=(15)

То есть 10 файлов по 10 ГБ каждый, 15 потоков, чтение - 80%.
IOSTAT:

KDB:
> ::memstat
Page Summary Pages MB %Tot
------------ ---------------- ---------------- ----
Kernel 112288 877 11%
Anon 70906 553 7%
Exec and libs 2570 20 0%
Page cache 786029 6140 76%
Free (cachelist) 13467 105 1%
Free (freelist) 42798 334 4%

Total 1028058 8031
Physical 982315 7674

Vdbench:

NaviSphere:


SWAT:


4. Следующий тест по сути такой же как предыдущий. 10 больших файлов (10ГБ каждый) и 200 потоков 8кб блоками 80/20:
sd=sd1,lun=/ssd_big/db1/fs2/file_1 sd=sd2,lun=/ssd_big/db1/fs2/file_2 sd=sd3,lun=/ssd_big/db1/fs2/file_3 sd=sd4,lun=/ssd_big/db1/fs2/file_4 sd=sd5,lun=/ssd_big/db1/fs2/file_5 sd=sd6,lun=/ssd_big/db1/fs2/file_6 sd=sd7,lun=/ssd_big/db1/fs2/file_7 sd=sd8,lun=/ssd_big/db1/fs2/file_8 sd=sd9,lun=/ssd_big/db1/fs2/file_9 sd=sd10,lun=/ssd_big/db1/fs2/file_10
wd=rg-1,sd=sd*,rdpct=80,rhpct=0,whpct=0,xfersize=8k,seekpct=80

rd=rd_rg-1,wd=rg-1,interval=1,iorate=max,elapsed=300,forthreads=(200)

Vdbench:


5. То же самое, но 500 потоков.
Vdbench:

SWAT:


6. А теперь только чтение:
wd=rg-1,sd=sd*,rdpct=100,rhpct=0,whpct=0,xfersize=8k,seekpct=100
rd=rd_rg-1,wd=rg-1,interval=1,iorate=max,elapsed=300,forthreads=(500)
Vdbench:

SWAT:


IOSTAT:


7. А теперь с тем же набором файлов но ТОЛЬКО запись:
wd=rg-1,sd=sd*,rdpct=0,rhpct=0,whpct=0,xfersize=8k,seekpct=0 rd=rd_rg-1,wd=rg-1,interval=1,iorate=max,elapsed=300,forthreads=(100)
IOSTAT:

Vdbench:

SWAT:


Продолжение следует...