Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9   вперед  Ctrl      все
 Re: SSD для баз данных?  [new]
rrrruuuu
Guest
есть годная статья с характеристиками последних поколений SSD от фсентра
http://www.fcenter.ru/online.shtml?articles/hardware/hdd/33054
24 май 12, 14:52    [12608609]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
ORA__SQL
Member

Откуда: Moscow
Сообщений: 1774
1) А что-нибудь измениось за 3 года по отношению к SSD: надежнось, пригодность для использования под Oracle
2) У кого что хранится сейчас на SSD. Какие впечателния/проблемы были?
9 июн 12, 09:50    [12692182]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
полиSSD
Guest
ORA__SQL
1) А что-нибудь измениось за 3 года по отношению к SSD: надежнось,

Надеженсть SSD так и не изменилась (принципиально).

ORA__SQL
пригодность для использования под Oracle

Пригодность сомнительна в виду ненадежности. Проще много памяти накупить для buffer cache, чем выгадывать что-то там.
Сейчас в любой low-end сервер можно натолкать 128-256 гектара ECC DDR3, этого более чем под 99% задач.
А для оставшегося 1% можно взять какой HP DL980 и натолкать туда 2TB планок.

ORA__SQL
2) У кого что хранится сейчас на SSD. Какие впечателния/проблемы были?

Эксперименты в Exadata показали, что для общих (general mixed OLDP/DSS) задач от этого вашего flash в реальности ни холодно, ни жарко.

Нужно еще очень постараться, чтоб показать улучшение чего-то там.
9 июн 12, 14:45    [12694356]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
ORA__SQL
Member

Откуда: Moscow
Сообщений: 1774
полиSSD
Эксперименты в Exadata показали, что для общих (general mixed OLDP/DSS) задач от этого вашего flash в реальности ни холодно, ни жарко.
А есть ссылки на результаты/документы по экспериментам?
9 июн 12, 14:54    [12694401]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
полиSSD
Guest
ORA__SQL
полиSSD
Эксперименты в Exadata показали, что для общих (general mixed OLDP/DSS) задач от этого вашего flash в реальности ни холодно, ни жарко.
А есть ссылки на результаты/документы по экспериментам?


Зачем они тебе? Поглазеть праздным интересом, многозначительно?
Или для принятия решений на основе недостоверного источника на нерелеватной твоей задаче?


Тебе дали направление - прежде чем покупать что-то на SSD - сделайте тесты под реальной нагрузкой.

Это все, что я хотел сказать.
9 июн 12, 14:58    [12694434]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
Денис1
Member

Откуда:
Сообщений: 61
полиSSD
Эксперименты в Exadata показали, что для общих (general mixed OLDP/DSS) задач от этого вашего flash в реальности ни холодно, ни жарко.

Нужно еще очень постараться, чтоб показать улучшение чего-то там.



Здравствуйте, Уважаемые!

Извините за поднятие старого топика - просто я вот тут на днях дополнительно протестировал свои (довольно старые) флэши и хотел поделиться результатами.

Я в этом топике выше ссылался на "Флеш-память, твёрдотельные и жёсткие диски - производительность для пользователя" - вот продолжение, если кому будет интересно.

Я изначально был заинтересован в Database Flash Cache - который, как без сомнения уже известно, отличается от Exadata'вского Smart Flash Cache.

Обе технологии используют одну и ту же карточку - "Sun Flash Accelerator F20 PCIe", но по-разному. Полная стойка Exadata включает 14 Exadata Storage Server, в каждой из таких ячеек установлено по 4 PCIe карточки, в каждой по 4 Флэш-модуля (да-да, "а смерть в яйце на конце иглы" :-) ). Используется это дело исключительно для работы Storage cell и к базе данных как таковой никакого отношения не имеет. В каждой из карточек могут храниться блоки из разных баз.

Database Flash Cache, в отличие, позволяет "расширить" database buffer cache так называемым
"кэшем 2-го уровня", который медленнее памяти но быстрее SSD. Вот именно эта функция мне была интересна.

Дело в том, что приведенный выше совет "покупать больше RAM" работает отлично если не покупать Ораклячие лицензии :-). Чтобы добавить RAM, чаще всего надо купить новую материнку - на текущей уже некуда вставлять планки памяти. Покупка новой мамки влечёт покупку 2х или 4х 6-ти или 8-ми ядерных процессоров, а лицензии есть на старый сервер, с одним 4-х ядерным. Вот и "попадаем на деньги" сразу же.

Именно с такой точки зрения я попытался взять очень слабый старый сервер (6 лет почти), вставить туда "Sun Flash Accelerator F20 PCIe" (очень удачно куплен по случаю в Китае - рекомендую: цена билета туда и обратно значительно меньше полной стоимости карточки :-) ) и посмотреть что получилось.

Без всякой настройки, "as-is" производительность возросла в 2 раза. Используя ASM вместо файловой системы и настроив OS и Оракл сервер, прирост производительности легко можно довести где-то до 8-12 раз.

Правда работает только для OLTP.

В общем, если интересно - добро пожаловать, у меня на сайте подробные тесты, называется заметка "Oracle 11g Database Flash Cache - производительность для пользователя".

Всем удачи,
=================================================
С уважением,
Денис

Библия для людей, работающих с командной строкой.
http://www.read-and-think.org/
=================================================
17 июл 12, 03:58    [12875487]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
-2-
Member

Откуда:
Сообщений: 15330
[quot Денис1]
полиSSD
Именно с такой точки зрения я попытался взять очень слабый старый сервер (6 лет почти), вставить туда "Sun Flash Accelerator F20 PCIe" (очень удачно куплен по случаю в Китае - рекомендую: цена билета туда и обратно значительно меньше полной стоимости карточки :-) ) и посмотреть что получилось.
Если хотелось получить тормоза за те же лицензии, можно поставить OVM.
писюк с 4 ядрами пока еще не редкость, с парой ssd будет дешевле и быстре и по цпу и по io.
17 июл 12, 05:59    [12875512]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
Денис1
Member

Откуда:
Сообщений: 61
-2-
Если хотелось получить тормоза за те же лицензии, можно поставить OVM.
писюк с 4 ядрами пока еще не редкость, с парой ssd будет дешевле и быстре и по цпу и по io.


Проблема с таким подходом - необходимость "to bind guest or virtual machineCPUs to physical CPUs or
cores" (см. "Hard Partitioning with Oracle VM"). Поскольку делается всё это всего несколькими строками в "vm.cfg" файле (cpus= '1-6' etc.) - такая конфигурация имеет тенденцию "исчезать" со временем или очень часто может быть изменена админом для "стресс-тестирования".

Потом приходит аудитор, запускает скриптик и Oracle LMS выкатывают серьёзный счёт.

Я бы *очень* не рекомендовал такой подход.

Кроме того, мне кажется что на маломощном сервере OVM будет расходовать слишком много ресурсов на Dom0 и другие DomU.

Но если все выше приведенные аспекты не смущают - согласен, это проще и дешевле.

К тому же Database Flash Cache можно поместить на одном из тех SSD,
17 июл 12, 12:24    [12877053]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
Paranoiac
Member

Откуда: Saint Petersburg
Сообщений: 389
Доброго времени суток!
Возник вопрос, кто уже делал, поделитесь опытом или статьей...
Купили недавно SSD диски под redo, раньше redo лежали на reiserfs
Вот никак не могу решиться/найти информацию на что их лучше класть,пойдет ли reiserfs на SSD и какие лучше опции монтирования юзать
26 июн 13, 12:06    [14485135]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
mayton
Member

Откуда: loopback
Сообщений: 49785
У reiserfs другое назначение. И вообще откуда пошла такая инициатива?
26 июн 13, 12:26    [14485326]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
Валерий Юринский
Member

Откуда: Москва, "ФОРС Дистрибуция"
Сообщений: 1235
mayton
Я думаю, что redo группы всё равно надо будет кидать на HDD.
Почему?

Например, в Oracle Database Appliance файлы Redo Logs помещаются именно в те ASM-группы,
которые размещены на четырех имеющихся SSD.
26 июн 13, 12:30    [14485365]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
ORA__SQL
Member

Откуда: Moscow
Сообщений: 1774
Paranoiac
Купили недавно SSD диски под redo
Всмысле, SSD под online журналы? Че серьезно? Ну вы еще и RAID5 прикурутите
26 июн 13, 12:32    [14485386]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
Изя Кацман
Member

Откуда: Великий Эксперимент
Сообщений: 2019
ORA__SQL
Paranoiac
Купили недавно SSD диски под redo
Всмысле, SSD под online журналы? Че серьезно? Ну вы еще и RAID5 прикурутите
А если головой подумать, камрад?
Ты хоть сам понял, какую хрень сейчас сказал?
Что общего у SSD и RAID-5? Буква D(isk)? :)
26 июн 13, 12:37    [14485429]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
denix1
Member

Откуда: Киев
Сообщений: 4656
ORA__SQL
Paranoiac
Купили недавно SSD диски под redo
Всмысле, SSD под online журналы? Че серьезно? Ну вы еще и RAID5 прикурутите
к чему такая категоричность ?
чем SSD плох под журналы то ?
ПС: да и RAID5 тоже весьма сносно работает для всего в очень многих случаях
26 июн 13, 12:38    [14485449]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
KoTTT
Member

Откуда: Екб
Сообщений: 1511
Ну не так все просто же
http://www.pythian.com/blog/de-confusing-ssd-for-oracle-databases/
Тестировать, смотреть, снова тестировать, снова смотреть.
Но не "суйте реду на ссд и будет счастье".
26 июн 13, 12:39    [14485455]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
ORA__SQL
Member

Откуда: Moscow
Сообщений: 1774
Изя Кацман
ORA__SQL
пропущено...
Всмысле, SSD под online журналы? Че серьезно? Ну вы еще и RAID5 прикурутите
А если головой подумать, камрад?
Ты хоть сам понял, какую хрень сейчас сказал?
Что общего у SSD и RAID-5? Буква D(isk)? :)
Изя, почеши тыковку и вспомни как работает RAID5 на запись.
26 июн 13, 12:56    [14485663]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
wurdu
Member

Откуда: Владивосток
Сообщений: 4441
Paranoiac
Доброго времени суток!
Возник вопрос, кто уже делал, поделитесь опытом или статьей...
Купили недавно SSD диски под redo, раньше redo лежали на reiserfs
Вот никак не могу решиться/найти информацию на что их лучше класть,пойдет ли reiserfs на SSD и какие лучше опции монтирования юзать
Почитай это: Using flash disk for Redo on Exadata, ну и там продолжение есть про 4K сектор, чтобы можно было сравнять SSD с HDD
26 июн 13, 13:06    [14485776]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
tim_scn
Member

Откуда: Ukraine
Сообщений: 384
ORA__SQL
Изя Кацман
пропущено...
А если головой подумать, камрад?
Ты хоть сам понял, какую хрень сейчас сказал?
Что общего у SSD и RAID-5? Буква D(isk)? :)
Изя, почеши тыковку и вспомни как работает RAID5 на запись.


тип нагрузки при raid5?Sequential Write ?
тип нагрузки при raid10?Sequential Write ?
надеюсь Вы сравниваете Enterprise storage
26 июн 13, 13:26    [14485987]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
-2-
Member

Откуда:
Сообщений: 15330
denix1
чем SSD плох под журналы то ?
не плох, но основная фича ssd - быстрое случайное чтение - бесполезна для redo.
26 июн 13, 13:40    [14486138]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
denix1
Member

Откуда: Киев
Сообщений: 4656
-2-
denix1
чем SSD плох под журналы то ?
не плох, но основная фича ssd - быстрое случайное чтение - бесполезна для redo.
так не про это же речь...
может автору это и не нужно ;)
26 июн 13, 13:43    [14486182]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
tim_scn
Member

Откуда: Ukraine
Сообщений: 384
Валерий Юринский
mayton
Я думаю, что redo группы всё равно надо будет кидать на HDD.
Почему?

Например, в Oracle Database Appliance файлы Redo Logs помещаются именно в те ASM-группы,
которые размещены на четырех имеющихся SSD.


презентация
Under the Hood of Oracle Database Appliance
Alex_Gorbachev_Oracle_Database_Appliance.pdf
+

Cannot use any cache because of shared storage
• I.e. must go to disk every read or write because of another node
• Be careful not to saturate you IO subsystem with excessive
writes
• Tune aggressiveness of DBWR processes (MTTR target)
• Direct path loads are OK - sequential writes are not the same
• This is why online redo logs are on SSD!
• redo write time directly contribute to transactions response time
• 600 MBPS per lane (x8) so theoretical bandwidth 4.8 GBPS
26 июн 13, 13:51    [14486281]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
tim_scn
ORA__SQL
пропущено...
Изя, почеши тыковку и вспомни как работает RAID5 на запись.


тип нагрузки при raid5?Sequential Write ?
тип нагрузки при raid10?Sequential Write ?
надеюсь Вы сравниваете Enterprise storage


Не вопрос
если такой график логфайл синк


| |
| |
| |
____/ \________/ \_____

не асоцируется с (_o_)

26 июн 13, 22:30    [14489147]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
ДохтаР
Member [заблокирован]

Откуда: Новоукраинск
Сообщений: 16864
tim_scn
Sequential


Добавьте чтение-запись на сторадж генерируемую бекапом редологов,
паралельно с записью соседнего записыемого и почуствуйте пиковую энтерпрайз нагрузку.
:)
26 июн 13, 22:38    [14489164]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
tim_scn
Member

Откуда: Ukraine
Сообщений: 384
ДохтаР
tim_scn
Sequential


Добавьте чтение-запись на сторадж генерируемую бекапом редологов,
паралельно с записью соседнего записыемого и почуствуйте пиковую энтерпрайз нагрузку.
:)


бред...удачи.
27 июн 13, 10:11    [14490088]     Ответить | Цитировать Сообщить модератору
 Re: SSD для баз данных?  [new]
DBA with SSDs
Guest
У нас уже пару лет используются SSD. Реальная нагрузка, не синтетика, до устоявшихся 100тыс physical reads per second на некоторых базах. SSD разные, как в составе tiering, так и просто JBOD.
Как показатели тесты, под журналы их использовать не эффективно. Но у нас не много, до 10МБ\сек. С этим легко справляется кэш массива\контроллеров + обычные диски.
Из очевидного, но не планируемого: стало тяжело тестировать приложения. Продакшены легко для однопоточного запроса могут сделать 4-5к sequental reads в секунду, а обычные диски на тестовых окружениях в лучшем случа 200-400. Таже проблема с перемещением архивных данных на более дешевые носители, где данные нужные не часто, но быстро. Как пример архивные данные, логические стендбаи.
Заменить SSD кучей памяти конечно можно до некоторой степени, и память в сравнении со стоимостью лицензий стоит копейки, но кэширование горячих данных и очень быстрый доступ ко всем данным это разные вещи. Плюс проблемы приобретения нового оборудования с уже лицензированным количеством ядер, озвученные выше. Объемы SSD пока еще заметно больше объемов памяти :) Существенных проблем с надежностью не выявлено, т.е. нельзя сказать что они менее надежны чем диски, но у нас не используются бытовые SSD... Как мне кажется SSD это безальтернативное будущее и они в корне меняют отношение к вводу выводу. Их цена меркнет на фоне стоимости лицензий (EE+RAC+Partitioning) и получаемой производительности, если она такая нужна конечно.
Если есть вопросы, то могу попробовать поделиться опытом, но не факт что опыт одного окружения, будет применим к остальным.
27 июн 13, 10:48    [14490274]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9   вперед  Ctrl      все
Все форумы / Oracle Ответить