Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Когда SHRINK лога действительно помогает?  [new]
o-o
Guest
MSSQLBug

Я уже давал вот эту ссылку: http://sqlblog.com/blogs/linchi_shea/archive/2009/02/09/performance-impact-a-large-number-of-virtual-log-files-part-ii.aspx , там тестируют 16 против 20000 VLF-ов, и существенной разницы нет.

интересны первые же слова по ссылке:
In my previous post on the performance impact of having a large number of virtual log files (VLFs) in a transaction log, I showed that a large number of VLFs could be very bad for SQL Server 2008 performance.
идем по предложенной ссылке в первую часть блога и видим такое:

К сообщению приложен файл. Размер - 78Kb
25 дек 14, 18:56    [17053440]     Ответить | Цитировать Сообщить модератору
 Re: Когда SHRINK лога действительно помогает?  [new]
MSSQLBug
Guest
Владислав Колосов
MSSQLBug, они тестировали на Вашем сервере?

Нет, а что?
25 дек 14, 18:57    [17053445]     Ответить | Цитировать Сообщить модератору
 Re: Когда SHRINK лога действительно помогает?  [new]
o-o
Guest
разница между первой частью блога и второй в размерах замеряемых транзакций.
The test workloads were large batch delete, update, and insert. In other words, they were single monolithic transactions that generated a large number of transaction records. Intuitively, these large transactions would cause SQL Server to cross many VLF boundaries and incur the penalty of crossing these boundaries.
The question then became: how about workloads that submit small transactions such as common OLTP workloads?
...
For this OLTP workload, the number of VLFs in the transaction log did not make any significant difference.

когда, простите, показывают, что при больших транзакциях разница есть и опупительна, а при мелких незначительна, НЕКОРРЕКТНО сообщать лишь второе, не уточнять, о каких именно транзакциях речь, да еще и ОБОБЩАТь типа
MSSQLBug
там тестируют 16 против 20000 VLF-ов, и существенной разницы нет.

там проводят 2 разных теста, и их результаты различны.
так давайте же каждый сам свою нагрузку оценит и соответствующие выводы о влиянии/невлиянии числа VLF сделает
25 дек 14, 19:06    [17053485]     Ответить | Цитировать Сообщить модератору
 Re: Когда SHRINK лога действительно помогает?  [new]
MSSQLBug
Guest
o-o
интересны первые же слова по ссылке:
In my previous post on the performance impact of having a large number of virtual log files (VLFs) in a transaction log, I showed that a large number of VLFs could be very bad for SQL Server 2008 performance.


Я прочитал всю эту статью, и для себя сделал вывод, что этот эффект обусловлен размерами самих VLF-ов, а не их количеством (Intuitively, these large transactions would cause SQL Server to cross many VLF boundaries and incur the penalty of crossing these boundaries). Может быть, я что-то не так понял?

При простом DBCC SHRINKFILE, как я понимаю, не изменится ни шаг приращения, ни размеры оставшихся VLF-ов. Если же далее нагрузка не меняется (и прочие ранее описанные причины отсутствуют), по идее, мало что изменится.

Кто-нибудь видел тест именно такого типа?

  • Нарастить LOG-файл достаточно "небольшого" размера с большим количеством VLF так, чтобы все уже упомянутые реальные причины были исключены (внутри области дисков с одинаковой производительностью I/O, VLF должны получиться одинакового размера).
  • Выполнить на этой базе тесты.
  • SHRINK-ануть LOG до 1/10 (1/100, по вкусу ;) ) первоначального размера, но так, чтобы последующие тесты не вызвали роста лога.
  • Опять выполнить тесты и сравнить результаты.
  • 25 дек 14, 19:16    [17053548]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    MSSQLBug
    Guest
    o-o
    когда, простите, показывают, что при больших транзакциях разница есть и опупительна, а при мелких незначительна, НЕКОРРЕКТНО сообщать лишь второе, не уточнять, о каких именно транзакциях речь, да еще и ОБОБЩАТь типа
    MSSQLBug
    там тестируют 16 против 20000 VLF-ов, и существенной разницы нет.

    Да ладно, не так уж и некорректно. ;) См. мой другой ответ.

    o-o
    там проводят 2 разных теста, и их результаты различны.
    так давайте же каждый сам свою нагрузку оценит и соответствующие выводы о влиянии/невлиянии числа VLF сделает


    Как-то мы с Вами несинхронно отвечаем. ;)
    25 дек 14, 19:19    [17053562]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    o-o
    Guest
    MSSQLBug
    Как-то мы с Вами несинхронно отвечаем. ;)

    я сегодня набегами за компом, могу чего и пропустить, если что -- извиняюсь
    MSSQLBug
    Я прочитал всю эту статью, и для себя сделал вывод, что этот эффект обусловлен размерами самих VLF-ов, а не их количеством (Intuitively, these large transactions would cause SQL Server to cross many VLF boundaries and incur the penalty of crossing these boundaries). Может быть, я что-то не так понял?

    автор той статьи все время долбит одно и то же: "a large number of VLFs"
    т.е. именно число, а не размер.
    вы и сами пишете, что все это следствие пересечения большого числа границ VLF-ов,
    ну так сколько границ, столько и VLF-ов, т.е. кучу границ создала именно куча VLF-ов.
    но я это именно к вопросу о том, на что обращает внимание автор статьи.
    а совсем не к тому, прав ли ваш ДБА :)
    25 дек 14, 20:02    [17053740]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    Александр Гладченко
    Member

    Откуда:
    Сообщений: 10779
    Блог
    MSSQLBug
    Александр Гладченко
    Допускаю, что ваш DBA имел ввиду производительность восстановления из копии, если приспичит.

    К сожалению, нет. Прочитайте его прекрасный алгоритм в первом сообщении темы. ;)

    Александр Гладченко
    ИМХО, не взирая на цели, применённая тут практика верна.

    По-моему, "не взирая на цели" --- это слишком сильно сказано.


    Я то прочитал, и хочу обратить Ваше внимание на второй аргумент в моём ответ, почему небольшой лог способен поднять производительность... Предвидя дальнейшие вопросы, напомню, что журнал кешируется агрессивнее файлов данных. Это может стать заметным при малом объёме доступной физической памяти. С учётом модели восстановления, особенно для массовых операций, может потребоваться распределение большого числа экстентов. Всё это сильно "ударит" по буферному пулу и сократит число логических чтений. Не исключено, что приложения вообще при этом "колом встанут"... Смотрите сами, почему может так расти журнал? Часто, именно потому, что серверу дешевле распределить новые страницы, чем вернуть в оборот уже использованные. Если до такого дошло (спасибо дизайну), тогда вызывающие ваше сомнение способы борьбы с подобным "злом" не выглядят такими уж нелепыми. Часто, DBA полагается на некие эмпирические наблюдения за поведение системы, т.ч. не исключено, что он уже определил ту границу роста файла журнала, после которой стоит ждать проблем. К сожалению, вы решили не давать тут полной картины проблемы и делиться своими подозрениями, будь иначе, можно было бы ожидать более предметного обсуждения.

    Сообщение было отредактировано: 25 дек 14, 20:27
    25 дек 14, 20:26    [17053835]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    MSSQLBug
    Guest
    Александр Гладченко
    Я то прочитал, и хочу обратить Ваше внимание на второй аргумент в моём ответ, почему небольшой лог способен поднять производительность... Предвидя дальнейшие вопросы,

    Верно, они будут. ;)

    Александр Гладченко
    напомню, что журнал кешируется агрессивнее файлов данных.

    А где можно про это прочитать, что-то не могу найти ничего конкретного?

    Александр Гладченко
    Это может стать заметным при малом объёме доступной физической памяти. С учётом модели восстановления, особенно для массовых операций, может потребоваться распределение большого числа экстентов. Всё это сильно "ударит" по буферному пулу и сократит число логических чтений. Не исключено, что приложения вообще при этом "колом встанут"...

    Вот тут я не понял... Если, так сказать, "структура" нагрузки остаётся приблизительно такой же, как и до SHRINK-а, то как это влияет?

    Александр Гладченко
    Смотрите сами, почему может так расти журнал? Часто, именно потому, что серверу дешевле распределить новые страницы, чем вернуть в оборот уже использованные.

    Подождите, я-то думал (вот здесь я этого набрался: http://technet.microsoft.com/ru-ru/library/jj835093(v=sql.110).aspx ;) ), что тут выбора у сервера нет (This cycle repeats endlessly, as long as the end of the logical log never reaches the beginning of the logical log), т.е. новые страницы добавляются только тогда, когда log заполнен, это не так?

    Александр Гладченко

    Если до такого дошло (спасибо дизайну), тогда вызывающие ваше сомнение способы борьбы с подобным "злом" не выглядят такими уж нелепыми. Часто, DBA полагается на некие эмпирические наблюдения за поведение системы, т.ч. не исключено, что он уже определил ту границу роста файла журнала, после которой стоит ждать проблем.

    Знаете, его альтернативный вариант действий в случае, если эта самая "граница" не превышена, вызывает у меня некоторые сомнения в том, что он что-то определил. ;)

    Александр Гладченко

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

    Что вы имеете в виду?
    25 дек 14, 21:21    [17054003]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    MSSQLBug
    Guest
    o-o
    автор той статьи все время долбит одно и то же: "a large number of VLFs"
    т.е. именно число, а не размер.
    вы и сами пишете, что все это следствие пересечения большого числа границ VLF-ов,
    ну так сколько границ, столько и VLF-ов, т.е. кучу границ создала именно куча VLF-ов.
    но я это именно к вопросу о том, на что обращает внимание автор статьи.
    а совсем не к тому, прав ли ваш ДБА :)


    Так дело-то в том, что (если все VLF-ы одного размера): Размер лога = кол-во VLF * размер одного VLF.

    Поэтому для 2-х логов того же размера, в одном из которых 20 VLF, а в другом 20000, размеры VLF-ов относятся друг к другу соответственно.

    Т.е. чем больше размер каждого VLF, тем реже пересекаются границы, а SHRINK эти размеры не меняет.
    25 дек 14, 21:30    [17054040]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    o-o
    Guest
    MSSQLBug
    o-o
    автор той статьи все время долбит одно и то же: "a large number of VLFs"
    т.е. именно число, а не размер.
    вы и сами пишете, что все это следствие пересечения большого числа границ VLF-ов,
    ну так сколько границ, столько и VLF-ов, т.е. кучу границ создала именно куча VLF-ов.
    но я это именно к вопросу о том, на что обращает внимание автор статьи.
    а совсем не к тому, прав ли ваш ДБА :)


    Так дело-то в том, что (если все VLF-ы одного размера): Размер лога = кол-во VLF * размер одного VLF.

    Поэтому для 2-х логов того же размера, в одном из которых 20 VLF, а в другом 20000, размеры VLF-ов относятся друг к другу соответственно.

    Т.е. чем больше размер каждого VLF, тем реже пересекаются границы, а SHRINK эти размеры не меняет.

    ну привет, если мы говорим именно об одном и том же фиксированном размере лога,
    то ясно, что говорить о большого размера VLF-ах это то же самое, что говорить об их малом числе,
    и наоборот, говоря о маленьких VLF-чиках, их по-любому больше, чем больших.

    но вы-то же говорите о шринке, т.е. размер лога меняется.
    если все VLF-ы одного размера, то шринк, УМЕНьШАЯ общий размер лога, сокращает и число VLF-ов,
    никак не меняя при этом их размер.
    т.е. границ VLF-ов станет меньше.
    25 дек 14, 21:59    [17054163]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    a_voronin
    Member

    Откуда: Москва
    Сообщений: 4813
    o-o,

    И сколько VLF-ов тогда оптимально делать?
    25 дек 14, 22:00    [17054167]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    o-o
    Guest
    a_voronin
    o-o,

    И сколько VLF-ов тогда оптимально делать?

    так смотря какого размера лог.
    для 1000 Гб-ого лога около тысячи VLF-ов это нормально,
    а для 10 Мб-ого это явно перебор.
    у Рэндала есть опрос населения по этому поводу, график и комментарии.
    сейчас поищу ссылку, а не найду, так картинку завешу
    25 дек 14, 22:05    [17054181]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    o-o
    Guest
    a_voronin
    o-o,

    И сколько VLF-ов тогда оптимально делать?

    Log file configuration metrics for 17000 databases
    самый последний график в этой статье как раз зависимость размер лога <-> число VLF
    + ниже следует куча полезных ссылок по теме
    25 дек 14, 22:13    [17054212]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    MSSQLBug
    Guest
    o-o
    но вы-то же говорите о шринке, т.е. размер лога меняется.
    если все VLF-ы одного размера, то шринк, УМЕНьШАЯ общий размер лога, сокращает и число VLF-ов,
    никак не меняя при этом их размер.
    т.е. границ VLF-ов станет меньше.


    Так дело-то в том, что при одинаковой нагрузке частота пересечения границ VLF-ов зависит только от размера VLF-ов, а при SHRINK-е эти размеры не меняются.
    25 дек 14, 22:18    [17054233]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    o-o
    Guest
    так у вас неодинаковая нагрузка, раз лог _периодически_ растет:
    MSSQLBug
    3. Заявить, что дело было в том, что "разросся лог", и произошло значительное улучшение производительности.

    пусть он у вас вырос до 20 Гб, т.к. кто-то разово перестоил индекс в 20 Гб.
    лог приращивался по 10 Мб, у вас стало 2048 VLF-ов и столько же границ.
    шринканули лог до 100 Мб, стало 10 VLF-ов.
    так и живете с ними, т.к. все транзакции короткие и не объемистые.
    через месяц снова что-то объемное лог раздуло, история повторилась.
    в итоге да, шринком уменьшали число VLF-ов, и еще как
    25 дек 14, 22:45    [17054331]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    MSSQLBug
    Guest
    o-o
    так у вас неодинаковая нагрузка, раз лог _периодически_ растет:
    MSSQLBug
    3. Заявить, что дело было в том, что "разросся лог", и произошло значительное улучшение производительности.



    Вы думаете? ;) Просто DBA смотрит на его размер в основном тогда, когда возникают какие-то проблемы.

    Например, у нас есть база, где формируются аргегаты (выполняется полное обновление данных за всю историю) для ежедневного заполнения OLAP-кубов, и размер лога у неё (пишу по памяти, так что приблизительно) --- где-то четверть от размера базы. И DBA его SHRINK-ает всегда ("он же гигантский!"), если что-то случается, и говорит... см. п. 3.

    Угадайте, какой размер становится у этого файла на следующий день? ;)
    25 дек 14, 23:03    [17054369]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    o-o
    Guest
    MSSQLBug,

    не, я вашего ДБА обсуждать не буду, и вообще одну сторону всегда бесполезно выслушивать.
    я только делюсь прочитанным и теоретически рассуждаю
    лучше к людям с опытом прислушайтесь, я в их число не вхожу
    25 дек 14, 23:47    [17054494]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    aleks2
    Guest
    Александр Гладченко
    Предвидя дальнейшие вопросы, напомню, что журнал кешируется агрессивнее файлов данных.


    Ога. MS SQL/Windows настолько глуп/а/, что кэширует весь журнал лога, даже если он пуст.
    Не смешите публику.

    ЗЫ. Рассуждения о "шринке лога как панацее от всех проблем с быстродействием" бесплодны, ибо как минимум очевидно, что лог приходится потом расширять и уж это то точно требует времени.
    26 дек 14, 07:52    [17054883]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    MSSQLBug
    Guest
    o-o
    MSSQLBug,
    не, я вашего ДБА обсуждать не буду, и вообще одну сторону всегда бесполезно выслушивать.


    Да это:

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


    я к тому, что Ваш вывод:

    o-o
    так у вас неодинаковая нагрузка, раз лог _периодически_ растет


    не так уж и обоснован. ;)
    26 дек 14, 08:26    [17054936]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    Александр Гладченко
    Member

    Откуда:
    Сообщений: 10779
    Блог
    aleks2
    Ога. MS SQL/Windows настолько глуп/а/, что кэширует весь журнал лога, даже если он пуст.
    Не смешите публику.

    Где Вы такое прочитали?

    aleks2
    ЗЫ. Рассуждения о "шринке лога как панацее от всех проблем с быстродействием" бесплодны, ибо как минимум очевидно, что лог приходится потом расширять и уж это то точно требует времени.

    Где сказано, что нужно шринковать до возможного минимума?

    Любезный, не нужно заниматься пустословием!
    26 дек 14, 10:24    [17055481]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    Александр Гладченко
    Member

    Откуда:
    Сообщений: 10779
    Блог
    MSSQLBug,
    Странно, что Вам не удалось найти информацию, которая доступна даже на этом сайте... Лучше вместо "лежащих на поверхности ответов" поясню, что я имел ввиду. Очень похоже, что вы пытаетесь тут не найти ответ, а ищите подтверждение своих претензий к DBA. Вместо того, что бы описать характеристики нагрузки и детализировать принимаемые админом меры, вы затеваете споры и требуете дальнейших разъяснений. Жаль Вас расстраивать, но тут уже сказано достаточно в ответ на первый вопрос. Если лень ходить по ссылкам и докапываться до первоисточников, примите на веру ;) По другим проблемам, лучше открывайте отдельные темы, так будет проще общаться.

    Сообщение было отредактировано: 26 дек 14, 10:36
    26 дек 14, 10:34    [17055552]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    MasterZiv
    Member

    Откуда: Питер
    Сообщений: 34679
    MSSQLBug,

    размер файла логов почти никак не влияет на производительность.
    я написал "почти" на самом деле даже для перестраховки.

    потому что в очень редких случаях оно влияет.

    влияет оно только на объем свободного места на диске.

    1) потому что размер файла лога и размер используемой его части - разные вещи.

    2) потому что лог не используется на чтение (почти) при обычной работе сервера, dml. при работе не Select log используется только на запись, а она производится в фиксированной области лога, её скорость не зависит от размера файлов лога.

    3) даже при использовании snapshot isolation in select statement когда лог используется на чтение, она производится во вполне определенных областях файла, которые заранее известны.

    ваш админ скорее всего не совсем в теме.
    26 дек 14, 10:53    [17055658]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    MasterZiv
    Member

    Откуда: Питер
    Сообщений: 34679
    Гавриленко Сергей Алексеевич
    NickAlex66
    пропущено...

    Таких вариантов нет.
    Очень даже есть. Помогает в случае, если в логе два файла, и второй лежит на более большем, но на менее быстродействующем массиве.


    интересно, сколько же у вас всего массивов, если под журналы вы выделяете два?

    минимум три должно быть.
    богато живете.
    26 дек 14, 10:59    [17055699]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    MasterZiv
    Member

    Откуда: Питер
    Сообщений: 34679
    Александр Гладченко
    Допускаю, что ваш DBA имел ввиду производительность восстановления из копии, если приспичит.
    Шринковать разросшиеся файлы журнала - хорошая практика, особенно, если соблюдать меру и учитывать возможности железа.
    Кроме этого, скромные размеры таких фалов могут требовать меньшего размера оперативки, которую эффективней будет с точке зрения производительности отдать буферному пулу.
    ИМХО, не взирая на цели, применённая тут практика верна.


    скорость восстановления не зависит от размера файлов журнала, а зависит от размера его активной части, той, что после последнего checkpoint.
    26 дек 14, 11:02    [17055726]     Ответить | Цитировать Сообщить модератору
     Re: Когда SHRINK лога действительно помогает?  [new]
    MSSQLBug
    Guest
    Александр Гладченко
    MSSQLBug,
    Странно, что Вам не удалось найти информацию, которая доступна даже на этом сайте...

    А ссылку можно, всё-таки?

    Александр Гладченко
    Лучше вместо "лежащих на поверхности ответов" поясню, что я имел ввиду. Очень похоже, что вы пытаетесь тут не найти ответ, а ищите подтверждение своих претензий к DBA.

    Это была всего лишь предыстория, "искать подтверждение своих претензий к DBA" мне не нужно.

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

    Вы о чём? Вопрос-то мой совсем не в этом...

    Александр Гладченко
    Жаль Вас расстраивать, но тут уже сказано достаточно в ответ на первый вопрос.

    То есть, других вариантов ответа на этот вопрос у Вас нет?

    Александр Гладченко
    Если лень ходить по ссылкам и докапываться до первоисточников, примите на веру ;) По другим проблемам, лучше открывайте отдельные темы, так будет проще общаться.

    А это не другие проблемы, всё это непосредственно относится к обсуждаемому вопросу, IMHO.
    26 дек 14, 11:03    [17055732]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
    Все форумы / Microsoft SQL Server Ответить