[Из песочницы] Анализ работы MS SQL Server, для тех кто видит его впервые24.08.2017 14:33

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

• Marwin

  24.08.17 в 13:50

  0

  Меня (возможно и не только меня) уже на протяжении многих лет в разных проектах преследует спонтанно возникающий глюк у mssql: условно говоря раз в месяц/другой (но строгой периодичности нет) он беспричинно начинает грузить одно ядро процессора и почти перестает отвечать на запросы. Что я только ни делал… обрубал все сетевые коннекты, останавливал сайты, даже рестартовал инстанс- всё равно он сразу возвращался к тормозам. В логах и профайлере никаких признаков ддоса или циклических запросов выявить не могу. Чаще всего помогает ребут винды.

  • 71rmn

    24.08.17 в 14:08

    0

    в разделе про анализ активности пользователей (в процессе написания) освещу вопросы как посмотреть кто именно работает, что делает при этом и сколько каких ресурсов потребляет.
    надеюсь, статья вам поможет

    • Marwin

      24.08.17 в 14:17

      0

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

• ildarz

  24.08.17 в 14:03

  0

  Что касается нагрузки на диски — в первую очередь нужно выучить, что такое IOPS и как они связаны с пропускной способностью. И тогда внезапно может стать понятно, что, например, 50Мб/сек на 4K блоках со случайным доступом может быть совсем не мало, и высокая очередь — это никакие не проблемы с железом, а банально недостаточно производительная дисковая.

  
  

  не смешивайте файлы ОС с файлами данных БД. Размещайте их на физически разных носителях чтобы система не конкурировала с СУБД за ввод-вывод.

  А что, разве ОС сама по себе создает какую-то серьезную нагрузку на диски? Разве только при постоянном своппинге, но тогда не о разнесении нагрузки на разные диски думать надо, а совсем о другом. Предлагаю вам на досуге померять, что будет быстрее — ОС + СУБД на RAID-10 из 4-х дисков, или ОС и СУБД на отдельных зеркалах.

  
  

  И т.д, и т.п.

  
  

  Резюмируя — на самом деле нужна голова на плечах и минимальное понимание происходящих процессов. Тогда половина рекомендаций в таких статьях сразу окажутся капитанскими, а вторая половина — вредными.

  • 71rmn

    24.08.17 в 14:11

    0

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

    • ildarz

      24.08.17 в 14:18

      0

      Я не вижу, как это может произойти, если вы описываете волшебные пилюли вместо того, чтобы давать понимание. Для примера — ну нельзя понять, что в случае СУБД происходит с нагрузкой на диски, не оперируя понятием IOPS, а вы это даже мимоходом не упоминаете.

      • 71rmn

        24.08.17 в 14:25

        0

        исходил из предположения что мсскл пишет данные страницами. в этом случае зависимость между IOPS и Mb/s — линейная.
        просто для меня лично удобнее прокачку оценивать в Мб/с, но тут кому как.

  • MrRoger

    24.08.17 в 14:26

    0

    Автор, скорее всего, имел ввиду не размещать на одном логическом диске файлы mdf и ldf. Т.к. mdf пишется параллельно, а ldf последовательно. Тут может быть гонка на ввод-вывод, если они рядом.

  • 71rmn

    24.08.17 в 14:32

    0

    А что, разве ОС сама по себе создает какую-то серьезную нагрузку на диски?

    
    ОС может и не создает, но сам диск может оказаться совсем не производительным. Встречал случаи когда С: создан внутри виртуальной машины которая лежит на общей хранилке с кучей всего остального и производительность там совсем никакая.
    В таком случае, вполне разумно файлы БД убрать с С:.
    прошу не воспринимать раздел «советы» как руководство к действию, а лучше как «варианты на подумать».

© Habrahabr.ru