Raid тормозит при копировании
Здравствуйте.
Есть сервер Fujitsu-Siemens Primergy 200 (2хPIII 1266Mhz, 1Gb RAM). Установлена плата Adaptec 2100S Ultra3 SCSI. Настроен RAID-5 на 4-х дисках Seagate 36Gb. WriteBack отключен. ОС Windows 2000 Server SP4. Скорость чтения с диска от 5 до 30 мб\сек. Запись - 6 мб\сек. Почему так медленно?
На запись информации на том RAID5 тратятся дополнительные ресурсы, так как требуются дополнительные вычисления, [/b]зато при чтении (по сравнению с отдельным винчестером) имеется выигрыш, потому что потоки данных с нескольких накопителей массива распараллеливаются.. |
Я вот не понял в чем выигрыш? У меня IDE Seagate 80Gb читает быстрее, чем этот SCSI RAID-5. Я уж про запись молчу, которая у SCSI просто дико низкая. Как же тогда сделать высокопроизводительный сервер с такими "тормознутосерверными" SCSI дисками. Я ждат большего. Зачем им тогда 320мб\сек пропускная способность? В чем их серверность?
модель винтов напиши. Может у них и заявленная скорость не блещет.
И еще
Если рейд ставиться с нуля, я бы 0+1 сделал.
нагрузка меньше
Я так понимаю, что модель винтов в RAIDе можно увидеть в RAID конфигурации, т.е надо сервак перезагружать. Пока что никак не сделать. А вот смысл производить медленные SCSI винты, если от них как раз и требуется высокая производительность? В чем тогда их преимущество?
Я имел ввиду то, что раньше винты были медленными. Может просто старые стоят.
модель винта смотреть, как во вложении
далее, скорость работы.
смотри загрузку процов. ошибки в логах, ProcessExplorer-ом от sysinternals проверь, кто вообще систему занимает
И еще глупый вопрос, вообще рейд аппаратный или програмный?
RAID аппаратный, а потому в операционка видит не 4 винта по 36Gb объединенных в RAID, а только один ADAPTEC RAID-5 на 101Gb.
Процессор ничем не занят. Хотя система жутко тормозит при копировании файлов по сети ( мышка тормозит, картинка на экране обновляется с трудом), но загрузка проца при этом показывается 3-4 %, причем в системе 2 проца стоят.
Вот сейчас качаю с сайта Fujitsu дрова, попробую обновить. А так ведь комп-то фирменный, уже три года как работает. Вот я до него только сейчас добрался, пока начальство в отпуске и никто не напрягает.
Начал дрова ставить. Заодно при перезагрузке посмотрел на винты: Seagate ST336706LC rev. 9303 Ultra160 Wide 4 штуки стоят. А пятым устройством какой-то SDR GEM318. Тут тестил прогой HD Tune 2.51. График ужасный (см. вложение).
Какие логи смотреть? Операционки? Так там ничего интересного нет.
А после обновления Firmware Raid контроллера рэйд-массив может слететь? Или же это безболезненная процедура?
А после обновления Firmware Raid контроллера рэйд-массив может слететь? Или же это безболезненная процедура?
ээээ.. сам не делал. Поэтому полюбому резервную копию делай. Благо размер небольшой.
imho из-за такой скорости стоит начальство озадачить что нужен глобальный ремонт.
график ужастный.
imho один из винтов сдыхает
Только начальство пошлет, т.к. у нас бюджетная организация и мне выделяют 20 т.р. на ремонт и техобслуживание всей техники в год. А у меня принтеров 40 шт, копиров 4 больших и 6 маленьких, компов 56 штук. Как понимаешь, особо не разоришься.
тогда, если вопрос организационный.
1. сливать данные с рейд массива
2. или разобрать рейд или проверить через биос.
3. проверять все винты на передмет живучести. в случае обнаружения этот винт на стол начальству, как сувенир
4.1. создавать рейд1 (на 36 гиг) из двух винтов, третий или про запас, или подцеплять без рейда.
4.2. создать рейд 1+0 (72 гига) из четырех винтов. И продолжать искать виновников.
единственное преимущзство raid5 против 1+0 - это больший объем. у тебя это - 36 гиг.
если инфы мало. то нафиг стараться
А чем их проверить по отдельности, т.е. надо какой-то еще комп, в котором SCSI есть и туда их поочередно тыкать? Т.к. через RAID биос такого наверное нет возможности сделать.
Johnnick
насколько знаю, рейд контроллеры повзоляют винты подключать как просто так и рейдом.
Ну я подключу их не рейдом, а данных-то уже не будет на винте, я так понимаю, RAID массив рухнет при подключении дисков не в массиве, а соответственно я даже операционку не смогу загрузить.
Вообще кто систему ставил?
Похоже это было до твоего прихода.
если мои подозрения верны, то система может накрыться. и вопрос отпадет сам собой.
Но я могу и ошибаться
Да, ставили до моего прихода, я не очень давно в этой конторе. Потому и точно ничего сказать не могу. Вот сливаю инфу на другой сервак (для бухгалтерии сам купил на 2х SATA винтах и их в RAID1 объединил). А потом разберу, посмотрю, что хоть за зверь такой за 500 т.р (он нам из Москвы от вышестоящей пришел по такой цене), да еще W2000 Advanced Server к ниму за 250 т.р.
Появилась уже проблема с моим компом. Там Maxtor на 40Gb стоит, 2 сбойных сектора изначально было, но работал нормально. Сегодня вдруг под Windows скорость считывания не более 3 Мб\сек. Запустил прогу MHDD под досом. Читает на скорости до 35 Мб\сек, но выявил 2 бэда и штук 5 секторов с доступом >500ms. Тоже дохнет? Кстати температура винта около 50С. Комп фирменный Fujitsu-Siemens. Система охлаждения по тупому сделана - один 90мм вентилятор на весь системник.
Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd. Перевод: zCarot
Чем можно заниматься в 0 часов 0 минут в Москве? Сидеть за праздничным столом и праздновать? Как бы не так. В этот праздничный миг я хочу поделиться с вами моими сегодняшними изысканиями по тюнингу производительности софтрейда в домашнем сервере. Можно пропустить теорию и сразу читать последний абзац где основная соль.
Посмотрим на скорость:
time sh -c «dd if=/dev/zero of=ddfile bs=1M count=5000»
time sh -c «dd if=ddfile of=/dev/null bs=1M count=5000»
Результаты для моего RAID-6 из 5xWD 1Тб получились следующие: чтение 268МБ/сек, запись 37МБ/сек. Все разводят руками и говорят: ну а чего же вы хотели? RAID-6 тормозит при записи, ведь ему надо прочитать то что было записано раньше, чтобы посчитать обновленные контрольные суммы для всех дисков. А еще и этот bitmap…
Скорость перестройки массива – около 25МБ/сек – полная перестройка массива до 15 часов. Вот он, ваш ночной кошмар.
О роли bitmap
Linux-овый софтрейд поддерживает замечательную фичу: bitmap. Там отмечаются измененные блоки на диске, и если у вас почему-то отвалился один диск из массива, а потом вы его обратно добавили – полная перестройка массива не нужна. Чертовски полезно. Хранить можно на самом рейде – internal, а можно в отдельном файле – но тут есть ограничения (на тип ФС например). Я сделал internal bitmap. И зря. Internal bitmap тормозит безбожно т.к. постоянно дергается головка веников при записи.
О паре мифов софтрейда
1) Он жрет много драгоценного процессора
Если мы одним глазком глянем в исходники драйвера RAID в ядре Linux, то увидем, что там давно все оптимизированно под SSE2. А с SSE2 процессор может считать XOR от 16 байт за 1 такт на 1 ядре современного процессора и все упирается в скорость обмена с памятью. Можете прикинуть сколько % загрузки одного ядра сгенерирует поток в 1Гб/сек :-) А ядер то много :-) На практике, с моим Opteron 165 (1.8Ghz 2 ядра) скорость никогда не упиралась в CPU.
2) Он разваливается и потом хрен соберешь.
Если что-то и отваливается – то из-за железа (например обычные винты любят иногда делать всякие фоновые задачи). Добавление вывалившегося веника – простая операция, которая кроме того может проводится автоматически. Впрочем, в среднем это надо делать раз в год.
mdadm /dev/md0 -a /dev/sde1
3) У софтрейда хреновый мониторинг
С мониторингом все отлично и настраиваемо. Достаточно например просто мыло указать в конфиге mdadm и он пришлет вам письмо если что-то случиться с вашим массивом. Очень удобно )
Вот например что приходит если один веник отвалился:
This is an automatically generated mail message from mdadm running on XXXXX
A DegradedArray event had been detected on md device /dev/md0.
Faithfully yours, etc.
P.S. The /proc/mdstat file currently contains the following:
Personalities: [raid6] [raid5] [raid4]
md0: active raid6 sda1[1] sdc1[4] sdd1[3] sde1[2]
2929683456 blocks super 1.2 level 6, 1024k chunk, algorithm 2 [5/4] [_UUUU]
unused devices: none
Почему RAID-6?
Как известно, RAID-5 выдерживает смерть одного веника, и после этой самой смерти – до момента когда закончится восстановление рейда с новым винчестером ваши данные под угрозой – восстановление обычно занимало до 70 часов для больших массивов и еще один веник может легко умереть в это время.
RAID-6 выдерживает смерть 2-х любых веников. Из минусов – общепризнанное мнение что тормозит, особенно запись, даже по сравнению с RAID-5. Что-ж, проверим.
Решаются проблемы просто:
-
У драйвера рейда в Linux есть такой полезный параметр: stripe_cache_size
значение по умолчанию которого равно 256. Слишком низкое значение – резко снижает скорость записи (как оказалось). Оптимальное значение для многих – 8192. Это — кол-во блоков памяти на 1 диск. 1 блок это обычно 4kb (зависит от платформы), для 5-и дискового массива кеш займет 8192*4кб*5 = 160МБ.
echo 8192 > /sys/block/md0/md/stripe_cache_size
Действовать начинает моментально. Теперь в большинстве случаев драйверу не приходится читать диск перед записью (особенно при линейной записи), и производительность резко вырастает. После перезагрузки пропадает, чтобы не пропало — добавляем в какой-нибуть /etc/rc.local например.
PS. Внимание! Под рутом ходить только на трезвую голову!
PS. В непростой схватке, первый пост на хабре в 2011 году опубликовал все-таки я
PS. infi
Эта проблема наиболее актуальна для аппаратных RAID или firmware RAID (таких как Intel RST RAID 1/10/5/6) с непромышленными SSD.
Особенность SSD
SSD пишут и читают данные страницами, записать можно только на очищенные страницы, а очистить страницы можно только большими блоками. Например, у диска размер страницы 8 КБ, в блоке находится 128 страниц, таким образом, размер блока — 1024 КБ (здесь и далее, если не указано иного, КБ и МБ двоичные).
Например, если изменить 40 КБ в одном файле, то на физическом уровне это будет выглядеть так:
На логическом уровне всё выглядит как обычно — данные будут перезаписаны поверх в соответствующих секторах. Как только в блоке 1 останутся исключительно пустые и готовые для очистки страницы, этот блок стирается и становится пустым целиком.
Чтобы скрыть физическую реализацию, диск поддерживает карту соответствия логических и физических номеров страниц (Flash Translation Layer).
Пока мы видим только один путь, которым физическая страница сможет стать снова очищенной — если на её логический адрес запишут новые данные. Дело в том, что контроллер диска работает на уровне страниц и не знает ничего о файловой системе, а операционная система никак не извещает диск об удалённых файлах, какие секторы могут быть очищены. Несложно видеть, что рано или поздно каждая страница диска будет занята и ему будет некуда писать данные.
Чтобы решить это проблему, была добавлена команда ATA TRIM (wiki). Операционная система посылает её диску с указанием секторов, которые могут быть очищены. Аналоги этой команды — SCSI UNMAP и CF ERASE. К сожалению, в некоторых случаях нет возможности послать её диску:
— если диск находится в RAID с аппаратным контроллером (LSI, Adaptec и т. п.),
— если диски находится в firmware-RAID, в частности, Intel RST RAID 1/10/5/6,
— если диск подключен по USB (ограничение протокола),
— если диск зашифрован программно через TrueCrypt, dm-crypt, GELI и т.п. (может поддерживаться, но обычно не включается по соображениям безопасности).
Если в результате тестирования выясняется, что диск не получает команду TRIM, то вскоре для записи может остаться совсем мало свободных страниц. Но они будут: каждый диск содержит некоторую зарезервированную область, которая служит как запас свободных страниц и запас блоков на замену полностью изношенным. Чтобы узнать размер этой области нужно посмотреть, какой физический объём памяти установлен на диске и сколько LBA указано в документации.
Например, Samsung SSD 840 Pro 512 GB имеет 512 ГБ памяти, при этом доступно 1000215216 LBA секторов. Резерв составляет: 512 × 1024 × 1024 × 1024 — 1000215216 × 512 = 35 ГБ или 6,85 %. Доступная ёмкость диска при этом составляет (512 — 35) × 1024 × 1024 × 1024 = 512 × 10^9 = 512 ГБ, уже десятичных. Samsung SSD 850 Pro 128 ГБ имеет на борту 129 ГБ, пользователю доступно 128 ГБ десятичных, резерв — 7,6 %.
Итак, если мы заполним весь диск, потом удалим все файлы, то без поддержки TRIM диск сможет писать только на какую-то часть от 6,85 % объёма диска. Часть, потому что этот резервный объём будет частично состоять из не полностью пустых блоков из-за фрагментации. Наличие этой области позволяет хоть как-то продолжать перезапись файлов на диске.
Пример худшей ситуации: писать некуда, хотя объём занятых страниц не превышает доступный пользователю без резерва.
В этом случае одновременно с записью работает сборщик мусора, который будет читать блок в оперативную память, стирать блок на диске (долгая операция, стирание занимает 3000 мкс в сравнении с 900 мкс записи в пустую страницу) и записывать блок из оперативной памяти. Задержка происходит также из-за роста Write Amplification — на одну логическую операцию записи приходится 5-10 физических операций записи.
Поэтому чем больше у диска есть свободного места для манёвров, тем выше скорость записи. Сборщик мусора в фоне занимается не только очисткой и дефрагментацией блоков, но и равномерным распределением циклов записи/очистки (P/E) по блокам, чтобы они изнашивались одинаково.
Есть популярный миф, что у современных дисков настолько хороший сборщик мусора, что им не нужен TRIM. Это совершенно не так, сборщик мусора и TRIM решают разные задачи.
Промышленные диски часто имеют 50% и больше резервной области, поэтому для них отсутствие TRIM не критично. Остальные диски чаще всего вообще не имеют явно заявленной резервной области, или она недостаточна. Тесты показывают, что хороший эффект имеет объём over-provisioning 25-29 % от общего объёма физической памяти (включая резервную область). Поэтому если у диска недостаточный объём резервной области, то нужно сделать over-provisioning самостоятельно.
Есть три способа:
— разметить диск таким образом, чтобы оставить некоторую часть неразмеченной области, после создания RAID,
— использовать команду ATA для создания Host protected area (howto), до создания RAID,
— настроить RAID контроллер, чтобы он использовал только часть объёма диска.
Прежде чем выделить свободную область, нужно дать знать диску, что эта область ничем не занята, одним из двух способов:
— подключить диск к другому контроллеру и послать команду ATA TRIM (или при помощи O&O Defrag — есть cli интерфейс, Windows 8 встроенный оптимизатор дисков или Anvil's Storage Utilities),
— сделать полную очистку таблицы FTL, послав команду ATA Secure Erase.
Есть версия, что также можно заставить диск понять, что блоки не используются, если туда записать 0x00 или 0xFF (так называемый метод «Tony TRIM»). Возможно, для каких-то контроллеров это работает, но мои тесты не показали изменений.
На практике
У меня есть два диска Samsung SSD 540 Pro 512 GB в Intel RST RAID 1, на которых установлена Windows 8.1. После года работы я измерил производительность и был неприятно удивлён. После проверки TRIM я увидел, что он не работает.
— Проверка TRIM под Windows,
— Проверка TRIM под Linux:
Колонки DISC-GRAN и DISC-MAX обе должны быть больше 0 для всех участвующих компонентов.
Альтернативный вариант:
После удаления файла на диске должны быть 0x00 или 0xFF, но это недостоверный способ: разные диски ведут себя по-разному.
TRIM в реальном времени включается опцией «discard» при монтировании диска:
TRIM для файловых систем на одиночных дисках и LVM поддерживается с ядра Linux 2.6.33. TRIM для mdraid поддерживается с ядра Linux 3.7. Но может быть портирован и на старые версии ядра, например, поддерживается в CentOS 6.
По-умолчанию Ubuntu делает TRIM по расписанию раз в неделю при помощи fstrim, но только для одиночных дисков (не mdraid) следующих производителей: Intel, Samsung, OCZ, SanDisk и Patriot и если установлен «hdparm».
— Проверка TRIM в FreeBSD:
ZFS по-умолчанию поддерживает TRIM начиная с версии FreeBSD 9.2:
GEOM RAID gmirror поддерживает TRIM с FreeBSD 9.1:
колонка «d/s» — BIO_DELETE/second.
Intel RST RAID поддерживает TRIM только для типа RAID 1, как исключение: для включения нужно убедиться, что драйвер Intel RST версии 11 и выше, и прошивка OROM (Legacy boot) или SataDriver (UEFI boot) версии 11 и выше, или старая версия, но пропатченная. TRIM поддерживается в Intel RSTe RAID 0/1/10 начиная с версии 3.7.0.1093.
Я решил создать неразмеченный раздел диска для over-provisioning.
1. При помощи Acronis Backup я снял образ диска. Также сохранил таблицу разделов (важно иметь первый сектор, последний сектор, GPT тип раздела, GPT уникальный идентификатор, имя раздела).
2. Перезагрузился в BIOS и сделал SSD Secure Erase. Если этого пункта нет в BIOS, то можно выполнить команду при помощи hdparam (или здесь и здесь, есть под Windows), HDDErase или HDAT2.
3. Собрал RAID 1 на двух дисках.
Здесь нужно сделать важное замечание: при инициализации массива RAID-контроллер считывает каждый сектор с одного диска и записывает его на второй. Теоретически это должно помешать всей нашей затее, и на одном диске не будет over-provisioning. Но тесты показали, что этот метод почему-то работает. У меня этому нет объяснений.
4. Загрузился с LiveCD и при помощи GPT fdisk создал нужную таблицу разделов: последний раздел на 104 ГБ меньше, чем раньше. Разделы нужно выравнивать (partition align) по размеру страницы диска, а не по размеру блока.
5. Восстановил из резервной копии каждый раздел.
После этого я полностью заполнил диск и запустил тесты. Это должно показать худший случай. Кеш Windows включён, регулярная запись кеша выключена, Inter RST write-back выключен, все тесты используют область диска фиксированного размера в 40 ГБ. Тестировать диски непросто, поскольку показатели могут меняться во времени. Ниже сведены показатели установившегося состояния.
Я сравню три состояния:
— Один диск без RAID, полностью заполненный, стандартная скрытая резервная область 6,58 %.
— Один диск без RAID, после запуска на нём TRIM свободного места.
— Два диска в RAID 1, полностью заполненные, стандартная скрытая резервная область 6,58 %.
— Два диска в RAID 1, полностью заполненные, over-provisioning 27,24 % (включая скрытую резервную область).
Анализ результатов:
— чтение с RAID 1 оказывается быстрее, чем с одного диска, невзирая на то, что у нас всего лишь firmware RAID.
— запись тем быстрее, чем больше нераспределенного пространства: на первом месте TRIM, на втором — наш самодельный over-provisioning.
Установившееся состояние не всегда достигается быстро. Посмотрим тест последней конфигурации (over-provisioning 27,24 %) в динамике и увидим худший случай:
Любопытный процесс идёт первые 400 секунд, после чего производительность возрастает и стабилизируется. Я думаю, параллельно с записью работает сборщик мусора, который дефрагментирует блоки и подготавливает их для записи. Такое поведение наблюдается не каждый раз, а время от времени. Видно, что последовательная запись проседает до 70 МБ/с, случайная запись — до 18000 IOPS. Эти показатели всё равно в два раза лучше, чем без over-provisioning (32 МБ/с и 7139 IOPS соответственно). Чтобы убедиться, что установившееся состояние на самом деле имеет такую высокую производительность, я также выполнил тест в течении 30 минут, при этом было записано на диск 490 ГБ со средним 69721 IOPS.
Кратко
— Если диск получает ATA TRIM от ОС, то беспокоиться не о чем, достаточно оставлять часть места на диске свободным.
— Если используются дорогие промышленные диски, то проверьте объём встроенной резервной области, если он достаточен, то проблем с записью не будет.
— В остальных случаях нужно оставить не размеченную область, чем больше её размер, тем меньше будет стандартное отклонение латентности записи.
— Иногда сборщик мусора не успевает подготовить чистые блоки и скорость записи может просесть и быть непостоянной.
— После over-provisioning установившаяся максимальная скорость записи повысилась с 7000 до 68000 IOPS, а средняя минимальная — с 6000 IOPS до 19000 IOPS.
Всем привет. Арендовал сервер, поставил proxmox и сделал из 2х SSD дисков raid1 на zfs. Диски использую как thin provision. Поставил оффтопики и заметил что при копировании файлов внутри дисков сервер начинает виснуть. Копирую с ftp так что скорость не больше 20 - 30 мбайт/с. Может что то упустил в настройках ?
Сжатия нет, дедупликации нет.
Что за ssd? На сколько заполнены?
Аргументы будут, дядя?
• ZFSautomaticallyadjustsblocksize • ZFS blocksize can be tuned on a per‐file‐system basis (the “recordsize” property) • Tuning the blocksize will not help with sequential workloads, due to prefetch • Tuning the blocksize is most helpful with applications perform mostly random I/O • Tuningtheblocksizemayaffecttheamountof metadata in a pool • If in doubt, don’t tune the blocksize
SSD - Crucial_CT500MX200SSD1
Наполовину только заполнены
забей на ZoL, сделай mdraid1, поставь все на xfs и scheduler noop.
это крайний случай, пока с zfs попробую разобраться
хз, это сервер у хецнера на 49 евро в месяц
В посте-то ересь какая-то написана, но таки на диски попадают порции по recordsize/кол-во_data_vdev.
Ну блин, smartctl -a /dev/sdX.
По выборе размера Блока для затаскивав исходить нужно из потребности приложений, а не количества дисков в нем. Согласно твоей высосанной из пальца теории, я придобаалении к двум зеркалам ещё двух зеркал должен что-ли резко размер блока уменьшать? Если ты в исходники не заглядывал и черпаешь свои «познания» невесть откуда - то так и пиши.
При выборе геометрии пула тоже нужно учитывать, что будет за нагрузка. А то задолбали уже деятели, которые из всех дисков один raidz топ-левел сделают, gzip9 включат, ни одного slog'a не добавят, советов vxzvxz начитаются, а потом плачутся, как у них их зада банных медленно работает и как у ZFS плохо с параллельными вводом/выводом.
Анонимус и без тебя неплохо знает, как raidz_map_t устроена
Исключительно в целях ликбеза несведущих.
=== START OF INFORMATION SECTION ===
Device Model: Crucial_CT500MX200SSD1
Serial Number: 154410F5E528
LU WWN Device Id: 5 00a075 110f5e528
Firmware Version: MU02
User Capacity: 500,107,862,016 bytes [500 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-3 T13/2161-D revision 4
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Thu Mar 3 15:27:35 2016 EET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF INFORMATION SECTION ===
Device Model: Crucial_CT500MX200SSD1
Serial Number: 154410F5D1F9
LU WWN Device Id: 5 00a075 110f5d1f9
Firmware Version: MU02
User Capacity: 500,107,862,016 bytes [500 GB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-3 T13/2161-D revision 4
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Thu Mar 3 15:27:51 2016 EET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Здравствуйте.
Есть сервер Fujitsu-Siemens Primergy 200 (2хPIII 1266Mhz, 1Gb RAM). Установлена плата Adaptec 2100S Ultra3 SCSI. Настроен RAID-5 на 4-х дисках Seagate 36Gb. WriteBack отключен. ОС Windows 2000 Server SP4. Скорость чтения с диска от 5 до 30 мб\сек. Запись - 6 мб\сек. Почему так медленно?
RAID 5, действительно, самый популярный из уровней – в первую очередь благодаря своей экономичности. Жертвуя ради избыточности емкостью всего одного диска из массива, мы получаем защиту от выхода из строя любого из винчестеров тома. На запись информации на том RAID5 тратятся дополнительные ресурсы, так как требуются дополнительные вычисления, зато при чтении (по сравнению с отдельным винчестером) имеется выигрыш, потому что потоки данных с нескольких накопителей массива распараллеливаются.
Недостатки RAID5 проявляются при выходе из строя одного из дисков – весь том переходит в критический режим, все операции записи и чтения сопровождаются дополнительными манипуляциями, резко падает производительность, диски начинают греться. Если срочно не принять меры – можно потерять весь том. Поэтому, (см. выше) с томом RAID5 следует обязательно использовать диск Hot Spare.
На запись информации на том RAID5 тратятся дополнительные ресурсы, так как требуются дополнительные вычисления, [/b]зато при чтении (по сравнению с отдельным винчестером) имеется выигрыш, потому что потоки данных с нескольких накопителей массива распараллеливаются..
Я вот не понял в чем выигрыш? У меня IDE Seagate 80Gb читает быстрее, чем этот SCSI RAID-5. Я уж про запись молчу, которая у SCSI просто дико низкая. Как же тогда сделать высокопроизводительный сервер с такими "тормознутосерверными" SCSI дисками. Я ждат большего. Зачем им тогда 320мб\сек пропускная способность? В чем их серверность?
модель винтов напиши. Может у них и заявленная скорость не блещет.
И еще
Если рейд ставиться с нуля, я бы 0+1 сделал.
нагрузка меньше
Я так понимаю, что модель винтов в RAIDе можно увидеть в RAID конфигурации, т.е надо сервак перезагружать. Пока что никак не сделать. А вот смысл производить медленные SCSI винты, если от них как раз и требуется высокая производительность? В чем тогда их преимущество?
А вот смысл производить медленные SCSI винты,
Я имел ввиду то, что раньше винты были медленными. Может просто старые стоят.
модель винта смотреть, как во вложении
далее, скорость работы.
смотри загрузку процов. ошибки в логах, ProcessExplorer-ом от sysinternals проверь, кто вообще систему занимает
И еще глупый вопрос, вообще рейд аппаратный или програмный?
RAID аппаратный, а потому в операционка видит не 4 винта по 36Gb объединенных в RAID, а только один ADAPTEC RAID-5 на 101Gb.
Процессор ничем не занят. Хотя система жутко тормозит при копировании файлов по сети ( мышка тормозит, картинка на экране обновляется с трудом), но загрузка проца при этом показывается 3-4 %, причем в системе 2 проца стоят.
Хотя система жутко тормозит при копировании файлов по сети
Это очень неправильно. туда рыть надо
ProcessExplorer-ом от sysinternals проверь, кто вообще систему занимает
imho проблемы с железом.
может дров нет, может еще чего
Вот сейчас качаю с сайта Fujitsu дрова, попробую обновить. А так ведь комп-то фирменный, уже три года как работает. Вот я до него только сейчас добрался, пока начальство в отпуске и никто не напрягает.
А так ведь комп-то фирменный, уже три года как работает
В логах что?
Vanya1156837339
уже три года как работает.
Недостатки RAID5 проявляются при выходе из строя одного из дисков
надо проверить винты (скорее всего через сам рейд контроллер)
Начал дрова ставить. Заодно при перезагрузке посмотрел на винты: Seagate ST336706LC rev. 9303 Ultra160 Wide 4 штуки стоят. А пятым устройством какой-то SDR GEM318. Тут тестил прогой HD Tune 2.51. График ужасный (см. вложение).
Какие логи смотреть? Операционки? Так там ничего интересного нет.
Johnnick1156838377
А после обновления Firmware Raid контроллера рэйд-массив может слететь? Или же это безболезненная процедура?
А после обновления Firmware Raid контроллера рэйд-массив может слететь? Или же это безболезненная процедура?
ээээ.. сам не делал. Поэтому полюбому резервную копию делай. Благо размер небольшой.
imho из-за такой скорости стоит начальство озадачить что нужен глобальный ремонт.
график ужастный.
imho один из винтов сдыхает
Только начальство пошлет, т.к. у нас бюджетная организация и мне выделяют 20 т.р. на ремонт и техобслуживание всей техники в год. А у меня принтеров 40 шт, копиров 4 больших и 6 маленьких, компов 56 штук. Как понимаешь, особо не разоришься.
тогда, если вопрос организационный.
1. сливать данные с рейд массива
2. или разобрать рейд или проверить через биос.
3. проверять все винты на передмет живучести. в случае обнаружения этот винт на стол начальству, как сувенир
4.1. создавать рейд1 (на 36 гиг) из двух винтов, третий или про запас, или подцеплять без рейда.
4.2. создать рейд 1+0 (72 гига) из четырех винтов. И продолжать искать виновников.
Vanya1156840819
единственное преимущзство raid5 против 1+0 - это больший объем. у тебя это - 36 гиг.
если инфы мало. то нафиг стараться
А чем их проверить по отдельности, т.е. надо какой-то еще комп, в котором SCSI есть и туда их поочередно тыкать? Т.к. через RAID биос такого наверное нет возможности сделать.
Johnnick
насколько знаю, рейд контроллеры повзоляют винты подключать как просто так и рейдом.
Т.к. через RAID биос такого наверное нет возможности сделать.
Не факт
Ну я подключу их не рейдом, а данных-то уже не будет на винте, я так понимаю, RAID массив рухнет при подключении дисков не в массиве, а соответственно я даже операционку не смогу загрузить.
а соответственно я даже операционку не смогу загрузить.
мда. действительно
Вообще кто систему ставил?
Похоже это было до твоего прихода.
если мои подозрения верны, то система может накрыться. и вопрос отпадет сам собой.
Но я могу и ошибаться
Да, ставили до моего прихода, я не очень давно в этой конторе. Потому и точно ничего сказать не могу. Вот сливаю инфу на другой сервак (для бухгалтерии сам купил на 2х SATA винтах и их в RAID1 объединил). А потом разберу, посмотрю, что хоть за зверь такой за 500 т.р (он нам из Москвы от вышестоящей пришел по такой цене), да еще W2000 Advanced Server к ниму за 250 т.р.
Появилась уже проблема с моим компом. Там Maxtor на 40Gb стоит, 2 сбойных сектора изначально было, но работал нормально. Сегодня вдруг под Windows скорость считывания не более 3 Мб\сек. Запустил прогу MHDD под досом. Читает на скорости до 35 Мб\сек, но выявил 2 бэда и штук 5 секторов с доступом >500ms. Тоже дохнет? Кстати температура винта около 50С. Комп фирменный Fujitsu-Siemens. Система охлаждения по тупому сделана - один 90мм вентилятор на весь системник.
Тоже дохнет?
Ессно, 50С многовато будет для харда
Фирменные компы - Г. (если не спец заказ) - работают четко до окончания гарантии,
погрешность +- неделя
Винт Maxtor заработал нормально. Глюканули дрова на IDE контроллер. Переставил - заработало. Но график чтения все также не ровный, с падениями до 2мб\сек. Но средняя скорость стала 24мб\сек.
Вот мож такая же фигyя с RAID? Переставить дрова?
Johnnick
Попробуй график в минимальной загрузке компа проверить.
Т.е. сеть выдернуть, все проги закрыть, все ненужные сервисы поотрубать (антивирус, indexservice, sql и т.п.)
(дверь и окна тоже можно закрыть)
Почему софтрейд?
Железный рейд нужен только в одном случае – если у него есть батарейка и набортный кеш. Тогда контроллер сразу отвечает ОС что запись на диск завершена на физическом уровне и всякие ACID базы работают очень быстро и безопасно.
В остальных случаях никаких бонусов по сравнению с софт-рейдом нет, одни минусы:
1) Сгорело железо? Новый сервер? Будьте добры купить тот же контроллер, ну или молитесь о совместимости. Софтрейд из тех-же дисков собирается где угодно.
2) Цена :-) Собственно, из-за этого нормальных рейдов с батарейкой я в руках так ниразу и не держал :-)
Ну а те «рейд-контроллеры» которые стоят на обычных материнских платах – вообще никогда не стоит использовать. Они просто дают грузить ОС с рейда за счет набортного биоса (который выполняется центральным процессором, своего процессора нет), на этом их польза заканчивается, и остаются только минусы.
Читайте также: