company_banner

Возможности PCI-E SSD Intel 910

    Раньше у нас долгое время для кеширования random IO использовались intel 320 серии. Это было умеренно быстро, в принципе, позволяло сократить число шпинделей. При этом обеспечение высокой производительности на запись требовало, мягко говоря, неразумное количество SSD.

    Наконец, в конце лета к нам приехал Intel 910. Сказать, что я глубоко впечатлён — не сказать ничего. Весь мой предыдущий скепсис относительно эффективности SSD на запись развеян.

    Впрочем, обо всём по порядку.

    Intel 910 — это карточка формата PCI-E, довольно солидных габаритов (под стать дискретным видеокартам). Впрочем, я не люблю unpack-посты, так что перейдём к самому главному — производительности.

    Картинка для привлечения внимания



    Цифры реальные, да, это сто тысяч IOPS'ов на произвольную запись. Подробности под катом.

    Описание устройства


    Но сначала мы поиграем в Alchemy Classic, в которой если перетащить один LSI поверх 4х Hitachi, то получится Intel.

    Устройство представляет собой особым образом адаптированный LSI 2008, к каждому порту которого «подключено» по одному SSD устройству ёмкостью 100Гб. Фактически все подключения выполнены на самой плате, так что подключение видно только при анализе взаимоотношений устройств.

    Примерная схема такая:


    Заметим, LSI'ный контроллер перепилен очень сильно — у него нет своего биоса, он не умеет быть загрузочным. В lspci он выглядит так:
    04:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)
            Subsystem: Intel Corporation Device 3700
    


    Структура устройства (4 SSD'шки по 100Гб) подразумевает, что пользователь сам решит, как именно использовать устройство — raid0 или raid1 (для тонких ценителей — raid5, хотя с большой вероятностью это будет самая большая глупость, которую можно сделать с устройством подобного класса).

    Обслуживается он драйвером mpt2sas.

    К нему подключено 4 scsi устройства, которые объявляют себя hitachi:
     sg_inq /dev/sdo
     Vendor identification: HITACHI 
     Product identification: HUSSL4010ASS600 
    


    Никаких расширенных sata-команд они не поддерживают (так же как и большинство расширенных сервисных команд SAS) — только минимум необходимого для полноценной работы в качестве блочного устройства. Хотя, к счастью, поддерживает sg_format с опцией resize, что позволяет сделать полноценное резервирование для меньшего влияния housekeeping'а при активной записи.

    Тестирование


    Всего мы делали 5 разных тестов, позволяющие оценить характеристики устройства:
    • тест на произвольное чтение
    • тест на произвольную запись
    • тест на смешанное параллельное чтение/запись (заметим, говорить про пропорции «чтения/записи» не приходится, т.к. каждый поток «молотил» отдельно друг от друга, конкурируя за ресурсы, как это чаще всего бывает в реальной жизни).
    • тест на максимальную линейную производительность на чтение
    • тест на максимальную линейную производительность на запись


    Тесты на линейные чтение и запись


    В общем случае, эти тесты мало кому интересны, для обеспечения «потока» HDD подходят куда лучше, т.к. у них выше ёмкость, ниже цена и весьма приличная линейная скорость. Простенький сервер с 8-10 SAS-дисками (или даже быстрыми SATA) в raid0 вполне способен забить десятигигабитный канал.

    Но, всё-таки, вот показатели:

    Линейное чтение


    Для максимальных показателей мы выставили 2 потока по 256к на каждое устройство. Итоговая производительность: 1680МБ/с, без колебаний (девиация составила всего 40 мкс). Lantency при этом составила 1.2мс (для блока 256к это более чем хорошо).
    Фактически, это означает, что в одиночку это устройство на чтение способно полностью «в потолок» забить канал 10Гбит/с и показывать более чем впечатляющие результаты на канале в 20Гбит/с. При этом оно будет показывать постоянную скорость работы вне зависимости от нагрузки. Заметим, сам Intel обещает до 2ГБ/с.

    Линейная запись


    Для получения самых высоких цифр по записи нам пришлось снизить глубину очереди — один поток на запись на каждое устройство. Остальные параметры были аналогичными (блок 256к)
    Пиковая скорость (секундные отсчёты) составила 1800МБ/с, минимум — около 600МБ/с. Средняя скорость записи 100% составила 1228МБ/с. Внезапное снижение скорости записи — родовая травма SSD из-за работы housekeeping'а. В данном случае падение было до 600МБ/с (примерно в три раза), что лучше, чем в старых поколениях SSD, где деградация могла доходить до 10-15 раз. Intel обещает скорость порядка 1.6ГБ/с при линейной записи.

    random IO


    Разумеется, линейная производительность никого не интересует. Всем интересна производительность под тяжёлой нагрузкой. А что может быть самым тяжёлым для SSD? Запись на 100% объёма, мелкими блоками, во много потоков, без перерывов в течение нескольких часов. На 320ой серии это приводило к падению производительности с 2000 IOPS до 300.

    Параметры теста: raid0 из 4х частей устройства, делается linux-raid (3.2), 64-бита. Каждая задача с режимом randread или randwrite, для смешанной нагрузки описываются 2 задачи.
    Заметим, в отличие от многих утилит, которые соотносят число операций чтений и записи в фиксированном процентном соотношении, мы запускаем два независимых потока, один из которых всё время читает, другой всё время пишет (это позволяет полнее нагрузить оборудование — если у устройства проблемы с записью, оно всё ещё может продолжать обслуживать чтение). Остальные параметры: direct=1,buffered=0, режим io — libaio, блок 4к.

    Random read



    iodepth IOPS avg.latency
    1 7681 0,127
    2 14893 0,131
    4 28203 0,139
    8 53011 0,148
    16 88700 0,178
    32 98419 0,323
    64 112378 0,568
    128 148845 0,858
    256 149196 1,714
    512 148067 3,456
    1024 148445 6,895


    Заметно, что оптимальной нагрузкой является что-то порядка 16-32 операций одновременно. Очередь длинной в 1024 добавлена из спортивного интереса, разумеется, это не является адекватными показателями для product (но даже в этом случае latency получается на уровне довольно быстрого HDD).

    Так же можно заметить, что точка, в которой скорость практически перестаёт расти — это 128. С учётом, что внутри там 4 куска, это обычная для многих контроллеров глубина очереди в 32 на каждый.

    Random write



    iodepth IOPS avg.latency
    1 14480 0,066
    2 26930 0,072
    4 47827 0,081
    8 67451 0,116
    16 85790 0,184
    32 85692 0,371
    64 89589 0,763
    128 96076 1,330
    256 102496 2,495
    512 96658 5,294
    1024 97243 10,52

    Аналогично — оптимум находится в районе 16-32 одновременных операций, путём весьма значительного (10-кратного роста) latency можно «выжать» ещё 10к IOPS.

    Интересно, что на малой нагрузке производительность на запись выше. Вот сравнение двух графиков — чтения и записи в одном масштабе (чтение — зелёным):


    Смешанная нагрузка


    Самый тяжёлый вид нагрузки, который можно считать заведомо превышающим любую практическую нагрузку в продакт-среде (включая OLAP).


    Поскольку по этому графику реальную производительность не понять, то вот те же цифры в куммулятивном виде:


    iodepth IOPS read IOPS write avg.latency
    1+1 6920 13015 0,141
    2+2 11777 20110 0,166
    4+4 21541 33392 0,18
    8+8 36865 53522 0,21
    16+16 44495 58457 0,35
    32+32 49852 58918 0,63
    64+64 55622 63001 1,14

    Видно, что оптимальная нагрузка так же находится в районе от 8+8 (то есть 16) до 32. Таким образом, не смотря на очень высокие максимальные показатели, нужно говорить про максимум в ~80к IOPS при нормальной нагрузке.

    Заметим, получившиеся цифры больше чем обещает intel. На сайте они заявляют, что эта модель способна на 35 kIOPS на запись, что примерно соответствует (на графике производительности) точке с iodepth около 6. Так же, возможно, эта цифра соответствует наихудшему случаю для housekeeping'а.

    Единственным минусом этого устройства являются определённые проблемы с горячей заменой — PCI-E устройства требуют обесточивать сервер перед заменой.
    Selectel
    ИТ-инфраструктура для бизнеса

    Похожие публикации

    Комментарии 107

      +2
      Показатели впечатляют.
      Но цена… Intel SSD 910 400GB $2000
        +11
        Ну, это совсем недорого. :)
          +3
          Просто для понимания, эквивалентное количество жёстких дисков будет стоить примерно $100k (1000 шт), и это без учёта того, где эти диски будут размещаться и куда подключаться.

          Пара таких железок в кеширующем режиме (или одна, но свёрнутая в raid1) обеспечивает практически неограниченную производительность дисковой подсистемы для сервера.
            +1
            насколько помню, при использовании правильных рейзеров hotswap и hotplug для PCI-e в стандарте заложено.

            cateee.net/lkddb/web-lkddb/HOTPLUG_PCI_PCIE.html
            0
            откуда взялось $100k за 1000штук? Можете по подробнее расписать расчеты?
              +2
              $100k за 1000штук / 1000 = $100 за 1штуку
                0
                не забываем про объем
                  +4
                  А причём тут объём? Толку-то от 100500Тб, если у вас будет 40 IOPS с них?
                0
                100 IOPS'ов на диск. Это при том, что у диска latency будет на полтора порядка выше, чем у SSD. Дальше считайте сами, сколько нужно дисков для 100к IOPS.
                  0
                  Ну если в таком контексте — то согласен.
                  Вопрос в тему:
                  — почему не стали смотреть в сторону FusionIO, ведь они быстрее?
                  — почему нету тестов на 512b random, а только на 4k?

                    +4
                    видимо, из-за того, что все актуальные ФС оперируют блоками 4к, и только появляются те, блок которых больше. 512 не соответствует сегодня никакой реальной нагрузке.
              0
              по сравнению с FusionIO устройствами — не очень…
              А вот цена — Я бы сказал что неплохо.
                0
                Я не щупал FusionIO, есть вероятность, что они попугаи считают с большой очередью (то есть завышенной latency, благо пока что большинство пользователей благосклонно смотрят как на latency в 0.1мс, так и в 0.3мс).
              0
              Копейки, как не посмотри.
              +2
              У вас SSD на запись на VPS-ках???
              На сколько лет ресурса хватает?
                +2
                По наблюдению за intel 320, которые у нас в продакте год были, износ составил

                233 Media_Wearout_Indicator 0x0032 086 086 000 Old_age Always — 0

                Другими словами, около 14% в год. И это в режиме весьма плотной записи почти непрерывно. Но 320 мы готовили правильно (то есть 20% места в резерв для housekeeping'а).
                  +5
                  Ясно, а какие ваши виды сервисов используют SSD?
                  Облако, VPS, или только для спец.клиентов?
                    +1
                    На VDS'ах обычные диски. В кастомные арендуемые серверы вы можете напихать любое физически возможное количество SSD.
                –6
                Только RAID6, только хардкор. В отличие от RAID10 — при том же объёме, сдохнуть могут любые два из 100G, а не только два из разных пар. Правда, производительность упадёт в 4 раза, но мы не ищем лёгких путей!
                  0
                  Не имеет смысла, у вас все равно остается единая точка отказа- сам контроллер. Вероятность выходя из строя модулей памяти значительно ниже (IMHO).
                    0
                    Выход из строя контроллера — random величина.
                    Выход из строя модуля памяти — запланированная, и растущая с возрастом.
                      0
                      запланированная
                      =>> значит не аварийная, можно заранее подготовиться. А вот контроллер у вас отвалится внезапно, что еще раз подтверждает мои слова.
                        –2
                        берём две карты, собираем RAID6 на каждой, и RAID1 поверх обеих
                        а еще лучше, берём три карты, и RAID5 из них.
                        или 4 карты, и RAID6 из них.

                        вот так точно угробим 80% производительности, но получим офигенскую надёжность.

                        правда надо 4 таких сервера, и RAID6 из них — иначе у нас SOPF — PCI контроллер
                          0
                          Вы поняли мысль ;)
                        0
                        Вы же сами не далее как вчера писали, что не использовать реид из ссд карт крайне плохо из-за возможности умирания контроллера SSD. Или предполагаете, что LSI контроллер существенно надёжней?
                          0
                          здесь 4 контроллера SSD от Hitachi + 1 PCI-E<=>SAS контроллер от LSI.
                            0
                            Да, но его, на сколько я понимаю, всё равно не поменять отдельно от ssd — всё припаяно.
                              0
                              его надёжность таки выше — ибо его функции проще.
                              а по надежноти SSD: habrahabr.ru/post/133924/
                      +1
                      Кстати, вы задали очень интересный вопрос.

                      У меня одна штука есть в лаборатории, сейчас посмотрю, что там будет в raid6 силами линукса.
                        0
                        Весьма интесно. Я живьём Raid6 не щупал, но как понимаю, производительность минимум втрое ниже, чем отдельного диска.
                          0
                          Это при 4-х дисках? А если больше?
                            0
                            в любом случае, при RAID6 запись идёт на 3 диска вместо одного.
                            не, если у вас 6 дисков, то есть ситуация когда одна запись пишет на одну тройку, а другая на другую тройку.
                            во всех остальных случаях — две параллельные записи всегда на каком-либо из дисков да лезут одновременно.
                            0
                            С чего-это производительности быть меньше, чем одного диска?

                            Сижу дома на RAID-6 из 8 дисков уже года 2 (диски «зеленые», ~60Мб/сек).
                            Вот результаты линейного чтения/записи (файл вдвое больше размера памяти):

                            Запись — 141 MB/s
                            Чтение — 359 MB/s

                            Случайный доступ / IOPS — не медленнее самого медленного диска.
                              +1
                              потому что запись идёт на 3 диска а не на 1.
                              соответственно, при RAID0 вероятность конфликта на Random Write будет 1/N где N — число дисков, а у RAID6 — 3/N.
                              то есть на 8 дисках, В 37.5% случаев запись встанет в очередь.

                              ну и да, я немного не прав, когда сравниваю с «одним». имеется ввиду по сравнению с «RAID0»
                                0
                                При наличии write-back не имеет значения на сколько дисков идёт запись. Она происходит для пользователя моментально, если объём записываемых данных помещается в кеш.

                                У меня записывается 800mb за пару секунд при размере кэша в 512mb на raid5 из старых медленных дисков.
                                  0
                                  никого не интересует производительность «когда влезает в кеш», интересует производительность худшего случая — когда все кеши пробиваются (например, помирает батарейка в рейде) и наступает полный коллапс.
                                    0
                                    Худший случай — это отключение питания в датацентре. Как пару лет назад было в Москве. И не спасёт вообще ничего.

                                    Разница в производительности с write-back и без него в сотню раз, примерно.

                                    Я пришёл к выводу, что наиболее эффективное решение по соотношениям ёмкость, цена, скорость и надёжность — это аппаратный рейд с большим кешем + батарейкой или суперконденсатором + flash (Z), плюс сервак с офигенной оперативкой.

                                    В большинстве случаев выгоднее вкладывать в оперативку (кеширование на чтение и тот же write-back только средствами ядра), чем в SSD.

                                    Оперативка за 1 Гб стоит в 1,8 раза дороже SSD, но при этом, как минимум, в 10 000 раз быстрее и имеет неограниченный ресурс перезаписи. Довольно логично выбирать её для апгрейда, а не новый SSD. Минусы такой системы — медленный старт, что для серверов не критично.

                                    А если добавить индивидуальный UPS от 100 долларов, то вообще шоколад. Кстати имея UPS можно сэкономить на батарейке рейда. Главное, чтобы UPS подавал серверу сигнал на выключение, если нет питания.

                                    Редко встречаются приложения, которые постоянно генерируют столько данных на запись, сколько хотя бы треть линейной скорости записи нормального рейд-массива. Write-back как раз оптимизирует случайную запись, что примерно треть-половина от линейной скорости массива на запись получается.

                                    На моём продакшен сервере до фига данных на запись на постоянной основе генерирует только бакап. Но он делается на отдельную дисковую подсистему мимо write-back кеша raid-контролера.
                                      0
                                      Сколько RAM сейчас используете?
                                        +1
                                        facepalm.

                                        Если бы упс спасал от kernel panic'а…

                                        Да и вообще, речь о другом идёт. Если вы используете wb модель за пределами FS, то любое повреждение кеша (питание ли, падение сервера, отказ памяти/ssd) приводит к необративому и неуправляемому повреждению данных (в сравнении с этим файловый кеш на журналируемых файловых системах по крайней мере мета-данные сохраняет).

                                        Таким образом, следует разделять «переживающий падение кеш» и «не переживающий». И это очень сильно меняет отношение к нему с точки зрения применимости. Главное достоинство рейда из SSD, что он всё-таки non-volative.
                                          0
                                          3 случая потери wb-кеша на контроллере, которые вы привели:

                                          1) питание
                                          лечится батарейкой в рейд, а лучше суперконденсатором + flash

                                          2) kernel panic
                                          лечится батарейкой в рейд + как вы сказали «файловый кеш на журналируемых файловых системах по крайней мере мета-данные сохраняет»

                                          3) отказ памяти
                                          у ECC RAM такого на практике не бывает. Ну у меня не было. Не слышал, чтобы RAM горела, если её не трогать. А вот для SSD это постоянно происходит. Причём может произойти синхронно на нескольких SSD, так как у них очень сходные характеристики

                                          вероятность поломки кеша с суперконденсатором микроскопична.
                                            0
                                            Вообще, вы с amarao говорите о совершенно разных вещах.
                                            inetstar — об оптимизации некоего своего сервера.
                                            amarao — о СХД.
                                            у них разные требования к надёжности и производительности системы.

                                            разговаривая о СХД речь идёт об исключительной надёжности, и производительности только в худшем случае.
                                            разговария об оптимизации своего сервера можно идти на допущения, типа «рамы хватит», «батарейки рейда хватит», «если упадёт, база ACID, восстановится».

                                            я на днях буквально видел — навернулся рейд1, на двух разделах ext3 в полную кашу, xfs в плохом состоянии, на третьем — отдельный раздел под postgresql, там xfs не монтировался и не чекался, но запуск без лога позволил тупо слить файло «в неком состоянии» на новые диски. и этого хватило — база поднялась, недостатки залили из бакапа.

                                            вот поэтому amarao и говорит, что НЕТ методики рассета. её действительно нет.
                                            ибо гадание на кофейной гуще «раза в 4 больше хватит всем» — что хватало на своих задачах, но соовсем не то, что позволяет оценить худший случай когда на СХД неизвестно и не может быть никогда известна.
                                              0
                                              У меня есть интуитивное подозрение, что теоретически можно как-то рассчитывать размер хотспота. Или даже не хотспота, а рационального кеша под скорость шпинделей (кеш такого размера, что его дальнейший рост не сильно улучшает производительность системы).

                                              Но я даже не очень понимаю, как на продакт-системе посмотреть размер хотспота (без привлечения debugfs), а уж рассчёты…
                                              0
                                              а на тему kernel panic'а… был у меня в юности негативный опыт. ext3, аппараный рейд, ядро по-моему 2.4.22 или .26.
                                              обычный такой рабочий сервачок со стартапом, база в мускуле, сайтик на пыхе, всё крутится, всё работает.
                                              был словлен kernel panic. После ребута — файловая система в кашу. Просто, в невосстановимую кашу. Причем спасибо аппаратному рейду — эта каша была заботливо отзеркалирована.
                                              Восстанавливать было нечего (копался я глубоко и долго).
                                                +1
                                                По поводу третьего — multi-bit ecc, примерно два десятка случаев отказа в год. На загруженном парке серверов, разумеется.

                                                Слёт содержимого wb на кондёре у адаптека я наблюдал. 5ая серия (на тот момент топовая), 2011 год.
                                                  0
                                                  А реально фичи вроде зеркалирования памяти на чипсете серии intel 5000 используются?
                                                    0
                                                    Зеркалирование не используется. На трёх каналах это, хм, слишком дорого получается. Из 48Гб образуется 16Гб RAM.
                                                      0
                                                      емнип 5000 так не умеет, он понимает не более 64 гб, в зеркале — 32 значит (два канала, две реплики)

                                                      но могу ошибаться, ни разу не эксплуатировал в таком режиме
                                                        0
                                                        Два канала? Странно. Новые процы имеют либо 3, либо 4 канала.
                                                          0
                                                          Есть разные линейки процессоров, на топовых да, по 3/4 канала, на тех что попроще по два.
                                                0
                                                И вообще — есть ли рейд в этой карте: можно ли менять SSD?

                                                Если использовать raid0, то вероятность вылета этой карты увеличивается в 4 раза по сравнению с одиночным SSD. Что ужасно и неприемлемо.

                                                Если менять на лету нельзя и нет средств оповещения о вылете, то это напрасная трата денег: в любой момент сервер может встать с потерей данных.
                                                  0
                                                  RAID != hotswap.
                                            +1
                                            Это очень наивное представление. Поясняю почему.

                                            Предположим, у вас есть кеш на 512мб, блок 4к, итого, 128k записей (забываем про метаданные). Само кешируемое устройство может обслуживать не более 500 случайных записей (полагаем, что последовательно образовавшиеся блоки будут писаться за то же время, что и один блок, в грубом приближении это допустимо).

                                            Вы ставите его в продакт. Первое время вы имеете random write равной линейной скорости записи в кеш. Потом ситуация меняется — кеш-то нужно flush'ить.

                                            А то, как флашится кеш определяется тем, насколько оный кеш может покрыть hotspot'ы, то есть какой коэфицент «повторных записей» объединяет кеш. Допустим, он становится равным 20. Это безумно высокий показатель, но, допустим.

                                            Итого, мы можем флашить 500 записей в секунду. При коэфиценте 20, это значит, что кеш может обрабатывать 10000 записей в секунду.

                                            Вроде бы всё хорошо, правда? Вы ставите на него нагрузку в 8к IOPS и жизнь хороша… А дальше вам в какой-то момент времени входит пачка random IO на запись. Не попадающая под «повторные записи». И, внезапно, коэфицент падает до двух, и оказывается, что производительность массива — 1000 IOPS на запись.

                                            И я не видел ни одного вменяемого интегратора/администратора/проектировщика, кто бы взялся более-менее предсказывать размер хотспотов.

                                            … А не забываем про ледяные данные (которые читаются раз в сутки).
                                              0
                                              кэш на 512MB в продакшене — Вы наверное шутите, тут минимум 1GB нужен.
                                              кстати для примера проще использовать несколько уровней кэширования

                                              2GB (OS Cache) + 2GB (RAID Cache) + 3xRAID5 120GB (SSD Cache) = основная дисковая подсистема
                                                +2
                                                Тут надо просто переставать меряться понтовостью слова «продакт» и говорить про цифры. Так вот: я не знаю адекватной методологии рассчёта хотспот области (читай — размер кеша).
                                                  0
                                                  Давайте — обычно размер идет по принципу.
                                                  Кэш = 2 * локальный кэш диска в RAID (обычно 64MB) * N (число дисков в RAID)

                                                  Берем пример для 4 дисков = 2 * 64MB * 4 = 512MB
                                                  Учитывая что будет интенсивная нагрузка на запись то берем двойное значение — т.е. 512MB*2 = 1024MB это и есть нужное значение.
                                                    0
                                                    Нужное значение для чего? Я вполне серьёзно спрашиваю, потому что ваш метод никаким образом не отвечает на вопрос о размере хотспота.
                                                      –1
                                                      Это расчет брался по реальному проекту для Xen:
                                                      (1) Redis (в качестве кэша)
                                                      (2) PerconaDB (интенсивный транзакции)
                                                      (3) MongoDB
                                                      (4) 3 x nginx (highload)
                                                      (5) 3 x CentOS — служебные машины

                                                      В этом конфиге все очень даже хорошо.
                                                        +1
                                                        Я честно сдерживаюсь, но мне хочется сказать много нехорошего.

                                                        Рассчёт чего? Какие цифры вы брали за входные, какие цифры пытались рассчитать? То, что эта штука у вас «работает», означает, что вы всего лишь не вышли за нижнюю границу.

                                                        Самой методики нет, методов проверки — нет.

                                                        Повторю ещё раз: каким образом вы рассчитываете размер хотспота и откуда берёте данные для рассчёта? Простите, считать за адекватную методологию «количество запущенных монго» я отказываюсь.
                                                  +1
                                                  кеша на 512 метров в продакте хватает нам за глаза на сервере с бд, на более слабых — вообще 256.
                                                  и они 100% на write, на read — покрываются OS Cache.
                                                  и всё равно, производительность меряется когда WB кеш не работает, иначе в один не прекрасный день можно сильно удивиться.
                                                    0
                                                    write cache файловой системы не касается файлов, открытых в direct режиме, а так же злоупотребления flush (так любят БД поступать, именно потому поток ужасного рандома называют OLAP).
                                                      0
                                                      я говорю про WB кеш, Battery-Backed на рейд контроллере.
                                                      файловый Write-Cache — только объеденить кучу строк лога в один write, на базах и не пахнет им конечно же.

                                                      это опять же к слову о том, что на OS-Cache палагаться на write низя.
                                                        0
                                                        смотря для каких БД — поскольку для некоторых (single file) можно вообще отдать блочное устройство и тогда не иметь проблем с накладными расходами от файловой системы.
                                                        P.S. при условии что:
                                                        — БД действительно может работать в таком режиме
                                                        — БД будет занимать меньше места чем размер блочного устройства
                                            +3
                                            … Я начал мерять, там работы очень много, так что результат ждите через несколько дней отдельной статьёй. Но результаты получаются крайне любопытные.
                                              0
                                              Как захотелось raidz на этом деле поднять :)
                                                0
                                                z?
                                                  0
                                                  RAID-Z
                                                  если я правильно понял ваш вопрос.

                                                  И да, я бы тоже не отказался посмотреть сравнение производительности дисков в составе raid-0, raid1, raid-z.
                                                    0
                                                    Как-то не все хорошо с перформансом на RAID-Z, если даже сам Oracle перформанс своих стораджей меряет на мирроре.
                                              0
                                              >Я живьём Raid6 не щупал
                                              … но всем рекомендую :)
                                                0
                                                вообще там явно читался тег .
                                            +1
                                            И нагрузка на оставшиеся диски сильно возрастет, увеличивая вероятность их отказа. Я уж не говорю об иопсах, которых на 10м значительно больше. Если надо держать отказ двух дисков – собираем их не парами, а тройками.
                                              0
                                              туплю, забудьте что я тут писал
                                                0
                                                правильно я понял, wIOPS упадёт минимум в три раза (в случае 4 устройств)?
                                                  0
                                                  По существующим тестам (полную простыню запощу как домеряю) — примерно в 4 раза (раньше писали в 4 устройства, теперь пишем на все одновременно, то есть считай, в одно).
                                                    0
                                                    на 4х устройствах — да. а вот на 6? я так понимаю, на 6 дисках уже должно падать только в 3. правда, дальнейший рост по-прежнему будет колебаться в коэффициенте 3-4
                                                      0
                                                      Да, вполне интересный вопрос. Я уже автоматизировал fio, теперь осталось автоматизировать генерацию файлов — и можно будет поставить вполне нормальный тест про рейды…
                                                        0
                                                        и недельку спокойно покодить. на вопрос начальства — «тестируем!» :)
                                                          0
                                                          Ну, сервер молотит, мы другим заняты. Основной вопрос: как из вывода fio аккуратно выковырять цифры IOPS и latency.
                                                            0
                                                            any feffekt?
                                                              +1
                                                              Проект не забыт, проект слегка отложен. Он у меня в планах есть, и, видимо, никакого отношения к ssd уже иметь не будет.

                                                              Будет развёрнутая статья про сравнение разных видов рейдов, сравнение adaptec'а и LSI на обычных магнитных дисках.

                                                              Я задумался, что никогда эти тесты лоб-в-лоб не делал (только в теории смотрел), так что мне самому интересно.

                                                              При этом тесты будут на 8 шпинделях, так что во-первых будут медленные, во-вторых я ещё не дописал софт для генерации отчётов.

                                                              Прогресс тут: github.com/amarao/auto-fio
                                              –2
                                              А для PCI-Express есть такие штуки? Сейчас же уже вроде даже не на всех платах-то PCI-E есть, и даже где есть его часто не много…
                                                +4
                                                Эээ, это же одно и то-же :-)
                                                  +5
                                                  >PCI-E
                                                  >PCI-Express

                                                    +5
                                                    Путаете с PCI-X.
                                                      +2
                                                      PCI-X, которая «64-битный PCI» можно считать мёртвым.
                                                        0
                                                        Угу, давно уже, хотя валяется у меня пара FC-карт под этот слот.
                                                          +1
                                                          Довольно крупная французская фирма Thales так не считает и уверенно клепает особо узкоспециальные авиационные платы под PCI-X 64. А на все вопросы вида «а куда нам их ставить-то?» отвечает «так покупайте у нас не только платы, а сразу сервера!».
                                                            –1
                                                            собственно не нужно путать майн-стрим с авиа-космической и оборонной отраслью — это разные стандарты.
                                                              0
                                                              А 64-битная плата в принципе может работать в 32-битном слоте? 32-битную плату в 64-битный слот вставлял, работало, а наоборот можно?
                                                                0
                                                                Да, но на скоростях 32х битной платы. Теоретически для кого-то это может стать проблемой. Нас устраивает.
                                                                Не забывайте еще один нюанс. Куча матплат, где за 32х битной PCI платой сразу стоит какой-нибудь радиатор, слот под что-то и тд. То есть «хвосту» от 64 битной платы будет мешать и она физически не встанет.
                                                                  0
                                                                  Ну так тогда есть масса passive PICMG 1.0 backplane, в которой за PCI-слотом ничего нет, мешать не будет. И этих плат на выбор — PCI-слотов хоть до полтутора десятков.
                                                                    0
                                                                    С фантастической скоростью PCI, общей для кучи железок? (66 МГц, 64 бита — 480МБ/с, и это на полтора десяток SSD? :)
                                                          +7
                                                          Всего за $100 адаптирую вашу PCI-E плату к PCI-Express шине (такой же размерности).
                                                            0
                                                            Почему такой же? Можно же и больше, и меньше :)
                                                          +4
                                                          Впрочем, я не люблю unpack-посты, так что перейдём к самому главному — производительности.
                                                          Ну хоть одну… фоточку… бы =(
                                                            0
                                                            можете поверить «на слово» — карточка страшная — это не Intel Xeon Phi slashdot.org/topic/wp-content/uploads/2012/11/Xeon_Phi_Family-e1352836615241.jpg
                                                              +1
                                                              Для кого-то, торчащая радиаторами и микросхемами «страшная» карточка будет интереснее такой «вылизанной» Интеловской.
                                                              Не спрашивайте почему, geek pron и все дела :D
                                                              Однако картинку конечно можно и нагуглить при желании.
                                                                0
                                                                Я видел решения и красивее (в т.ч. решения без кожуха) — тут точно не тот случай.
                                                                  +1
                                                                  Настоящий geek porn, это когда lantency наносекундами меряют.
                                                                    +1
                                                                    Это уже хардкор!
                                                              0
                                                              Взял ли бы хоть пару картинок для увеселения публики отсюда, или отсюда, или, на крайний случай, вот отсюда
                                                                0
                                                                Я ж говорю, я не любитель анпак тредов. Какая разница, как она выглядит?
                                                                0
                                                                Конечно сравнивать такую плату и Intel 320 — это сравнивать велосипед и камаз :)

                                                                А как насчёт таких штук, не пробовали?
                                                                  0
                                                                  Вы SSD в качестве кеша для обычных дисков для блочных девайсов используете? Где при этом сам SSD располагается: на хост-машине или в хранилище?
                                                                    +3
                                                                    Использование SSD на локальном хосте — порочная практика. Поскольку хосты в облачной среде предполагаются равноправными, быстродохнущими и экивалентно заменяющими друг друга, наличие любой пользовательской информации на дисках не допустимо. Если хост по той или иной причине сдохнет, мы не сможем запустить клиента с кешем диска на другом хосте.

                                                                    Так что от intellicache пришлось отказаться, увы, на хостах диски только под fs для dom0, помойка для резервной копии логов и прочей служебной фигни, не касающейся клиентов.
                                                                    +2
                                                                    image

                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                    Самое читаемое