proNovell

было проведено тупое сравнение Netware и OES2 SP2 x86_64 на том же железе.

Железо:
чипсет - Intel Nehalem (MB Tyan S7025)
CPU: 2xW5590
RAM: 8GB DDR3

Hyper Threading выключен (рисуется 8 змей на SCRSAVER.NLM а не 16 )

Дисковая подсистема:
LSI MegaRaid SAS 8888ELP 512MB+BBU
8x15KRPM SEAGATE SAS HDD (7 on RAID5 + HotSpare)


Конфиг раида:

Adapter 0 -- Virtual Drive Information:
Virtual Disk: 0 (Target Id: 0)
Name:
RAID Level: Primary-5, Secondary-0, RAID Level Qualifier-3
Size:815.835 GB
State: Optimal
Stripe Size: 256 KB
Number Of Drives:7
Span Depth:1
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU

Current Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU

Access Policy: Read/Write
Disk Cache Policy: Enabled
Encryption Type: None


NW65SP8+All PostFixes (EDIR885SP3)+распоследние MEGA_SAS.HAM и E1000Q.LAN

(большие файлы)
Заливка туды 37 MB/S
Чтение оттель 26 MB/S

OES2 SP2 x86_64 + AllPatches (via RUG -t)
(большие файлы)
Заливка туды 46,3 MB/S
Чтение оттель 41,9 MB/S
[причем на OES2 запущен реалтайм кошмарыча !!!]

Склоняюсь в сторону OES2.

OES2 SP2 x86_64

Но на всякий случай уточню. Под оес 2 понимается линуксовая платформа?

да .

упор на то что OES2 SP2 Linux доступен в варианте x86_64.

Dimerson писал(а):Конфиг раида:

[...]
RAID Level: Primary-5, Secondary-0, RAID Level Qualifier-3
Size:815.835 GB
State: Optimal
Stripe Size: 256 KB
Number Of Drives:7
Span Depth:1
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU

Как я недавно писал здесь, я не так давно тоже игрался с замером производительности дисковой подсистемы в NetWare (там, правда, цели были другие). Так вот, одной из вещей, сильно меня удививших, явилось то, что в некоторых конфигурациях была существенная (на два порядка!) разница в производительности между последовательным (sequential) и произвольным (random) чтением. В тестах я использовал операции чтения/записи по 4кБ, что соответствует стандартному размеру блока для файловой системы NSS. Если в процессе тестирования этот параметр увеличивали, то падение производительности было не таким заметным (при значении 256 кБ разница находилась уже вполне в пределах вежливости). Я склонен этот эффект относить именно на счёт того, что в тех случаях параметры аппаратного RAID-массива, скорее всего, были слишком большими (вроде Ваших); что приводило к необходимости контроллеру читать целый страйп (256кБ) каждый раз, когда запрашивается лишь один блок (4кБ).

Поэтому в расчёте на использование файловой системы NSS (что для Linux-a, что для NetWare) я бы выставил всё же размер страйпа поменьше. Попутно, кстати, небольшое замечание: я нигде не нашёл, как размер блока NSS (для NetWare, для Linux-а не искал) изменить. Ну, то есть после создания пула и тома он везде отображается как 4 килобайта, но вот где его можно задать руками при создании - я так и не выяснил (ни в iManager, ни через NSSMU этого сделать не удаётся).

Возвращаясь к теме, я бы тоже делал ставку на платформу Linux. Во-первых, это поддержка современного "железа" (x86_64, большие объёмы оперативки, драйвера на новые контроллеры - всего этого для NetWare уже не будет). Во-вторых, политика самой компании Novell (постепенное окончание поддержки NetWare и настойчивые призывы к миграции на Linux). И если производительность по Вашим задачам Вас устраивает - то лучше сразу ставить Linux.

Честно говоря разницы между страйпом 256 и 64 к я не особо заметил.
При этом мерил производительность не на сервере а в связке
server - cisco3750 - станция (везде гигабит).

Кроме всего прочего окончательно тестировался кошмарыч (5.7 for Linux Server), Pervasive SQL 10.3 .

Осталось поглядеть SESAM бакап. Ибо придется хоронить купленный Arcserve 11.1 for NW (имеется ченджер с последним ультриумом).

Кто-нибудь глядел живьем ? как у него с производительностью ?

и вообще - Arcserve vs Sesam = ?

По словам многих вендоров размер страйпа и логического блока ОС уже почти никак друг к другу не относятся. Особенно если RAID-контроллер с набортным кэшем. Да еще и на дисках кеша до 64 МБ!
Про Портлок. Чтение мелких блоков будет принципиально медленнее, чем чтение больших блоков. Для большинства контроллеров/дисков самым большим блоком является 128 или 256 секторов. Для новых - уже и 512 секторов. Не удивлюсь, если в следующих версиях Портлока появятся и бОльшие блоки, ну там 1024 или 2048 секторов.
Кстати, вроде WD в своих дисках уже сектора делает не по 512 традиционных байт, а по 4096!