в соседнем чатике по автоматизации интим-фото предлагают, а тут всего-то песенка )

О, где?

Сфоткаю свой сервер, не дорого 🤣🤣🤣

Человек чатом ошибся, думаю. Поправит

Зато видно, жизнь кипит)))

Добрый день! Хотел бы с вами проконсультироваться по анализу утилизации дисковой подсистемы. На сервере БД oracle используется ASM, создана группа дисков и в нее включен один диск, по мониторингу видим, что длина дисковой очереди под нагрузкой достигает значения 150. Хотелось бы узнать, какие критерии допустимых значений в таком случае? как если бы был raid массив, кол-во дисков в массиве*2? А тут по аналогии кол-во дисков в группе дисков ASM или это не так работает?

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

запись размазывается по дискам не равномерно, количество дисков может меняться и т.д.

так что вообще забей на очередь как метрику, по которой можно искать проблемы

используй её разве что для сравнения двух тестов

а ориентируйся на время отклика

в линуксе - ioTime, servTime

в Windows
AVG sec/read
AVG sec/write

если время отклика регулярно превышает 3-5ms - стоит начать беспокоиться

может прокачать СХД, может сократить объёмы IO, может размазать нагрузку по нескольким серверам

@Ganeles спасибо за развернутый ответ, Витя!)

Коллеги, есть идеи, что могло так повлиять?

Обновили MSSQL 2012 => 2016(в режиме совместимости с 2012), и в первых трёх тестах (2 дня после обновления) утилизация CPU на БД была в разы больше - вместо 30% все 100%, с соответствующим (плохим) поведением системы.

А на третий день внезапно всё вернулось к изначальному состоянию.

сперва подумали, что дело в перестройке планов, но количество Compilation/sec и Recompilation/sec не особо изменилось.

теперь боязно на проде переходить на 2016 :)
вдруг там тоже пару дней всё лежать будет?