низкая скорость записи в массивах yotta yi-16 fc-sata2
Модераторы: Trinity admin`s, Free-lance moderator`s
Размер страйпа для случая линейного последовательного чтения должен быть однозначно меньше блока чтения. Проверял лично. В случае "обычной" Винды размер блока, как уже выше упомянули, 64К, а значит страйп желателен меньше 64К, намного меньше. Если взять Висту, то там максимальный размер блока чтения 8М, стало быть в данном случае размера страйпа в 1М за одну операцию чтения "захватится" 8 дисков и, соотв., где-то должно получиться 40 (минимум по чтению)*8 минус накладные расходы на "рейдпятовость" ~ 200-250 мег/сек. Как-то примерно так...
страйп 57 мбт в сек
хотелось бы хотябы 100
т.к. (тоже повторюсь) копирование с одиночного диска сата на аналогичный при чистых дисках (максимальные скорости в первых 40 % поверхности дисков) дало 57 мбт в сек
разьве может скорость записи одиночных дисков равняться страйпу из 16ти аналогичных дисков при всех выполненных рекомендациях по настройке для данного типа и размера файлов
достаточно теории...откликнитесь, кто реально получал на массивах с более 2тбт более 100мбт в сек на файлах больших размера кэша windows...
хотелось бы хотябы 100
т.к. (тоже повторюсь) копирование с одиночного диска сата на аналогичный при чистых дисках (максимальные скорости в первых 40 % поверхности дисков) дало 57 мбт в сек
разьве может скорость записи одиночных дисков равняться страйпу из 16ти аналогичных дисков при всех выполненных рекомендациях по настройке для данного типа и размера файлов
достаточно теории...откликнитесь, кто реально получал на массивах с более 2тбт более 100мбт в сек на файлах больших размера кэша windows...
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Пост Йохансона по поводу размера страйпа стоит считать или ошибочным или присущим какому-то одному конкретному массиву.
Фирмвари контроллера глубоко фиолетовы сторонние мнения - она работает так, как работает. И факт того, что данные иометра точно совпадают с реальным копированием, говорит очень много.
Многие массивы могут выдавать гораздо большие потоки. Из дешевых например инфортренды. Из посерьезнее - ИБМ DS4200 например.
Даже Xyratex, который очень сильно тормозит при записи на сата винты, выдает 60-70МБ/с даже при включенном кэш-мирроринге. А без оного раза в два больше...
Вы же купили запорожец и хотите, чтобы он ездил как феррари...
Фирмвари контроллера глубоко фиолетовы сторонние мнения - она работает так, как работает. И факт того, что данные иометра точно совпадают с реальным копированием, говорит очень много.
Многие массивы могут выдавать гораздо большие потоки. Из дешевых например инфортренды. Из посерьезнее - ИБМ DS4200 например.
Даже Xyratex, который очень сильно тормозит при записи на сата винты, выдает 60-70МБ/с даже при включенном кэш-мирроринге. А без оного раза в два больше...
Вы же купили запорожец и хотите, чтобы он ездил как феррари...
Да, я говорил за свою Триварь. Но, все равно, по логике вещей, если фирмварь контроллера не делает какое-то умное предсказание по чтению и не забирает больше инфы, чем система просит от массива, то такая картина и будет. А если фирмварь умная, то будет другая картина.gs писал(а):Пост Йохансона по поводу размера страйпа стоит считать или ошибочным или присущим какому-то одному конкретному массиву.
пошаманил - теперь имею по записи 55 мбт в сек (гонял на 20ти гиговых массивах файлов разной емкости (от 1гиг до цельного куска 20гиг))
маловато..
жаль, что ётта не понимает raid 4 double parity, глядишь и на 100 мбт в сек бы вышел
от 6-го рейда отказаться не могу, часто видел одновременные отказы 2-ух дисков в 16ти дисковых массивах (хотя до запуска в работу диски полными тестами массивов гонял)
а у меня сервер 52 терра юзаемого пространства (9ть осталось) и без Tape библиотеки в качестве бэкапа
жду когда ётты будут понимать терные диски типа Ultrastar A7K1000
в общем все печально...
маловато..
жаль, что ётта не понимает raid 4 double parity, глядишь и на 100 мбт в сек бы вышел
от 6-го рейда отказаться не могу, часто видел одновременные отказы 2-ух дисков в 16ти дисковых массивах (хотя до запуска в работу диски полными тестами массивов гонял)
а у меня сервер 52 терра юзаемого пространства (9ть осталось) и без Tape библиотеки в качестве бэкапа
жду когда ётты будут понимать терные диски типа Ultrastar A7K1000
в общем все печально...
Не пробовал ли кто-либо в массивах использовать скоростные (по заявлениям) жесткие диски типа barracuda es2 или ultrastar a7k1000?
к сожалению под 10000rpm только 150 gb..
И использовал ли кто в массивах гибридные диски (о твердотельниках молчу) от MCell с sdram ddr в 1gb в качестве буфера?
Есть ли прирост скорости записи в массивах?
к сожалению под 10000rpm только 150 gb..
И использовал ли кто в массивах гибридные диски (о твердотельниках молчу) от MCell с sdram ddr в 1gb в качестве буфера?
Есть ли прирост скорости записи в массивах?
Похоже, я понял, как работает буферизация в винде2003.
Если файл имеет больший размер, чем свободное место в буфере, то буфер заполняется со скоростью чтения из ётты. После заполнения он становится недоступным для дозалива оставшегося файла и сбрасывает буферизованную часть файла на диск со скоростью записи на этот диск.
Вот и получается , что мы имеем между ёттами практически еще один паразитный диск.
А теперь цифры:
Как правило, у нас 7.5 гбт буфера свободно. Вот и берем с одной етты файл 7.5гбт и копируем в другую.
Все проходит в один «заглот» и имеем скорость 105 мбт в сек даже в 6том рейде. (дефраг и все остальное не в счет пока)
Как только превысим размер буфера, начинаем иметь наши 50мбт в сек. И чем больше «заглотов», тем хуже.
На малых файлах иной раз копировал со скоростью 350 мбт в сек. Но тут похоже участвует много факторов, т.к. один и тот же файл я мог копировать с разными скоростями (многопользовательская работа,загруженность процессора, приоритеты процессов и т.д.).
Итог:
Логика работы эксплоурера не понимает, что если файл больше размеров буфера, то просто нужно отказаться для его копирования от виндовой буферизации!
Вот собственно и все...
Если файл имеет больший размер, чем свободное место в буфере, то буфер заполняется со скоростью чтения из ётты. После заполнения он становится недоступным для дозалива оставшегося файла и сбрасывает буферизованную часть файла на диск со скоростью записи на этот диск.
Вот и получается , что мы имеем между ёттами практически еще один паразитный диск.
А теперь цифры:
Как правило, у нас 7.5 гбт буфера свободно. Вот и берем с одной етты файл 7.5гбт и копируем в другую.
Все проходит в один «заглот» и имеем скорость 105 мбт в сек даже в 6том рейде. (дефраг и все остальное не в счет пока)
Как только превысим размер буфера, начинаем иметь наши 50мбт в сек. И чем больше «заглотов», тем хуже.
На малых файлах иной раз копировал со скоростью 350 мбт в сек. Но тут похоже участвует много факторов, т.к. один и тот же файл я мог копировать с разными скоростями (многопользовательская работа,загруженность процессора, приоритеты процессов и т.д.).
Итог:
Логика работы эксплоурера не понимает, что если файл больше размеров буфера, то просто нужно отказаться для его копирования от виндовой буферизации!
Вот собственно и все...
Re: низкая скорость записи в массивах yotta yi-16 fc-sata2
Провел модернизацию старым массивам yotta. Заменил все старые на диски Hitachi Ultrastar 1тбт HUA721010KLA330. И обновил винду с 2003 на 2008. (p/s/ Ранее я увеличил объем физической памяти до 16гбт). При записи из массива в массив замерял реальную скорость записи. Копировал файлы: 1 , 2, 10, 20гбт в один поток (пока пользователей не было на массиве). Получал в среднем 176мбт в сек (иногда до 206 мбт в сек). Это совсем другое дело! Даже в 5ть потоков средняя скорость была около 55мбт в сек (но варьировалась). 2008 кэш отбирает полностью до остатка. Проблем 2003 винды с файлами, превышающими кэш (в 2ва раза отличающиеся скорости записи) НЕТ. Просто "Бузумно" доволен. (( Можно не отвечать. Просто поделился "радостью" с коллегами )).
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 30 гостей