powered by simpleCommunicator - 2.0.50     © 2025 Programmizd 02
Форумы / Hardware [игнор отключен] [закрыт для гостей] / New hardware for MS SQL server
26 сообщений из 26, показаны все 2 страниц
New hardware for MS SQL server
    #39270994
user5
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
All,

Чего-то тут совсем тихо и обсуждается только устаревшее железо.
Или все уже сидят на AFA-СХД и особо проблем нет? )

Вообщем встала задача, нужно менять 7-летний DL380G5 32GB, на котором живет MS SQL.
Железо совсем EOL, диски дохнут, нужно бы и памяти добавить.
Там стоит Win 2008 R2 Standard, больше 32GB оно не умеет. Да и память DDR2 покупать сейчас немного странно.
По любому переходить на Win 2012 R2 Standard и все переинсталлировать.
Вообщем, проще купить новый HPE DL380 gen9.

Базы живут на СХД дисках, но система хранения у нас тоже уже старенькая.
Хочется нагрузку c нее немного снять и все сделать на локальных дисках.
Может часть баз оставим.

Новый сервер покупается на те же 5+ лет.

Базы важные: 400GB, логи на 100GB.
TempDB: 25GB + логи
Еще всякие тестовые базы: 300GB+логи.
Нагрузка ~1000 IOPS, но бывают всплески.


Базовая конфигурация сервера, которая будет заказываться:

HPE DL380 gen9 - 2 CPU, 128GB, 2xPSU, P440ar, 8 SFF

Диски:
2 x 240GB SATA SSD Read Intensive-3 (RI-3) под OS/swap
2 x 900GB SAS 10K под локальные бекапы

У этих SSD RI-3 DWPD < 1, можно записать около 315TB, под OS/swap на 5 лет должно хватить.



А вот дальше начинаются муки выбора.

1.
Можно пойти традиционным путем и взять SAS 15K HDD 300GB x 10, сделать raid10 из 8 дисков для БД/логов, 2 диска под temp db.
Но мне кажется немного странно сегодня не делать дисковую систему на SSD, которая перекроет как минимум на 1 порядок традиционные диски по производительности, у которых меньше latency и стоимость не сильно отличается.
На SSD volume можно положить все базы, логи, tempdb.

2.
Смотрим SSD. Они у HPE бывают Write Intensive (DWPD=10), Mixed Use (DWPD=3), Read Intensive (DWPD<=1).
Mixed Use (MU) нам должно хватить на 5 лет, поэтому будем брать эту серию.

Можно взять 2 x 800GB SSD MU в raid1, можно 4 x 400GB MU в raid10 или даже лучше raid5.
SSD бывают SATA и SAS. Двухпортовость SAS нам не нужна в этом сервере, а цена как бы отличается.
DWPD у них одинаковое, в зависимости от модели чуть плавает производительность в IOPS.
Raid нужно делать, т.к. все-таки железо иногда отказывает.

Какая будет аргументация за SAS SSD?
2 x SATA SSD 800GB по деньгам сильно дешевле.

3.
Но пойдем дальше. Сейчас появились платы NVMe SSD PCIe и диски NVMe SSD 2.5".
У них меньше latency, больше производительность, цепляются напрямую к PCIe.
Можно взять HPE 2 x NVMe 800GB MU, но не понятно, как делать raid1. Софтверно?
Минусы - менять плату только с остановом сервера, софтверный raid (?).
Только под заказ.

4.
Можно вставить в сервер корзину на 6 x NVMe MU 2.5" SSD и взять HPE 2 x 800GB MU NVMe 2.5" SSD (они выглядят как диски 2.5", но цепляются напрямую к PCIe).
Опять же вопрос, как делать raid1?
Менять их удобнее.
Только под заказ.
Сильно дороже.

5.
Intel NVMe P3608 1.6TB PCIe. Новая серия у Intel, на одной плате внутри два контроллера, каждый обслуживает свой 800GB диск.
Можно сделать raid1 или raid0 софтом от Intel-а.
DWPD=3, аналог HP MU.
Есть в наличие, Intel дает гарантию 5 лет, HPE - 3 года.
Производительность в 2-4 раза выше, чем у HPE.
Минус - одна плата, в случае умирания придется ее снимать и ехать в ремонт.

6.
Intel NVMe P3700 2 x 800GB
DWPD=10, аналог HPE WI.
Производительность хуже P3608, но за глаза хватит.
Есть в наличие, гарантия 5 лет
Софтверный raid ?


Взвесим плюсы и минусы NVMe:

HPE:
+ железо от одного вендора, работающий мониторинг через SIM/агентов.
- все позиции SSD не ходовые и только под заказ на 4-6 недель.
- ценник HPE повыше будет на 30-40%.

Intel:
+ есть в наличие, 5 лет гарантии, производительность, дешевле HPE.
- с мониторингом не понятно, с одной платой P3608 хуже надежность.


По ценам HDD/SSD/NVMe получается в $4-8K дополнительно и вообщем сопоставимо.

Ну и что выбрать? Аааааааа!
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39270996
JVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
user5,

Без виртуализации живете? Я когда старый хлам апгрейдил, года три назад, все перевел на виртуалки з живой миграцией и балансировкой. Отделил, так сказать душу от тела. Сильно упростилась жисть.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39270997
JVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А новое железо все равно будет быстрее, чем старое, по-любому. Так, что не мучайся. Думай об удобстве работы и дальнейших миграциях. В виртуале оно намного приятнее.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39270999
user5
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
JVFА новое железо все равно будет быстрее, чем старое, по-любому. Так, что не мучайся. Думай об удобстве работы и дальнейших миграциях. В виртуале оно намного приятнее.

Все уже виртуализировано.
SQL пока не готовы. Нужно тогда пару блейдов одинаковых покупать и СХД апгрейдить. Пару лет еще подождем.
Дешевые локальные диски странно не использовать.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39271001
JVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
user5Дешевые локальные диски странно не использовать.Да, локальные диски не используем. Не вписываются в концепцию. Да и на сторедже плюшек гораздо больше - снапшоты, моментальное клонирование баз, лайв майгрейшн, восстановление и прочие нищяки.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39271898
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
user5All,

Чего-то тут совсем тихо и обсуждается только устаревшее железо.
Или все уже сидят на AFA-СХД и особо проблем нет? )
Ну почему же :)
Новый сервер покупается на те же 5+ лет.

Базы важные: 400GB, логи на 100GB.
TempDB: 25GB + логи
Еще всякие тестовые базы: 300GB+логи.
Нагрузка ~1000 IOPS, но бывают всплески.


Базовая конфигурация сервера, которая будет заказываться:

HPE DL380 gen9 - 2 CPU, 128GB, 2xPSU, P440ar, 8 SFF

Диски:
2 x 240GB SATA SSD Read Intensive-3 (RI-3) под OS/swap
2 x 900GB SAS 10K под локальные бекапы

У этих SSD RI-3 DWPD < 1, можно записать около 315TB, под OS/swap на 5 лет должно хватить.
...
А вот дальше начинаются муки выбора.
...
Ну и что выбрать? Аааааааа!
Для начала - HPE без вариантов ?
Есть ведь и другие брэнды первого уровня, и другие локальные брэнды по заметно более другим ценам.
Но это вопрос Вашего корпоративного стандарта, конечно.

NVMe в нынешней версии стандарта под Вашу задачу особенного смысла не имеют.
Причина - они не умеют в аппаратный RAID и имеют цену чугунного моста, особенно от НРЕ: и дело не в "жадности" НРЕ, а в вендорах, ОЕМящих для НРЕ: это Fusion-IO, у них цена исторически.. тяжеловата, скажем так, в версиях под любыми лейблами.
Вкрячивание интеловских SSD/NVMe чревато тем, что при любом кейсе саппорт НРЕ, для начала, вежливо попросит Вас убрать из сервера сторонние комплектующие. До, собственно, начала работы по этому кейсу. А так- в их сервисном соглашении есть строки, позволяющие им теоретически и отказаться от гарантии на сервер в целом на этот случай.
Ну и опять-таки, использование NVMe - к нему надо подходить осторожно: с каждого процессора выходит 40 линий PCI-E, и заметная их часть (по крайней мере, от первого процессора) уже задействована - под всякие разные набортные устройства. Каждый NVMe нынешний "съест" 4 линии, если что. Конкретно в серверах НРЕ - потребуется установка специализированного кита под них (NVMe), который тоже заказной.

По дисковой подсистеме:
По уму, если брать с запасом - я бы рекомендовал что-то типа 4-6х 800-1.2ТБ SSD SATA/SAS (по бюджету, вендору и модели) Mixed Use (3-5 DWPD) в RAID10 под Вашу базу, в идеале - на аппаратном RAID SAS 12G, с кэшем и его защитой.
Это сделает жизнь сильно проще, причем Вашу в первую очередь.
Использовать жесткие диски, особенно малой емкости в качестве высокопроизводителей накопителей под БД при нынешних ценах на SSD - занятие уже бессмысленное.

Процессоры: обратите внимание, что процессоры серии E5-2600v3 имеют лучшую производительность на ядро (относительно v4) - но меньше ядер, E5-2600v4 наоборот. Но в обоих сериях имеются высокочастотные (4-10-12 ядер 3+ ГГц) процессоры.
Что именно для Ваших задач лучше (много ядер на 2.1-2.2 ГГц / производительность на ядро (2.3-2.6ГГц) + ядра / высокая производительность на ядро (3+ ГГц) и относительно мало ядер - это смотрите сами, из Ваших нагрузок.

ОЗУ: очень рекомендую использовать LR-DIMM сразу. Причина проста - Load-Reduced DIMM это современная реинкарнация FB-DIMM (Full-Buffered DIMM), при их набивании "до упора" (до 3 модулей на канал, у каждого процессора - 4 канала к ОЗУ, итого - до 24 модулей на сервер такого типа) частота, на которой работает процессор с ОЗУ, не падает.
У обычных "держится" до 2 модулей на канал, затем на 3 модулях на канал - "падает" на шаг (с 2400 на 2133 МГц для "старших" v4, например).
LR-DIMM имеют емкость от 32ГБ и стоят несколько дороже, чем "обычные" модули - но разница не слишком велика.

По сети - HPM (High-Performance Model) модели HPE (от E5-2650v3/v4 и выше) уже имеют на борту 10 Гбитки.
Возможно, имеет смысл думать таки о модернизации своей сети - и вовсе не обязательно брать какие-то адовы Нексусы под 24-48 портов, у того же HP есть свичи от Aruba - 2920 серия, с 4 портами, куда можно привесить 10Гбит (RJ-45 кат. 6 или SFP+).
Как-то так.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39274666
user5
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
a_shats, спасибо за ответ.

Да, у нас только HPE.
По CPU согласен.

По дискам - тоже больше склоняюсь к raid из SSD.
А из каких соображений RAID10, почему не RAID5?

По поводу NVMe. Вот делают софтверный raid для OS из обычных дисков.
Почему не сделать софтверный raid из NVMe для данных? ;-)
Ну или какой драйвер, который делает псевдо-аппаратный raid типа как у Intel.

Вы случайно не работаете в локальном производителе серверов? ;-)
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39274673
user5
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Еще по поводу NVMe.
Интел делает хорошие SSD.
Все вендоры (Cisco/HPE/etc) используют их SSD в своих серверах.
Если NVMe пойдут в рынок, то все возьмут Intel в свои линейки.
Нужно еще 1-2 года подождать ;-)
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39274780
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А из каких соображений RAID10, почему не RAID5?
Даже если бы в RAID5 был какой-то смысл (ну дедупликация работала б, например) - не вижу смысла нагибать считалку RAID-контроллера дурной нагрузкой, которая, по большому счету, служебная.
По поводу NVMe. Вот делают софтверный raid для OS из обычных дисков.
Почему не сделать софтверный raid из NVMe для данных? ;-)
Сделать - не проблема. Проблема в том, что софтовые RAID несколько хуже и неудобней управляются/мониторятся/абстрагируют накопители от ОС, чем аппаратные.
Ну и самих NVMe уже много не набить в принципе, количество PCI-E линий ограничено.
Вы случайно не работаете в локальном производителе серверов? ;-)
И даже не случайно работаю :D
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39275341
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
user5На SSD volume можно положить все базы, логи, tempdb.

логи не стоит
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39279534
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JVFuser5,

Без виртуализации живете? Я когда старый хлам апгрейдил, года три назад, все перевел на виртуалки з живой миграцией и балансировкой. Отделил, так сказать душу от тела. Сильно упростилась жисть.

Что в качестве гипервизора используете?
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39279572
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критикuser5На SSD volume можно положить все базы, логи, tempdb.

логи не стоит

почему?
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39279630
rahzer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
HettКритикпропущено...


логи не стоит

почему?
Насколько я помню из рекомендаций, то на логи, почти все подавляющее большинство идет потоковой записи (ну если откатов не идет), а с потоковой записью классические винты справляются лучше, чем SSD (правда самый распоследние SSD не было возможности тестить на этот счет)
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39279644
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вместо "не стоит" точнее было бы написать "не имеет смысла" ))) ИМХУ

Но вообще, у __дешевых__ ССД есть реальные проблемы при большой и массивной записи. У меня десктопный ССД "умирает" при попытке одновременного обновления 3-4 гб. У ентерпрайзных так явно выраженно быть не должно.

Могу ошибаться. Не админ и не железячник ))))
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39279655
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid Kudryavtsev,

как понимаю, тот же инсерт будет считаться завершенным только после записи в лог? А в случае с HDD на это уйдет куда больше времени.

если какой-нибудь samsung evo юзать, то конечно он до 50 МБ/с просядет при активной записи, но с теми же Plextor линейки pro такой проблемы нет. Я уж не говорю о энтерпрайз железках.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39280168
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
rahzerНасколько я помню из рекомендаций, то на логи, почти все подавляющее большинство идет потоковой записи (ну если откатов не идет), а с потоковой записью классические винты справляются лучше, чем SSD (правда самый распоследние SSD не было возможности тестить на этот счет)
Но как, сэр ? (с)
Дисков, чтобы реализовать производительность (гарантированную) на запись при такой нагрузке - нужно сильно больше, чем SSD - и латентность этого хозяйства (вкупе с RAID-контроллером) будет сильно хуже.
Разумеется, речь идет об Enterprise SSD.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39280296
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Лог - это последовательная запись почти 100% времени.
Нет никакого смысла в трате ограниченного и дорогого ресурса SSD на то, с чем отлично справляются обычные HDD.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39280369
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Критик,

"Ограниченный" и "дорогой" - это эмоции.
На деле - самые низкоресурсные Enterprise SSD имеют ресурс 0,3- 1 объема перезаписи в сутки на 3-5 лет (в зависимости от вендора и модели). Гарантийный, подчеркиваю.
То есть на нещасную 120 ГБ SSDшку Intel S3510 - гарантийный ресурс 40 ГБ перезаписи в сутки. Цена ей - средняя с Я. Маркета - 7500 руб. на момент написания данного поста. При этом она (на синтетике, разумеется) выдает 68К иопсов на чтение и что-то с 10К на запись, IRL несколько меньше, но тоже неслабо. Что с дисками сравнивать как-то странно.

Если у Вас на такие дешевые вещи предполагается бОльший объем перезаписи в среднем - значит, Вы что-то не так делаете.

Среднересурсные - это 3-5 DWPD: то есть Intel S3610 200GB - это уже 600 ГБ/сутки на 5 лет, гарантия.
Разумеется, под всякого рода кэши такое не ставят - но оно и стоит немногим дороже, чем S3510.

Реально дорогие - это высокоресурсные SAS/SATA (10+ DWPD) и NVMe, но те, кому они нужны, эмоциональные оценки при проектировании решений не используют.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39280668
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hettкак понимаю, тот же инсерт будет считаться завершенным только после записи в лог? А в случае с HDD на это уйдет куда больше времени.
AFAIK

Про MS не знаю, но в Oracle - не insert, а commit. При этом за одну операцию flush'а на диск может и сразу много commit'ов сброситься. Т.ч. если диск занять только логами и не загружен другими задачами (никто головки с последнего места записи не украдет) - то на IOPs скорее всего будет глубоко пофиг
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39280672
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevHettкак понимаю, тот же инсерт будет считаться завершенным только после записи в лог? А в случае с HDD на это уйдет куда больше времени.
AFAIK

Про MS не знаю, но в Oracle - не insert, а commit. При этом за одну операцию flush'а на диск может и сразу много commit'ов сброситься. Т.ч. если диск занять только логами и не загружен другими задачами (никто головки с последнего места записи не украдет) - то на IOPs скорее всего будет глубоко пофигВ сиквеле так же.
Нагрузка на лог-файл последовательная, задержка будет действительно небольшая.

Однако, средний SSD всё равно тут будет быстрее HDD, даже в таких условиях, хотя и не так кардинально, как для случайного доступа.

КритикЛог - это последовательная запись почти 100% времени.
Нет никакого смысла в трате ограниченного и дорогого ресурса SSD на то, с чем отлично справляются обычные HDD.Согласен с a_shats, стоимость SSD уже такова, что даже для последовательного доступа в случае файлов транзакций они пусть не выигрывают однозначно по соотношению цена/производительность, но, по крайней мере, проигрывают немного.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39280676
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Запись HDD - 150мб/с в лучшем случае
Запись SSD - 500 в худшем.
Можно и тест синтетический провести ради интереса.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39280727
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
HettЗапись HDD - 150мб/с в лучшем случае
Запись SSD - 500 в худшем.
Можно и тест синтетический провести ради интереса.
И.... ?

Я думаю, что такую нагрузку на redo log'и (в терминах Oracle), кроме как у Сбербанка найти сложно. Но, я так же думаю, что SSD им все равно не поможет, как не помогает 256 процессоров в сервере.... ))))

Другое дело, что вряд ли кто-то будет городить зоопарк из SSD / HDD и раскладывать все по разным дискам. Да и целиком HDD отдавать только под redo - как то стремно, у HDD объемы нехилые, а активные redo ... ну пара-десяток гигабайт max.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39280985
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvgСогласен с a_shats, стоимость SSD уже такова, что даже для последовательного доступа в случае файлов транзакций они пусть не выигрывают однозначно по соотношению цена/производительность, но, по крайней мере, проигрывают немного.
Чуток уточню - Вы, наверное, имели в виду соотношение цена/объем. По цене/производительности уже выигрывают, и достаточно давно: десяток SAS 15K у вышеописанной мной SSDшки на запись выиграют в iops крайне вряд ли, а вот стоить будут очень сильно дороже (и это без учета контроллера, который к этим дискам потребуется, и прочего - бэкплейна/кабелей/пр.).
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39281573
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shatsalexeyvgСогласен с a_shats, стоимость SSD уже такова, что даже для последовательного доступа в случае файлов транзакций они пусть не выигрывают однозначно по соотношению цена/производительность, но, по крайней мере, проигрывают немного.
Чуток уточню - Вы, наверное, имели в виду соотношение цена/объем. По цене/производительности уже выигрывают, и достаточно давно: десяток SAS 15K у вышеописанной мной SSDшки на запись выиграют в iops крайне вряд ли, а вот стоить будут очень сильно дороже (и это без учета контроллера, который к этим дискам потребуется, и прочего - бэкплейна/кабелей/пр.).Я же пишу про последовательный доступ, тут же не такая большая разница. Неужели десяток SAS 15K в RAID10 не обгонят уверенно пару SSD (не NVMe) в зеркале при последовательной записи?

А если вы говорите про iops-ы, то, наверное, про случайный доступ? Тут, конечно, SSD сейчас далеко впереди по соотношению цена/производительность.

Это не укладывается в голове, это странно, но если вы хотите сэкономить, покупайте SSD - к этому трудно привыкнуть :-)
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39281723
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvgЯ же пишу про последовательный доступ, тут же не такая большая разница. Неужели десяток SAS 15K в RAID10 не обгонят уверенно пару SSD (не NVMe) в зеркале при последовательной записи?

А если вы говорите про iops-ы, то, наверное, про случайный доступ? Тут, конечно, SSD сейчас далеко впереди по соотношению цена/производительность.

Это не укладывается в голове, это странно, но если вы хотите сэкономить, покупайте SSD - к этому трудно привыкнуть :-)
А, просто я Вас не совсем правильно понял.
Тут такое дело...
Если взять даже SAS SSD (от того же HGST или Тошибы) - нет, не догонят, при этом один SSD будет всё равно дешевле десятка SAS 15K.
SATA SSD ограничены интерфейсом 6G, но и 480-500 МБайт/с на запись - это штука, трудно достижимая на дисках за сравнимые деньги: к дискам, напоминаю, нужен какой-никакой контроллер и кабели к нему.
...
Рейтинг: 0 / 0
New hardware for MS SQL server
    #39290735
Фотография Hett
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonid KudryavtsevHettкак понимаю, тот же инсерт будет считаться завершенным только после записи в лог? А в случае с HDD на это уйдет куда больше времени.
AFAIK

Про MS не знаю, но в Oracle - не insert, а commit. При этом за одну операцию flush'а на диск может и сразу много commit'ов сброситься. Т.ч. если диск занять только логами и не загружен другими задачами (никто головки с последнего места записи не украдет) - то на IOPs скорее всего будет глубоко пофиг

Вчера один случай произошел, и вспомнил эту тему.
Есть сервер с 4 хорошими SSD, массив 0+1. Все данные и логи пишутся на них.
Так же следует отметить, что в силу особенностей архитектуры MySQL, для репликации у них ведутся отдельные логи (bin-log). Т.е. происходит запись самих данных, данных транзакционного лога (если это InnoDB), и логи для слейвов.

Так вот настроили слейв, данные движка положили на SSD, а логи репликации на HDD.
Слейв стал не то чтобы не догонял мастера, а он с приличной скоростью отставал. Сначала не поняли в чем дело, потом вспомнили про эти логи. (был смонтирован /var/lib/mysql только на SSD)
В итоге все решилось тем, что и bin-log убрали на тот же SSD. Вот вам и последовательная запись.
...
Рейтинг: 0 / 0
26 сообщений из 26, показаны все 2 страниц
Форумы / Hardware [игнор отключен] [закрыт для гостей] / New hardware for MS SQL server
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]