Еще раз о дисковой подсистеме

[Anton Kuznetsov]

Добрый день!

Случилось у меня радость долгожданная - разжился большим пузатым сервером
под свои фильмы. 80ГБ оперативки, да дисков 12х2ТБ, да рейд-контроллеры
Adaptec ... Ну, думаю, заживу теперь как белый человек! Соберу все в
большие, надежные, быстрые рейды и будет мне удобно и комфортно. Но как
давно известно - выбери любые два из трех и заходи. :( Хотелось-то малого -
устал я жить размазав свой архив по 10 дискам и собирая все в один каталог
симлинками.
В новом сервере все диски подключены через два контроллера Adaptec 3805.
Сделал два рейда, один "железный" RAID5 на контроллере из 5 дисков, другие
диски объявил single volume и во фре собрал еще один массив так же из 5
дисков ZFS->raidz.
Полная грусть.
raidz работает близко к нулевой нагрузке, пока потоков штук 200 и мегабит
примерно 200-300. А потом, в какой-то момент gstat резко краснеет, все диски
100%, скорость падает с 300 до 200 и так все ровнехонько и тащится, все
nginx-ы в состоянии zio->. Никакие тюнинги внятного эффекта не дали.
Железный RAID5 по утвеждению gstat всегда читает блоками по 1М независимо от
значения kern.ipc.sfreadahead, нагрузку держит более линейно, но так же
плохо. Nginx начинает заваливаться в biord при 300-400 мегабитах.

Мои предыдущие достижения на тех же SATA дисках - до 200 мегабит с диска
(всем плохо конечно, но 6 дисков дают гигабит в полку) или 150 в
качественной отдаче, т.е. я наделся получить с этих рейдов качественные 750
мегабит, а реальный результат в разы хуже. Честно говоря связываться с
железным рейдом и не хочется - гибкости никакой. Можно ли потюнить ZFS для
высокопроизводительной отдачи больших файлов под nginx? Или возвращаться к
старой схеме одиночных дисков и опять забыть про надежность?


-- 
Best regards,
Anton Kuznetsov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20110817/a35b4f40/attachment.html>