|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Всем привет. Интересно ваше мнение, допустим есть 200 баз, равнонагруженных, где они будет эффективнее работать, на 4х серверах или на 2х с удвоенными ресурсами. Где процессоры будет эффективнее, в связке 4х8 или 2х16 Где будет эффективнее использоваться память 4х128 или 2х256 Диски из дискового хранилища. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 09:14 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Размеры активной части данных в рамках каждой базы? Какая нагрузка (DW/OLTP)? Со всеми базами одновременно работают в пике? Версия сиквела? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 09:24 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Sergey Syrovatchenko, Допустим нагрузка равномерная и разнообразная, где то больше пишут, где то больше читают, время пика для каждой из баз разнесено по суткам. Сервера активно используют связи с линкованными серверами в запросах. OLTP 2x2019 Ent 4x2019 St ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 09:30 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Топлю за вариант 4*Std который будет банально дешевле + DELAYED_DURABILITY включаем чтобы снизить нагрузку на диски от OLTP нагрузки. AlwaysOn планируете? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 09:37 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Sergey Syrovatchenko, Пока нет, бизнес устраивает вариант с восстановлением данных из бэкапов с простоем на это время. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 10:29 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
teCa, пространство буферного пула, plan cache и tempdb на один инстанс общее для всех баз. эффективней с моей точки зрения будет 4 сервера. Sergey Syrovatchenko, для прома OLTP DELAYED_DURABILITY? да вы рисковый :) ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 10:32 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
teCa, решение должно быть в пользу суммарного количества ядер, памяти, объема и скорости дисков. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 10:41 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
felix_ff, С точки зрения администрирования так же удобно обслуживать 4 сервера вместо двух, при банальной перезагрузке недоступной становиться лишь четверть ресурсов, но так же присутствует большое количество OLEDB обращений между серверами, которое тормозит выполнение запросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 10:42 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Владислав Колосов, те в пользу 2х серверов с большими ресурсами? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 10:42 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
teCa, при равных объемах ресурсов лучше два сервера. Сто баз на одном и сто на другом. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 10:44 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Sergey Syrovatchenko, почитал вашу статью о Delayed Durability. Чувствуется, что вы плотно в теме. Вопрос - каков риск сломать базу при сбое при включенном DD? На проде конечно ставить боязно, но вот на STAGE почему нет? Там нет постоянных данных, а сломается, так можно быстро поднять из бекапа. Но это все равно морока. Или есть ещё какие-то скрытые нюансы? Заранее благодарен. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 10:46 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
felix_ffдля прома OLTP DELAYED_DURABILITY? да вы рисковый :) SQL2008Вопрос - каков риск сломать базу при сбое при включенном DD? Если на проекте используются услуги датацентров и нет проблем с бесперебойниками, то не вижу проблем с включением этой опции. SQL2008Или есть ещё какие-то скрытые нюансы? Я их не знаю. В моем случае из коробки всегда снижало нагрузку на диски от WRITELOG ожиданий. Если кто сталкивался с проблемами при использовании DELAYED_DURABILITY, то присоединяюсь к обсуждению. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 11:05 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Sergey Syrovatchenko, А как перезагрузку производите? Как я понял, использование DELAYED_DURABILITY не имеет механизм обработки перезагрузок, те, даже при перезагрузке есть риск потерять часть транзакций. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 11:10 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
teCa, перед перезагрузкой штатно (самим сиквелом) вызывается sys.sp_flush_log и сервер перестает принимать новые соединения, поэтому не должно быть проблем. Я не утверждаю что проблем не будет, но сколько я читал и проверял так и не смог сделать репро когда проблема бы себя проявила. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 11:20 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Sergey Syrovatchenko, там нет гарантии запуска при штатной перезагрузке: в случае тушения сервера нужно явно вызывать sys.sp_flush_log For delayed durability, there is no difference between an unexpected shutdown and an expected shutdown/restart of SQL Server. Like catastrophic events, you should plan for data loss. In a planned shutdown/restart some transactions that have not been written to disk may first be saved to disk, but you should not plan on it. Plan as though a shutdown/restart, whether planned or unplanned, loses the data the same as a catastrophic event. принцип использования/не использования DD сводится к ответу на простой вопрос: важно ли нам что часть данных может быть потеряна? если ответ да, то DD использовать не желательно. но согласен эта штука полезная особенно на тестовых контурах / стейджевых стендах не требовательных к консистетности данных или способных быстро их восстановить. полагаться на датацентры, хорошие упсы и.т.д я бы в таком вопросе не стал, как говорится "раз в жизни даже палка стреляет" :) ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 11:33 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Sergey Syrovatchenko, Еще не понял, как sys.sp_flush_log ограничивает подключение к серверу? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 11:38 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
felix_ff, не хочу спорить с тем что написано в справке. Вот прям сейчас создал БД с включенной DD + таблицу (1 поле INT). Вставляю 1 строку (чекпоинта нет смотрел через XEvent) других транзакций тоже... а значит все в LogBuffer и физически в файл лога не ушло. Следуя логике работы DD... насильно убиваю процесс сиквела. Стартую процесс. База онлайн и запись физически вставилась. Тогда получается магия какая-то. Но данные у меня не получается потерять. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 11:58 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Sergey Syrovatchenko Если на проекте используются услуги датацентров и нет проблем с бесперебойниками, то не вижу проблем с включением этой опции. Да, все сервера на виртуальных машинах в ДЦ. Более того, даже разовый сбой не очень критичен, так как во второй раз все прогрузится снова. Это отчетные системы, а не операционные. Спасибо за развернутый ответ! ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 12:01 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Sergey Syrovatchenko, В инструкции так же написано, что сервер определяет загруженность дисковой системы, и если она не загружена, то транзакции фиксируются сразу. Так же интересно, есть ли возможность следить за размером LogBuffer ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 12:24 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Мнения разделились. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.07.2021, 16:31 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
SQL2008 Sergey Syrovatchenko, почитал вашу статью о Delayed Durability. Чувствуется, что вы плотно в теме. Вопрос - каков риск сломать базу при сбое при включенном DD? На проде конечно ставить боязно, но вот на STAGE почему нет? Там нет постоянных данных, а сломается, так можно быстро поднять из бекапа. Но это все равно морока. Или есть ещё какие-то скрытые нюансы? Заранее благодарен. Я использую "отложенную устойчивость" :-) в ETL задачах. Только не форсированную, а управляемую. Т.к. новые данные грузятся в рядомстоящие секции, а потом подменяются свитчем, то проблема потери данных при перезагрузке или сбое не стоит вообще. Все равно данные заново перезагружать. Скорость загрузки выросла в 4 раза. Если раньше типовые 10 млн. записей грузились час, то сейчас - 15 минут. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2021, 10:48 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
teCa felix_ff, С точки зрения администрирования так же удобно обслуживать 4 сервера вместо двух, при банальной перезагрузке недоступной становиться лишь четверть ресурсов, но так же присутствует большое количество OLEDB обращений между серверами, которое тормозит выполнение запросов. Стандарты, хоть и дешевле, обладают "особенностями", которые сразу начинают выпирать. Во-первых, 128 Гб ОЗУ - откровенно мало. Это значит, что суммарный объем баз под OLTP нагрузкой у вас будет всего где-то гигабайт 500, прежде чем пользователи начнут жаловаться на задумчивость БД. Опять же процессоров - всего 24. Ну, если в базу не летит ничего сложнее чем select * from tbl where id=1, то не критично, а если разработчики предпочитают изъясняться в стиле "Воины и Мира"? У меня есть OLTP система, где типовые запросы - строк по 500, а запрос, формирующий "оперативную отчетность" - немного не дотягивает до 8 тыс. строк. Запрос. Один. Но не будем о грустном. Онлайновое перестроение индексов - нужно не часто, но иногда бывает. Ну и с управлением ресурсами и аудитом - всё сильно лучше. Поэтому если речь идет именно о 2 энтерпрайзах против 4 стандартов - я однозначно выберу 2 энтерпрайза. Разумеется, если мне не придется оплачивать их из своего кармана. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2021, 11:12 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
teCa Всем привет. Интересно ваше мнение, допустим есть 200 баз, равнонагруженных, где они будет эффективнее работать, на 4х серверах или на 2х с удвоенными ресурсами. Где процессоры будет эффективнее, в связке 4х8 или 2х16 Где будет эффективнее использоваться память 4х128 или 2х256 Диски из дискового хранилища. Теоретически, если "все одинаково" - будет одинаково. Практически, "все одинаково" - недостижимая фантазия. В абстрактной реальности, отдельный сервер "аналогичной" производительности обеспечит 1-й базе большее быстродействие, чем N баз на одном сервере Nx"аналогичной" производительности. Ибо, кроме памяти дисков и процессора есть, как минимум, еще шина и сеть. В суровой реальности, никто не даст вам N серверов "аналогичной" производительности. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.07.2021, 15:26 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
Попробовал я применить DELAYED_DURABILITY на одном из серверов. На этом сервере, как раз присутствует высокое значение ожиданий записи лога. Применил на самую на базу DELAYED_DURABILITY FORCED, которая единственная на диске и этот диск испытывает высокие нагрузки. Вот график очередей на диске во время ночных расчетов, красной линией разделил до включения и после. Как видно по графику, нагрузка на диск не многим изменилась. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.07.2021, 11:06 |
|
Что будет эффективнее? Теоретически.
|
|||
---|---|---|---|
#18+
teCa Попробовал я применить DELAYED_DURABILITY на одном из серверов. На этом сервере, как раз присутствует высокое значение ожиданий записи лога. Применил на самую на базу DELAYED_DURABILITY FORCED, которая единственная на диске и этот диск испытывает высокие нагрузки. Вот график очередей на диске во время ночных расчетов, красной линией разделил до включения и после. Как видно по графику, нагрузка на диск не многим изменилась. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.07.2021, 11:46 |
|
|
start [/forum/topic.php?fid=46&fpage=20&tid=1684543]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
93ms |
get tp. blocked users: |
2ms |
others: | 260ms |
total: | 435ms |
0 / 0 |