Comments 107
Показатели впечатляют.
Но цена… Intel SSD 910 400GB $2000
Но цена… Intel SSD 910 400GB $2000
Ну, это совсем недорого. :)
Просто для понимания, эквивалентное количество жёстких дисков будет стоить примерно $100k (1000 шт), и это без учёта того, где эти диски будут размещаться и куда подключаться.
Пара таких железок в кеширующем режиме (или одна, но свёрнутая в raid1) обеспечивает практически неограниченную производительность дисковой подсистемы для сервера.
Пара таких железок в кеширующем режиме (или одна, но свёрнутая в raid1) обеспечивает практически неограниченную производительность дисковой подсистемы для сервера.
насколько помню, при использовании правильных рейзеров hotswap и hotplug для PCI-e в стандарте заложено.
cateee.net/lkddb/web-lkddb/HOTPLUG_PCI_PCIE.html
cateee.net/lkddb/web-lkddb/HOTPLUG_PCI_PCIE.html
откуда взялось $100k за 1000штук? Можете по подробнее расписать расчеты?
$100k за 1000штук / 1000 = $100 за 1штуку
100 IOPS'ов на диск. Это при том, что у диска latency будет на полтора порядка выше, чем у SSD. Дальше считайте сами, сколько нужно дисков для 100к IOPS.
по сравнению с FusionIO устройствами — не очень…
А вот цена — Я бы сказал что неплохо.
А вот цена — Я бы сказал что неплохо.
Я не щупал FusionIO, есть вероятность, что они попугаи считают с большой очередью (то есть завышенной latency, благо пока что большинство пользователей благосклонно смотрят как на latency в 0.1мс, так и в 0.3мс).
www.solidstateworks.com/ioDrive-Octal.asp
насколько Я знаю там µs по average, также как и IOPS.
насколько Я знаю там µs по average, также как и IOPS.
UFO just landed and posted this here
У вас SSD на запись на VPS-ках???
На сколько лет ресурса хватает?
На сколько лет ресурса хватает?
По наблюдению за intel 320, которые у нас в продакте год были, износ составил
233 Media_Wearout_Indicator 0x0032 086 086 000 Old_age Always — 0
Другими словами, около 14% в год. И это в режиме весьма плотной записи почти непрерывно. Но 320 мы готовили правильно (то есть 20% места в резерв для housekeeping'а).
233 Media_Wearout_Indicator 0x0032 086 086 000 Old_age Always — 0
Другими словами, около 14% в год. И это в режиме весьма плотной записи почти непрерывно. Но 320 мы готовили правильно (то есть 20% места в резерв для housekeeping'а).
Только RAID6, только хардкор. В отличие от RAID10 — при том же объёме, сдохнуть могут любые два из 100G, а не только два из разных пар. Правда, производительность упадёт в 4 раза, но мы не ищем лёгких путей!
Не имеет смысла, у вас все равно остается единая точка отказа- сам контроллер. Вероятность выходя из строя модулей памяти значительно ниже (IMHO).
Выход из строя контроллера — random величина.
Выход из строя модуля памяти — запланированная, и растущая с возрастом.
Выход из строя модуля памяти — запланированная, и растущая с возрастом.
запланированная=>> значит не аварийная, можно заранее подготовиться. А вот контроллер у вас отвалится внезапно, что еще раз подтверждает мои слова.
Вы же сами не далее как вчера писали, что не использовать реид из ссд карт крайне плохо из-за возможности умирания контроллера SSD. Или предполагаете, что LSI контроллер существенно надёжней?
здесь 4 контроллера SSD от Hitachi + 1 PCI-E<=>SAS контроллер от LSI.
Да, но его, на сколько я понимаю, всё равно не поменять отдельно от ssd — всё припаяно.
его надёжность таки выше — ибо его функции проще.
а по надежноти SSD: habrahabr.ru/post/133924/
а по надежноти SSD: habrahabr.ru/post/133924/
Кстати, вы задали очень интересный вопрос.
У меня одна штука есть в лаборатории, сейчас посмотрю, что там будет в raid6 силами линукса.
У меня одна штука есть в лаборатории, сейчас посмотрю, что там будет в raid6 силами линукса.
Весьма интесно. Я живьём Raid6 не щупал, но как понимаю, производительность минимум втрое ниже, чем отдельного диска.
Это при 4-х дисках? А если больше?
С чего-это производительности быть меньше, чем одного диска?
Сижу дома на RAID-6 из 8 дисков уже года 2 (диски «зеленые», ~60Мб/сек).
Вот результаты линейного чтения/записи (файл вдвое больше размера памяти):
Запись — 141 MB/s
Чтение — 359 MB/s
Случайный доступ / IOPS — не медленнее самого медленного диска.
Сижу дома на RAID-6 из 8 дисков уже года 2 (диски «зеленые», ~60Мб/сек).
Вот результаты линейного чтения/записи (файл вдвое больше размера памяти):
Запись — 141 MB/s
Чтение — 359 MB/s
Случайный доступ / IOPS — не медленнее самого медленного диска.
потому что запись идёт на 3 диска а не на 1.
соответственно, при RAID0 вероятность конфликта на Random Write будет 1/N где N — число дисков, а у RAID6 — 3/N.
то есть на 8 дисках, В 37.5% случаев запись встанет в очередь.
ну и да, я немного не прав, когда сравниваю с «одним». имеется ввиду по сравнению с «RAID0»
соответственно, при RAID0 вероятность конфликта на Random Write будет 1/N где N — число дисков, а у RAID6 — 3/N.
то есть на 8 дисках, В 37.5% случаев запись встанет в очередь.
ну и да, я немного не прав, когда сравниваю с «одним». имеется ввиду по сравнению с «RAID0»
При наличии write-back не имеет значения на сколько дисков идёт запись. Она происходит для пользователя моментально, если объём записываемых данных помещается в кеш.
У меня записывается 800mb за пару секунд при размере кэша в 512mb на raid5 из старых медленных дисков.
У меня записывается 800mb за пару секунд при размере кэша в 512mb на raid5 из старых медленных дисков.
никого не интересует производительность «когда влезает в кеш», интересует производительность худшего случая — когда все кеши пробиваются (например, помирает батарейка в рейде) и наступает полный коллапс.
Худший случай — это отключение питания в датацентре. Как пару лет назад было в Москве. И не спасёт вообще ничего.
Разница в производительности с write-back и без него в сотню раз, примерно.
Я пришёл к выводу, что наиболее эффективное решение по соотношениям ёмкость, цена, скорость и надёжность — это аппаратный рейд с большим кешем + батарейкой или суперконденсатором + flash (Z), плюс сервак с офигенной оперативкой.
В большинстве случаев выгоднее вкладывать в оперативку (кеширование на чтение и тот же write-back только средствами ядра), чем в SSD.
Оперативка за 1 Гб стоит в 1,8 раза дороже SSD, но при этом, как минимум, в 10 000 раз быстрее и имеет неограниченный ресурс перезаписи. Довольно логично выбирать её для апгрейда, а не новый SSD. Минусы такой системы — медленный старт, что для серверов не критично.
А если добавить индивидуальный UPS от 100 долларов, то вообще шоколад. Кстати имея UPS можно сэкономить на батарейке рейда. Главное, чтобы UPS подавал серверу сигнал на выключение, если нет питания.
Редко встречаются приложения, которые постоянно генерируют столько данных на запись, сколько хотя бы треть линейной скорости записи нормального рейд-массива. Write-back как раз оптимизирует случайную запись, что примерно треть-половина от линейной скорости массива на запись получается.
На моём продакшен сервере до фига данных на запись на постоянной основе генерирует только бакап. Но он делается на отдельную дисковую подсистему мимо write-back кеша raid-контролера.
Разница в производительности с write-back и без него в сотню раз, примерно.
Я пришёл к выводу, что наиболее эффективное решение по соотношениям ёмкость, цена, скорость и надёжность — это аппаратный рейд с большим кешем + батарейкой или суперконденсатором + flash (Z), плюс сервак с офигенной оперативкой.
В большинстве случаев выгоднее вкладывать в оперативку (кеширование на чтение и тот же write-back только средствами ядра), чем в SSD.
Оперативка за 1 Гб стоит в 1,8 раза дороже SSD, но при этом, как минимум, в 10 000 раз быстрее и имеет неограниченный ресурс перезаписи. Довольно логично выбирать её для апгрейда, а не новый SSD. Минусы такой системы — медленный старт, что для серверов не критично.
А если добавить индивидуальный UPS от 100 долларов, то вообще шоколад. Кстати имея UPS можно сэкономить на батарейке рейда. Главное, чтобы UPS подавал серверу сигнал на выключение, если нет питания.
Редко встречаются приложения, которые постоянно генерируют столько данных на запись, сколько хотя бы треть линейной скорости записи нормального рейд-массива. Write-back как раз оптимизирует случайную запись, что примерно треть-половина от линейной скорости массива на запись получается.
На моём продакшен сервере до фига данных на запись на постоянной основе генерирует только бакап. Но он делается на отдельную дисковую подсистему мимо write-back кеша raid-контролера.
Сколько RAM сейчас используете?
facepalm.
Если бы упс спасал от kernel panic'а…
Да и вообще, речь о другом идёт. Если вы используете wb модель за пределами FS, то любое повреждение кеша (питание ли, падение сервера, отказ памяти/ssd) приводит к необративому и неуправляемому повреждению данных (в сравнении с этим файловый кеш на журналируемых файловых системах по крайней мере мета-данные сохраняет).
Таким образом, следует разделять «переживающий падение кеш» и «не переживающий». И это очень сильно меняет отношение к нему с точки зрения применимости. Главное достоинство рейда из SSD, что он всё-таки non-volative.
Если бы упс спасал от kernel panic'а…
Да и вообще, речь о другом идёт. Если вы используете wb модель за пределами FS, то любое повреждение кеша (питание ли, падение сервера, отказ памяти/ssd) приводит к необративому и неуправляемому повреждению данных (в сравнении с этим файловый кеш на журналируемых файловых системах по крайней мере мета-данные сохраняет).
Таким образом, следует разделять «переживающий падение кеш» и «не переживающий». И это очень сильно меняет отношение к нему с точки зрения применимости. Главное достоинство рейда из SSD, что он всё-таки non-volative.
3 случая потери wb-кеша на контроллере, которые вы привели:
1) питание
лечится батарейкой в рейд, а лучше суперконденсатором + flash
2) kernel panic
лечится батарейкой в рейд + как вы сказали «файловый кеш на журналируемых файловых системах по крайней мере мета-данные сохраняет»
3) отказ памяти
у ECC RAM такого на практике не бывает. Ну у меня не было. Не слышал, чтобы RAM горела, если её не трогать. А вот для SSD это постоянно происходит. Причём может произойти синхронно на нескольких SSD, так как у них очень сходные характеристики
вероятность поломки кеша с суперконденсатором микроскопична.
1) питание
лечится батарейкой в рейд, а лучше суперконденсатором + flash
2) kernel panic
лечится батарейкой в рейд + как вы сказали «файловый кеш на журналируемых файловых системах по крайней мере мета-данные сохраняет»
3) отказ памяти
у ECC RAM такого на практике не бывает. Ну у меня не было. Не слышал, чтобы RAM горела, если её не трогать. А вот для SSD это постоянно происходит. Причём может произойти синхронно на нескольких SSD, так как у них очень сходные характеристики
вероятность поломки кеша с суперконденсатором микроскопична.
Вообще, вы с amarao говорите о совершенно разных вещах.
inetstar — об оптимизации некоего своего сервера.
amarao — о СХД.
у них разные требования к надёжности и производительности системы.
разговаривая о СХД речь идёт об исключительной надёжности, и производительности только в худшем случае.
разговария об оптимизации своего сервера можно идти на допущения, типа «рамы хватит», «батарейки рейда хватит», «если упадёт, база ACID, восстановится».
я на днях буквально видел — навернулся рейд1, на двух разделах ext3 в полную кашу, xfs в плохом состоянии, на третьем — отдельный раздел под postgresql, там xfs не монтировался и не чекался, но запуск без лога позволил тупо слить файло «в неком состоянии» на новые диски. и этого хватило — база поднялась, недостатки залили из бакапа.
вот поэтому amarao и говорит, что НЕТ методики рассета. её действительно нет.
ибо гадание на кофейной гуще «раза в 4 больше хватит всем» — что хватало на своих задачах, но соовсем не то, что позволяет оценить худший случай когда на СХД неизвестно и не может быть никогда известна.
inetstar — об оптимизации некоего своего сервера.
amarao — о СХД.
у них разные требования к надёжности и производительности системы.
разговаривая о СХД речь идёт об исключительной надёжности, и производительности только в худшем случае.
разговария об оптимизации своего сервера можно идти на допущения, типа «рамы хватит», «батарейки рейда хватит», «если упадёт, база ACID, восстановится».
я на днях буквально видел — навернулся рейд1, на двух разделах ext3 в полную кашу, xfs в плохом состоянии, на третьем — отдельный раздел под postgresql, там xfs не монтировался и не чекался, но запуск без лога позволил тупо слить файло «в неком состоянии» на новые диски. и этого хватило — база поднялась, недостатки залили из бакапа.
вот поэтому amarao и говорит, что НЕТ методики рассета. её действительно нет.
ибо гадание на кофейной гуще «раза в 4 больше хватит всем» — что хватало на своих задачах, но соовсем не то, что позволяет оценить худший случай когда на СХД неизвестно и не может быть никогда известна.
У меня есть интуитивное подозрение, что теоретически можно как-то рассчитывать размер хотспота. Или даже не хотспота, а рационального кеша под скорость шпинделей (кеш такого размера, что его дальнейший рост не сильно улучшает производительность системы).
Но я даже не очень понимаю, как на продакт-системе посмотреть размер хотспота (без привлечения debugfs), а уж рассчёты…
Но я даже не очень понимаю, как на продакт-системе посмотреть размер хотспота (без привлечения debugfs), а уж рассчёты…
а на тему kernel panic'а… был у меня в юности негативный опыт. ext3, аппараный рейд, ядро по-моему 2.4.22 или .26.
обычный такой рабочий сервачок со стартапом, база в мускуле, сайтик на пыхе, всё крутится, всё работает.
был словлен kernel panic. После ребута — файловая система в кашу. Просто, в невосстановимую кашу. Причем спасибо аппаратному рейду — эта каша была заботливо отзеркалирована.
Восстанавливать было нечего (копался я глубоко и долго).
обычный такой рабочий сервачок со стартапом, база в мускуле, сайтик на пыхе, всё крутится, всё работает.
был словлен kernel panic. После ребута — файловая система в кашу. Просто, в невосстановимую кашу. Причем спасибо аппаратному рейду — эта каша была заботливо отзеркалирована.
Восстанавливать было нечего (копался я глубоко и долго).
По поводу третьего — multi-bit ecc, примерно два десятка случаев отказа в год. На загруженном парке серверов, разумеется.
Слёт содержимого wb на кондёре у адаптека я наблюдал. 5ая серия (на тот момент топовая), 2011 год.
Слёт содержимого wb на кондёре у адаптека я наблюдал. 5ая серия (на тот момент топовая), 2011 год.
А реально фичи вроде зеркалирования памяти на чипсете серии intel 5000 используются?
И вообще — есть ли рейд в этой карте: можно ли менять SSD?
Если использовать raid0, то вероятность вылета этой карты увеличивается в 4 раза по сравнению с одиночным SSD. Что ужасно и неприемлемо.
Если менять на лету нельзя и нет средств оповещения о вылете, то это напрасная трата денег: в любой момент сервер может встать с потерей данных.
Если использовать raid0, то вероятность вылета этой карты увеличивается в 4 раза по сравнению с одиночным SSD. Что ужасно и неприемлемо.
Если менять на лету нельзя и нет средств оповещения о вылете, то это напрасная трата денег: в любой момент сервер может встать с потерей данных.
Это очень наивное представление. Поясняю почему.
Предположим, у вас есть кеш на 512мб, блок 4к, итого, 128k записей (забываем про метаданные). Само кешируемое устройство может обслуживать не более 500 случайных записей (полагаем, что последовательно образовавшиеся блоки будут писаться за то же время, что и один блок, в грубом приближении это допустимо).
Вы ставите его в продакт. Первое время вы имеете random write равной линейной скорости записи в кеш. Потом ситуация меняется — кеш-то нужно flush'ить.
А то, как флашится кеш определяется тем, насколько оный кеш может покрыть hotspot'ы, то есть какой коэфицент «повторных записей» объединяет кеш. Допустим, он становится равным 20. Это безумно высокий показатель, но, допустим.
Итого, мы можем флашить 500 записей в секунду. При коэфиценте 20, это значит, что кеш может обрабатывать 10000 записей в секунду.
Вроде бы всё хорошо, правда? Вы ставите на него нагрузку в 8к IOPS и жизнь хороша… А дальше вам в какой-то момент времени входит пачка random IO на запись. Не попадающая под «повторные записи». И, внезапно, коэфицент падает до двух, и оказывается, что производительность массива — 1000 IOPS на запись.
И я не видел ни одного вменяемого интегратора/администратора/проектировщика, кто бы взялся более-менее предсказывать размер хотспотов.
… А не забываем про ледяные данные (которые читаются раз в сутки).
Предположим, у вас есть кеш на 512мб, блок 4к, итого, 128k записей (забываем про метаданные). Само кешируемое устройство может обслуживать не более 500 случайных записей (полагаем, что последовательно образовавшиеся блоки будут писаться за то же время, что и один блок, в грубом приближении это допустимо).
Вы ставите его в продакт. Первое время вы имеете random write равной линейной скорости записи в кеш. Потом ситуация меняется — кеш-то нужно flush'ить.
А то, как флашится кеш определяется тем, насколько оный кеш может покрыть hotspot'ы, то есть какой коэфицент «повторных записей» объединяет кеш. Допустим, он становится равным 20. Это безумно высокий показатель, но, допустим.
Итого, мы можем флашить 500 записей в секунду. При коэфиценте 20, это значит, что кеш может обрабатывать 10000 записей в секунду.
Вроде бы всё хорошо, правда? Вы ставите на него нагрузку в 8к IOPS и жизнь хороша… А дальше вам в какой-то момент времени входит пачка random IO на запись. Не попадающая под «повторные записи». И, внезапно, коэфицент падает до двух, и оказывается, что производительность массива — 1000 IOPS на запись.
И я не видел ни одного вменяемого интегратора/администратора/проектировщика, кто бы взялся более-менее предсказывать размер хотспотов.
… А не забываем про ледяные данные (которые читаются раз в сутки).
кэш на 512MB в продакшене — Вы наверное шутите, тут минимум 1GB нужен.
кстати для примера проще использовать несколько уровней кэширования
2GB (OS Cache) + 2GB (RAID Cache) + 3xRAID5 120GB (SSD Cache) = основная дисковая подсистема
кстати для примера проще использовать несколько уровней кэширования
2GB (OS Cache) + 2GB (RAID Cache) + 3xRAID5 120GB (SSD Cache) = основная дисковая подсистема
Тут надо просто переставать меряться понтовостью слова «продакт» и говорить про цифры. Так вот: я не знаю адекватной методологии рассчёта хотспот области (читай — размер кеша).
Давайте — обычно размер идет по принципу.
Кэш = 2 * локальный кэш диска в RAID (обычно 64MB) * N (число дисков в RAID)
Берем пример для 4 дисков = 2 * 64MB * 4 = 512MB
Учитывая что будет интенсивная нагрузка на запись то берем двойное значение — т.е. 512MB*2 = 1024MB это и есть нужное значение.
Кэш = 2 * локальный кэш диска в RAID (обычно 64MB) * N (число дисков в RAID)
Берем пример для 4 дисков = 2 * 64MB * 4 = 512MB
Учитывая что будет интенсивная нагрузка на запись то берем двойное значение — т.е. 512MB*2 = 1024MB это и есть нужное значение.
Нужное значение для чего? Я вполне серьёзно спрашиваю, потому что ваш метод никаким образом не отвечает на вопрос о размере хотспота.
Это расчет брался по реальному проекту для Xen:
(1) Redis (в качестве кэша)
(2) PerconaDB (интенсивный транзакции)
(3) MongoDB
(4) 3 x nginx (highload)
(5) 3 x CentOS — служебные машины
В этом конфиге все очень даже хорошо.
(1) Redis (в качестве кэша)
(2) PerconaDB (интенсивный транзакции)
(3) MongoDB
(4) 3 x nginx (highload)
(5) 3 x CentOS — служебные машины
В этом конфиге все очень даже хорошо.
Я честно сдерживаюсь, но мне хочется сказать много нехорошего.
Рассчёт чего? Какие цифры вы брали за входные, какие цифры пытались рассчитать? То, что эта штука у вас «работает», означает, что вы всего лишь не вышли за нижнюю границу.
Самой методики нет, методов проверки — нет.
Повторю ещё раз: каким образом вы рассчитываете размер хотспота и откуда берёте данные для рассчёта? Простите, считать за адекватную методологию «количество запущенных монго» я отказываюсь.
Рассчёт чего? Какие цифры вы брали за входные, какие цифры пытались рассчитать? То, что эта штука у вас «работает», означает, что вы всего лишь не вышли за нижнюю границу.
Самой методики нет, методов проверки — нет.
Повторю ещё раз: каким образом вы рассчитываете размер хотспота и откуда берёте данные для рассчёта? Простите, считать за адекватную методологию «количество запущенных монго» я отказываюсь.
кеша на 512 метров в продакте хватает нам за глаза на сервере с бд, на более слабых — вообще 256.
и они 100% на write, на read — покрываются OS Cache.
и всё равно, производительность меряется когда WB кеш не работает, иначе в один не прекрасный день можно сильно удивиться.
и они 100% на write, на read — покрываются OS Cache.
и всё равно, производительность меряется когда WB кеш не работает, иначе в один не прекрасный день можно сильно удивиться.
write cache файловой системы не касается файлов, открытых в direct режиме, а так же злоупотребления flush (так любят БД поступать, именно потому поток ужасного рандома называют OLAP).
я говорю про WB кеш, Battery-Backed на рейд контроллере.
файловый Write-Cache — только объеденить кучу строк лога в один write, на базах и не пахнет им конечно же.
это опять же к слову о том, что на OS-Cache палагаться на write низя.
файловый Write-Cache — только объеденить кучу строк лога в один write, на базах и не пахнет им конечно же.
это опять же к слову о том, что на OS-Cache палагаться на write низя.
смотря для каких БД — поскольку для некоторых (single file) можно вообще отдать блочное устройство и тогда не иметь проблем с накладными расходами от файловой системы.
P.S. при условии что:
— БД действительно может работать в таком режиме
— БД будет занимать меньше места чем размер блочного устройства
P.S. при условии что:
— БД действительно может работать в таком режиме
— БД будет занимать меньше места чем размер блочного устройства
… Я начал мерять, там работы очень много, так что результат ждите через несколько дней отдельной статьёй. Но результаты получаются крайне любопытные.
Как захотелось raidz на этом деле поднять :)
z?
RAID-Z
если я правильно понял ваш вопрос.
И да, я бы тоже не отказался посмотреть сравнение производительности дисков в составе raid-0, raid1, raid-z.
если я правильно понял ваш вопрос.
И да, я бы тоже не отказался посмотреть сравнение производительности дисков в составе raid-0, raid1, raid-z.
>Я живьём Raid6 не щупал
… но всем рекомендую :)
… но всем рекомендую :)
И нагрузка на оставшиеся диски сильно возрастет, увеличивая вероятность их отказа. Я уж не говорю об иопсах, которых на 10м значительно больше. Если надо держать отказ двух дисков – собираем их не парами, а тройками.
правильно я понял, wIOPS упадёт минимум в три раза (в случае 4 устройств)?
По существующим тестам (полную простыню запощу как домеряю) — примерно в 4 раза (раньше писали в 4 устройства, теперь пишем на все одновременно, то есть считай, в одно).
на 4х устройствах — да. а вот на 6? я так понимаю, на 6 дисках уже должно падать только в 3. правда, дальнейший рост по-прежнему будет колебаться в коэффициенте 3-4
Да, вполне интересный вопрос. Я уже автоматизировал fio, теперь осталось автоматизировать генерацию файлов — и можно будет поставить вполне нормальный тест про рейды…
и недельку спокойно покодить. на вопрос начальства — «тестируем!» :)
Ну, сервер молотит, мы другим заняты. Основной вопрос: как из вывода fio аккуратно выковырять цифры IOPS и latency.
any feffekt?
Проект не забыт, проект слегка отложен. Он у меня в планах есть, и, видимо, никакого отношения к ssd уже иметь не будет.
Будет развёрнутая статья про сравнение разных видов рейдов, сравнение adaptec'а и LSI на обычных магнитных дисках.
Я задумался, что никогда эти тесты лоб-в-лоб не делал (только в теории смотрел), так что мне самому интересно.
При этом тесты будут на 8 шпинделях, так что во-первых будут медленные, во-вторых я ещё не дописал софт для генерации отчётов.
Прогресс тут: github.com/amarao/auto-fio
Будет развёрнутая статья про сравнение разных видов рейдов, сравнение adaptec'а и LSI на обычных магнитных дисках.
Я задумался, что никогда эти тесты лоб-в-лоб не делал (только в теории смотрел), так что мне самому интересно.
При этом тесты будут на 8 шпинделях, так что во-первых будут медленные, во-вторых я ещё не дописал софт для генерации отчётов.
Прогресс тут: github.com/amarao/auto-fio
А для PCI-Express есть такие штуки? Сейчас же уже вроде даже не на всех платах-то PCI-E есть, и даже где есть его часто не много…
Эээ, это же одно и то-же :-)
>PCI-E
>PCI-Express
…
>PCI-Express
…
Путаете с PCI-X.
PCI-X, которая «64-битный PCI» можно считать мёртвым.
Угу, давно уже, хотя валяется у меня пара FC-карт под этот слот.
Довольно крупная французская фирма Thales так не считает и уверенно клепает особо узкоспециальные авиационные платы под PCI-X 64. А на все вопросы вида «а куда нам их ставить-то?» отвечает «так покупайте у нас не только платы, а сразу сервера!».
собственно не нужно путать майн-стрим с авиа-космической и оборонной отраслью — это разные стандарты.
А 64-битная плата в принципе может работать в 32-битном слоте? 32-битную плату в 64-битный слот вставлял, работало, а наоборот можно?
Да, но на скоростях 32х битной платы. Теоретически для кого-то это может стать проблемой. Нас устраивает.
Не забывайте еще один нюанс. Куча матплат, где за 32х битной PCI платой сразу стоит какой-нибудь радиатор, слот под что-то и тд. То есть «хвосту» от 64 битной платы будет мешать и она физически не встанет.
Не забывайте еще один нюанс. Куча матплат, где за 32х битной PCI платой сразу стоит какой-нибудь радиатор, слот под что-то и тд. То есть «хвосту» от 64 битной платы будет мешать и она физически не встанет.
Всего за $100 адаптирую вашу PCI-E плату к PCI-Express шине (такой же размерности).
Впрочем, я не люблю unpack-посты, так что перейдём к самому главному — производительности.
Ну хоть одну… фоточку… бы =(
Ну хоть одну… фоточку… бы =(
можете поверить «на слово» — карточка страшная — это не Intel Xeon Phi slashdot.org/topic/wp-content/uploads/2012/11/Xeon_Phi_Family-e1352836615241.jpg
UFO just landed and posted this here
Вы SSD в качестве кеша для обычных дисков для блочных девайсов используете? Где при этом сам SSD располагается: на хост-машине или в хранилище?
Использование SSD на локальном хосте — порочная практика. Поскольку хосты в облачной среде предполагаются равноправными, быстродохнущими и экивалентно заменяющими друг друга, наличие любой пользовательской информации на дисках не допустимо. Если хост по той или иной причине сдохнет, мы не сможем запустить клиента с кешем диска на другом хосте.
Так что от intellicache пришлось отказаться, увы, на хостах диски только под fs для dom0, помойка для резервной копии логов и прочей служебной фигни, не касающейся клиентов.
Так что от intellicache пришлось отказаться, увы, на хостах диски только под fs для dom0, помойка для резервной копии логов и прочей служебной фигни, не касающейся клиентов.
Sign up to leave a comment.
Возможности PCI-E SSD Intel 910