May 17th, 2010

404

spew

Итак, во-первых, в качестве ПО для тестирования будет использоваться именно spew, как самая "тупая и понятная" по логике программа.

Её алгоритм (в random режиме): файл заданного размера (в случае блочного устройства - область устройства заданного размера) сначала целиком записывается, а потом целиком читается. Запись и чтение осуществляется блоками произвольного размера в данных диапазонах (я выбрал для теста диапазон 2-256к), причём таким образом, что каждая область прочитывается/пишется, причём только один раз.

В ходе этого вычисляется число иопсов (как время теста, делённое на число операций) и скорость.

Пока я имею следующее (для стрипа из 4х RAID6 по 12 дисков каждый):


spew -dgr --raw -b 2k -B 256k XXXX /dev/md0

XXXX

W iops (kb/s)

R iops (kb/s)

512M

 460 (3761.16)

3364.37 (26383.71)

2G

1794.48 (15102.29)

1289 (10105.19)

8G

6214 ( 63883 кб/с)

5973 (46773 кб/с)

32G

10958 (86295)

8853 (69343)

128G

 8583.14 (85366.84)

5573 ( 43651)



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

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

Методика понятна, теперь осталось выяснить, какой рейд лучше будет справляться.

Ещё удивительное: iops'ы на запись лучше чтения.
404

Изучение рейдов

Во-первых, конечно, это было шоком, когда с 850Мб/с линейной скорости рейд "пал" до 4Мб/с при 4кб рандомном доступе. Я сначала даже отказывался признавать результаты. Потом задумался - а почему, собственно, нет? Если рейд дёргают по сотне гигабайт с требованием читать 4кб каждый раз из нового места, то почему нужно ожидать, что там будет какая-то архискорость? Ведь речь идёт про настоящий рандом, в котором даже NCQ/TCQ никак особо не спасает, ни кеши, ни что. Голый винт с голой головкой. И всё, в чём может себя проявить рейд - это правильно распределить загрузку по винтам, так, чтобы каждый из винтов был чуть меньше занят, благодаря TCQ, в котором можно одновременно загрузить несколько винтов запросами из разных мест очереди.

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

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

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

Ещё нужно внимательно проверить, а так ли круто многократное наслоение рейдов, как это казалось в линейных тестах...


PS Заодно стало понятно, что нужен ещё один тест - тест на ограниченное число параллельных (конкурирующих) линейных потоков чтения/записи.
404

Веб-браузерное

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

Просто по клику на табе в списке выбираешь один из 5-7 цветов, и от подсвечивает, например, шрифт таба. Или цвет крестика.

А ещё хочу на табы вешать "аларм" (напомнить про таб через 10 минут, через два месяца и т.д.).
404

(no subject)

"Вам назначена роль Связанный сотрудник в Партнёрской программе Майкрософт"

Сибари?

Слишком внезапно, моё сердце не готово...
404

(no subject)

Event Type: Error
Event Source: NtFrs
Event Category: None
Event ID: 13568
Date: 17.05.2010
Time: 18:23:34
User: N/A
Computer: DC-SRV-01
Description:
The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.

Replica set name is : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Replica root path is : "c:\winnt\sysvol\domain"
Replica root volume is : "\\.\C:"
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found. This can occur because of one of the following reasons.

[1] Volume "\\.\C:" has been formatted.
[2] The NTFS USN journal on volume "\\.\C:" has been deleted.
[3] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long time.
[5] File Replication Service could not keep up with the rate of Disk IO activity on "\\.\C:".
Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.
[1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run "net stop ntfrs" followed by "net start ntfrs" to restart the File Replication Service.
[2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again.

To change this registry parameter, run regedit.

Click on Start, Run and type regedit.

Expand HKEY_LOCAL_MACHINE.
Click down the key path:
"System\CurrentControlSet\Services\NtFrs\Parameters"
Double click on the value name
"Enable Journal Wrap Automatic Restore"
and update the value.

If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.



Ненавижу винды.
404

тушёное мясо

+ лечо. Точнее, тот странный sidedish, который называют "грибное лечо" из грибов, перца, морковки и томатов.

Решено. Прощай котлеты и пельмени в морозильнике. Если за раз делать по килограмму-полтора, будет на несколько дней хватать.

Алсо, тушёное мясо, ака ТУШЁНКА может быть вкусным. И да, оно даже розово-беловатое внутри.
404

aptitude'ное

Кстати, оказывается, есть пакеты, которых нет в stable, sid, experimental, но которые есть в testing...

(например, libdirac-decoder0)