Лига Сисадминов

Символ | (вертикальная черта) — это оператор конвейера. Его задача — взять результат (вывод) команды, стоящей слева от него, и передать его на вход команде, стоящей справа.

Команда 1 (создает объекты) → | → Команда 2 (получает и обрабатывает объекты) → | → Команда 3 (получает обработанные объекты) → | ...

Классический UNIX-конвейер: Поток текста

В bash по конвейеру передается поток байтов, который обычно интерпретируется как текст.

Найти все процессы 'nginx' и посчитать их количество
> ps -ef | grep 'nginx' | wc -l

Здесь `ps` выводит текст, `grep` фильтрует этот текст, а `wc` считает строки. Каждая утилита ничего не знает о "процессах", она работает только со строками.

PowerShell-конвейер: Поток объектов

Пример: Давайте получим все процессы, отсортируем их по использованию CPU и выберем 5 самых "прожорливых".

> Get-Process | Sort-Object -Property CPU -Descending | Select-Object -First 5

Здесь Get-Process создает объекты процессов. Sort-Object получает эти объекты и сортирует их по свойству CPU. Select-Object получает отсортированные объекты и выбирает первые 5.

Вы наверняка заметили в команде слова, начинающиеся с дефиса (-): -Property, -Descending, -First. Это параметры. Параметры — это настройки, переключатели и инструкции для командлета. Они позволяют управлять тем, КАК команда будет выполнять свою работу. Без параметров команда работает в режиме по умолчанию, а с параметрами вы даете ей конкретные указания.

Основные типы параметров:

• Параметр со значением: требует дополнительной информации.

  -Property CPU: Мы говорим Sort-Object, по какому свойству сортировать. CPU — это значение параметра.

  -First 5: Мы говорим Select-Object, сколько объектов выбрать. 5 — это значение параметра.

• Параметр-переключатель (флаг): Не требует значения. Само его наличие в команде включает или выключает определенное поведение.

  -Descending: Этот флаг говорит Sort-Object изменить порядок сортировки на обратный (от большего к меньшему). Ему не нужно дополнительное значение — он сам по себе инструкция.

> Get-Process -Name 'svchost' | Measure-Object

Эта команда отвечает на очень простой вопрос: "Сколько именно процессов с именем svchost.exe сейчас запущено в моей системе?"

Разбор по шагам

Шаг 1: Get-Process -Name 'svchost'

Эта часть команды обращается к операционной системе и просит найти все без исключения запущенные процессы, у которых имя исполняемого файла — svchost.exe. В отличие от процессов типа notepad (которых обычно один или два), процессов svchost в системе всегда много. Команда вернет массив (коллекцию) объектов, где каждый объект — это отдельный, полноценный процесс svchost со своим уникальным ID, использованием памяти и т.д. PowerShell нашел в системе, например, 90 процессов svchost и теперь держит в руках коллекцию из 90 объектов.

Шаг 2: | (Оператор конвейера)

Этот символ берет коллекцию из 90 объектов svchost, полученную на первом шаге, и начинает передавать их по одному на вход следующей команде.

Шаг 3: Measure-Object

Поскольку мы вызвали Measure-Object без параметров (таких как -Property, -Sum и т.д.), он выполняет свою операцию по умолчанию — просто считает количество "предметов", которые ему передали. Раз, два, три ... После того как все объекты посчитаны, Measure-Object создает свой собственный объект-результат, в котором есть свойство Count, равное итоговому числу.

Count: 90 — это и есть ответ на наш вопрос. Запущено 90 процессов svchost. Остальные поля пустые, потому что мы не просили Measure-Object выполнять более сложные вычисления.

Пример с svchost и параметрами

Давайте изменим нашу задачу. Теперь мы хотим не просто посчитать процессы svchost, а узнать, сколько всего оперативной памяти (в мегабайтах) они потребляют вместе.

Для этого нам понадобятся параметры:

• -Property WorkingSet64: Эта инструкция говорит Measure-Object: "Из каждого объекта svchost, который к тебе придет, возьми числовое значение из свойства WorkingSet64 (это использование памяти в байтах)".

• -Sum: Эта инструкция-флаг говорит: "Сложи все эти значения, которые ты взял из свойства WorkingSet64".

Наша новая команда будет выглядеть так:

> Get-Process -Name 'svchost' | Measure-Object -Property WorkingSet64 -Sum

1. Get-Process найдет количество объектов svchost.

2. Конвейер | передаст их в Measure-Object.

3. Но теперь Measure-Object работает по-новому:

   • Он берет первый объект svchost, смотрит его свойство .WorkingSet64 (например, 25000000 байт) и запоминает это число.

   • Берет второй объект, смотрит его .WorkingSet64 (например, 15000000 байт) и прибавляет к предыдущему.

   • ...и так далее для всех объектов.

4. В итоге Measure-Object создаст объект-результат, но теперь он будет другим.

• Count: 92: Количество объектов.

• Sum: 1661890560: Это общая сумма всех значений WorkingSet64 в байтах.

• Property: WorkingSet64: Это поле теперь тоже заполнено, оно информирует нас, какое именно свойство было использовано для вычислений.

2. Переменные (Обычные и специальная $_)

Переменная — это именованное хранилище в памяти, которое содержит какое-либо значение.

Этим значением может быть что угодно: текст, число, дата или, что самое важное для PowerShell, целый объект или даже коллекция объектов. Имя переменной в PowerShell всегда начинается со знака доллара ($). Примеры: $name, $counter, $processList.

Специальная переменная $_?

$_ — это сокращение для "текущий объект" или "вот эта штука". Представьте себе конвейер на заводе. По нему едут разные детали (объекты).

$_ — это та самая деталь, которая находится прямо сейчас перед вами (или перед роботом-обработчиком).

Источник (Get-Process) — высыпает на конвейер целую коробку с деталями (всеми процессами).

Конвейер (|) — заставляет эти детали двигаться по ленте по одной.

Обработчик (Where-Object или ForEach-Object) — это робот, который смотрит на каждую деталь.

Переменная $_ — это та самая деталь, которая сейчас находится в "руках" у робота.

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

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

1. Выполняем команду и сохраняем ее сложный объект-результат в переменную $svchostMemory

> $svchostMemory = Get-Process -Name svchost | Measure-Object -Property WorkingSet64 -Sum

2. Теперь мы можем работать с сохраненным объектом. Достаем из него свойство Sum

> $memoryInMB = $svchostMemory.Sum / 1MB

3. Выводим результат на экран, используя новую переменную

> Write-Host "Все процессы svchost используют $memoryInMB МБ памяти."

• Write-Host — это специализированный командлет, чья единственная задача — показать текст непосредственно пользователю в консоли.

• Строка в двойных кавычках: "..." - текстовая строка, которую мы передаем командлету Write-Host в качестве аргумента. Почему двойные, а не одинарные кавычки?

  В PowerShell есть два типа кавычек:

  • Одинарные ('...'): Создают буквальную строку. Все, что внутри них, воспринимается как обычный текст, без исключений.

  • Двойные ("..."): Создают расширяемую (или подстановочную) строку. PowerShell "сканирует" такую строку на предмет переменных (начинающихся с $) и подставляет на их место их значения.

• $memoryInMB. Это переменная, в которую мы на предыдущем шаге нашего скрипта положили результат вычислений. Когда Write-Host получает строку в двойных кавычках, происходит процесс, называемый "подстановка переменных" (String Expansion):

  1. PowerShell видит текст "Все процессы svchost используют ".

  2. Затем он натыкается на конструкцию $memoryInMB. Он понимает, что это не просто текст, а переменная.

  3. Он заглядывает в память, находит значение, хранящееся в $memoryInMB (например, 1585.52).

  4. Он подставляет это значение прямо в строку.

  5. Затем он добавляет оставшуюся часть текста: " МБ памяти.".

  6. В итоге, в Write-Host передается уже готовая, собранная строка: "Все процессы svchost используют 1585.52 МБ памяти.".

Запустите блокнот!

1. Находим процесс Блокнота и сохраняем его в переменную $notepadProcess

> $notepadProcess = Get-Process -Name notepad

1. Обращаемся к свойству 'Id' этого объекта через точку и выводим его

> Write-Host "ID процесса 'Блокнот' равен: $($notepadProcess.Id)"

❗ Важно: Write-Host "ломает" конвейер. Текст, выведенный им, нельзя передать дальше по конвейеру для обработки. Он предназначен только для отображения.

3. Get-Member (Инспектор объектов)

Мы знаем, что по конвейеру "текут" объекты. Но как узнать, из чего они состоят? Какие у них есть свойства и какие действия (методы) с ними можно совершать?

командлет Get-Member (псевдоним: gm) главный инструмент для исследования. Прежде чем работать с объектом, пропустите его через Get-Member, чтобы увидеть все его возможности.

Давайте проанализируем объекты, которые создает Get-Process:

> Get-Process | Get-Member

Разберем каждую часть вывода Get-Member.

TypeName: System.Diagnostics.Process - Это полное, официальное "имя типа" объекта из библиотеки .NET. Это его "паспорт". Эта строка говорит вам, что все объекты, которые возвращает Get-Process, являются объектами типа System.Diagnostics.Process. Это гарантирует, что у них у всех будет одинаковый набор свойств и методов. Вы можете загуглить "System.Diagnostics.Process", чтобы найти официальную документацию Microsoft с еще более подробной информацией.

• Колонка 1: Name

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

• Колонка 2: MemberType (Тип объекта)

Это самая важная для понимания колонка. Она классифицирует, чем является каждый объект. Это его "должность", которая говорит вам, КАК его использовать.

• Property (Свойство): характеристика или порция данных, хранящаяся внутри объекта. Вы можете "прочитать" ее значение.

  • Примеры на скриншоте: BasePriority, HandleCount, ExitCode. Это просто данные, которые можно посмотреть.

• Method (Метод): ДЕЙСТВИЕ, которое можно совершить с объектом. Методы всегда вызываются с круглыми скобками ().

  • Примеры на скриншоте: Kill, Refresh, WaitForExit. Вы бы написали $process.Kill() или $process.Refresh().

• AliasProperty (Псевдоним свойства): дружелюбный псевдоним для другого, более длинного свойства. PowerShell добавляет их для удобства и краткости.

  • Примеры на скриншоте: WS — это короткий псевдоним для WorkingSet64. Name — для ProcessName. VM — для VirtualMemorySize64.

• Event (Событие): УВЕДОМЛЕНИЕ о том, что что-то произошло, на которое можно "подписаться".

  • Пример на скриншоте: Exited. Ваш скрипт может "слушать" это событие, чтобы выполнить какое-то действие сразу после того, как процесс завершится.

• CodeProperty и NoteProperty: специальные типы свойств, часто добавляемые самим PowerShell для удобства. CodeProperty вычисляет свое значение "на лету", а NoteProperty — это простое свойство-заметка, добавленное к объекту.

• Колонка 3: Definition (Определение)

Это техническое определение или "подпись" члена. Она дает вам точные детали для его использования. Ее содержимое зависит от MemberType:

• Для AliasProperty: Показывает, чему равен псевдоним. Это невероятно полезно!

  • Пример на скриншоте: WS = WorkingSet64. Вы сразу видите, что WS — это просто короткая запись для WorkingSet64.

• Для Property: Показывает тип данных, который хранится в свойстве (например, int для целого числа, string для текста, datetime для даты и времени), и что можно с ним делать ({get;} — только читать, {get;set;} — читать и изменять).

  • Пример на скриншоте: int BasePriority {get;}. Это целочисленное свойство, которое можно только прочитать.

• Для Method: Показывает, что метод возвращает (например, void — ничего, bool — true/false) и какие параметры (входные данные) он принимает в скобках.

  • Пример на скриншоте: void Kill(). Это значит, что метод Kill ничего не возвращает и может быть вызван без параметров. Также есть вторая версия void Kill(bool entireProcessTree), которая принимает логическое значение (true/false).

В виде таблицы

Пример: Работа с окнами процессов

1. Проблема:

"Я открыл много окон Блокнота. Как мне программно свернуть все, кроме главного, а затем закрыть только то, у которого в заголовке есть слово 'Untitled'?"

Откройте несколько экземпляров блокнота (Windows Notepad) на компьютере

2. Исследование с Get-Member:

Нам нужно найти свойства, связанные с окном и его заголовком.

> Get-Process -Name notepad | Get-Member

Анализ результата Get-Member:

• Листая свойства, мы находим MainWindowTitle. Тип string. Отлично, это заголовок главного окна!

• В методах мы видим CloseMainWindow(). Это более "мягкий" способ закрыть окно, чем Kill().

• Также в методах есть WaitForInputIdle(). Звучит интересно, возможно, это поможет дождаться, пока процесс будет готов к взаимодействию.

Get-Member показал нам свойство MainWindowTitle, которое является ключом к решению задачи и позволяет взаимодействовать с процессами на основе состояния их окон, а не просто по имени.

3. Решение:

Теперь мы можем построить логику, основанную на заголовке окна.

Пример: Найти родительский процесс

1. Проблема:

"Иногда я вижу в системе много дочерних процессов chrome.exe. Как мне узнать, какой из них является главным, "родительским" процессом, который их всех запустил?"

2. Исследование с Get-Member:

Нам нужно найти что-то, что связывает один процесс с другим.

> Get-Process -Name chrome | Select-Object -First 1 | Get-Member

Анализ результата Get-Member:

• Внимательно просматривая список, мы находим свойство типа CodeProperty с именем Parent.

• Его определение (Definition) — System.Diagnostics.Process Parent{get=GetParentProcess;}. Это вычисляемое свойство, которое при обращении к нему возвращает объект родительского процесса.

3. Решение:

Теперь мы можем написать скрипт, который для каждого процесса chrome будет выводить информацию о его родителе.

Мы сразу видим, что процессы с ID 4756, 7936, 8268 и 9752 были запущены процессом с ID 14908. Также можно заметить интересный случай с процессом ID: 7252, у которого родительский процесс не определился (возможно, родитель уже успел завершиться к моменту проверки). Модификация скрипта с проверкой if ($parent) аккуратно обрабатывает этот случай, не вызывая ошибки. Get-Member помог нам обнаружить "скрытое" свойство Parent, которое предоставляет мощные возможности для анализа иерархии процессов.

4. Файл .ps1 (Создание скриптов)

Когда ваша цепочка команд становится полезной, вы захотите сохранить ее для многократного использования. Для этого и нужны скрипты — текстовые файлы с расширением .ps1.

Разрешение на запуск скриптов

По умолчанию в Windows запрещен запуск локальных скриптов. Чтобы это исправить для текущего пользователя, выполните один раз в PowerShell от имени администратора:

> Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

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

Пример скрипта system_monitor.ps1

Создайте файл с таким именем и вставьте в него код ниже. Этот скрипт собирает информацию о системе и генерирует отчеты.

Примечание: функция Export-Results будет определена в следующем разделе как пример хорошей практики.

5. Экспорт результатов

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

Дополнение к скрипту: функция экспорта

Давайте добавим в наш скрипт system_monitor.ps1 функцию, которая будет заниматься экспортом. Поместите этот код перед вызовом Export-Results.

код на github

Теперь наш скрипт не просто собирает данные, но и аккуратно сохраняет их в двух форматах: CSV для анализа и HTML для быстрого просмотра.

Заключение

1. Конвейер (|) — главный инструмент для объединения команд и обработки объектов.

2. Get-Member — анализ объектов, который показывает, из чего они состоят.

3. Переменные ($var, $_) позволяют сохранять данные и обращаться к текущему объекту в конвейере.

4. Файлы .ps1 превращают команды в переиспользуемые инструменты автоматизации.

5. Командлеты экспорта (Export-Csv, ConvertTo-Html) Экспортируют данные в соответствующем формате.

В следующей части мы применим эти знания для навигации и управления файловой системой, исследуя объекты System.IO.DirectoryInfo и System.IO.FileInfo.

К первой части

Полезно? Подпишись.
Понравилось — ставь «+»
Удачи! 🚀

Предупреждение еще раз. Все данные ниже можно принимать во внимание, но не стоит рассматривать как какой-то эталон.

Что получил:

Один тред, один файл, блок 4k на чтение.

1 Влияние длины очереди. Тут была таблица, но не вставилась, поэтому просто цифрами:

После очереди == 4, нагрузка не растет, около 90k IOPS

2 Влияние числа тредов и числа файлов в работе на общий IOPS

Примечание: для 2 и 3 файлов – один файл был размещен на другом логическом диске

Тут тоже была таблица, но мне лень вставлять ее даже картинкой. На картинке опечатка, везде k, тысячи IOPS.

Затем общий IOPS не рос.

До 10 тредов IOPS на поток падало – с 40 тысяч при 1 треде на каждый файл.
При соотношении 2 файла \ 3 треда, всего 6 тредов, и 3 файла \ 2 треда – выйдя на примерно 40k IOPS на поток, при 4 тредах и 3 файлах просев до 33-35 k IOPS на поток

На 14 (7\2) и 15 (5\3) тредах начинает падать IOPS\thread – с 35 до 17.
На 14 – 10 по 35k, 4 по 17k
на 15 – 9 треда по 35k, 3 треда по 17k.
Что отлично укладывается в логику 12 тредов CPU, из которых 9 работают на один тред, генерируя по 35k, и 3 CPU потока обрабатывают по 2 дисковых треда по 17k.
На 24 тредах (2 файла \ 12 тредов и 3 файла \ 8 тредов)  картинка та же – все треды примерно по 17.5 IOPS
На 26 тредах (2\13 и 3\12) -4-6 потоков падают до 10k IOPS \ thread. Суммарно те же 40k

И для записи, пиковое значение было получено при 2 тредах на каждый их 3 файлов, 240k IOPS итого, по 40k IOPS на тред. Затем было только хуже –

Например, на казалось бы ПОЧТИ то же самое, 3 треда на два файла – производительность упала до 20k на тред, 120k IOPS.

На 4 потоках на файл, 12 файлах – производительность вроде бы была 210k, но есть разброс – от 15 до 20k IOPS на тред, перемерять надо.

На этом обзор физики можно и закончить, с выводами:
AMD потоки работают интереснее, чем у Intel, в именно этой реализации.
Максимальная производительность по чтению по дисковым операциям на физическом хосте достигается на числе потоков данных = числу потоков CPU
Производительность на чтение от очереди зависит достаточно слабо, то есть на очереди 8 выжало не 430, а 440k IOPS, на очереди 16 и 32 – 450k IOPS.

Внезапно, наловил ошибок – удалил старые файлы тестов, а новые, с тем же именем, не создаются!
There has been an error during threads execution
Error generating I/O requests
Оказалось, в какой-то момент в середине ночи удалил параметр с размером файлов.  Случайно. И даже не заметил. Поправил и завелось.

И, наконец, влияние read-modify-write для любителей дисков потолще.

Показать не удалось, потому что:
Картина на файле 10 гигабайт и длительности записи 10 секунд и прогреве W=10

Картина приплыли на файле 200 гигабайт при прогреве W=2

До этого прогрев был W=10. И, в таблице ниже, 3.5k это не опечатка, 3500 IOPS

Как бы так сказать, что при таком разбросе данных, это не тестирование, а полная и беспросветная лажа?

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

Перейдем к SQLsim.
Для опытов был взят Microsoft® SQL Server® 2019 Express,
Будете ставить – не забывайте сразу качать SQL Server Management Studio, пригодится.

файл отдельно не качается (я не нашел), поэтому скачал, поставил и вот -
C:\Program Files\Microsoft SQL Server\MSSQLXX.<InstanceName>\MSSQL\Binn

В GUI варианте теста «по умолчанию» ничего сложного – размеры файлов, размещение, число циклов, длина теста. Просто, наглядно.

Одна проблема – по умолчанию на 1 цикл поставлено 600 секунд (10 минут), и 12 циклов – то есть базовый тест – это два часа.

В конце теста генерируется sqliosim.log.xml.

Вторая проблема: тест не выдает в итоге каких-то цифр, типа «вы молодец, давайте дальше» - только таблицу

Display Monitor ********** Final Summary for file sqliosim.ldx ********** CLogicalFile::OutputSummary fileio.cpp

Display Monitor File Attributes: Compression = No, Encryption = No, Sparse = No CLogicalFile::OutputSummary fileio.cpp

Display Monitor Target IO Duration (ms) = 100, Running Average IO Duration (ms) = 0, Number of times IO throttled = NN, IO request blocks = NN CLogicalFile::OutputSummary fileio.cpp

Display Monitor Reads = NN, Scatter Reads = 0, Writes = NN, Gather Writes = 0, Total IO Time (ms) = NN CLogicalFile::OutputSummary fileio.cpp

Display Monitor DRIVE LEVEL: Sector size = 512, Cylinders = NN, Media type = NN, Sectors per track = 63, Tracks per Cylinders = 255 CLogicalFile::OutputSummary fileio.cpp

Display Monitor DRIVE LEVEL: Read cache enabled = Yes, Write cache enabled = Yes CLogicalFile::OutputSummary fileio.cpp

Display Monitor DRIVE LEVEL: Read count = BB, Read time = BB, Write count = BB, Write time = NN, Idle time = NN, Bytes read = NN, Bytes written = NN, Split IO Count = 0, Storage number = NN, Storage manager name = VOLMGR  CLogicalFile::OutputSummary fileio.cpp

Я молодец, ок, а дальше что?

Конечно, если вы молодец (как я), то будете смотреть не только в окно самой программы, а запустите resmon и будете смотреть нагрузку по дискам, очереди, задержки, etc.

Перейду к hammerdb .. но это уже другая история.

В следующих сериях, теперь уже точно!
Опыты на виртуальной машине на 3 ядра.

CPU affinity
Опыты на Debian внутри Hyper-V, опыты с Proxmox nested. Stay tuned!

Литература

Performance benchmark test recommendations for Azure NetApp Files
Azure NetApp Files regular volume performance benchmarks for Linux
Hidden Treasure Part 1: Additional Performance Insights in DISKSPD XML
Hidden Treasure Part 2: Mining Additional Insights

Command line and parameters
Customizing tests
Use an XML file to provide DiskSpd parameters
Use the SQLIOSim utility to simulate SQL Server activity on a disk subsystem

SQL Server I/O Basics, Chapter 2
Use the SQLIOSim utility to simulate SQL Server activity on a disk subsystem on Linux
SQLIOSim Create a realistic I/O load for stress-testing SQL Server 2005

about_Comparison_Operators
about_Assignment_Operators

hammerdb Documentation

PS

И немного powershell.

Часть 1, которую вы уже видели

$pciStats = (Get-WMIObject Win32_Bus -Filter 'DeviceID like "PCI%"').GetRelated('Win32_PnPEntity') |

foreach {

# request connection properties from wmi

[pscustomobject][ordered]@{

Name = $_.Name

ExpressSpecVersion=$_.GetDeviceProperties('DEVPKEY_PciDevice_ExpressSpecVersion').deviceProperties.data

MaxLinkSpeed  =$_.GetDeviceProperties('DEVPKEY_PciDevice_MaxLinkSpeed'  ).deviceProperties.data

MaxLinkWidth  =$_.GetDeviceProperties('DEVPKEY_PciDevice_MaxLinkWidth'  ).deviceProperties.data

CurrentLinkSpeed  =$_.GetDeviceProperties('DEVPKEY_PciDevice_CurrentLinkSpeed'  ).deviceProperties.data

CurrentLinkWidth  =$_.GetDeviceProperties('DEVPKEY_PciDevice_CurrentLinkWidth'  ).deviceProperties.data

} |

# only keep devices with PCI connections

Where MaxLinkSpeed

}

$pciStats | Format-Table -AutoSize

Get-CimInstance -ClassName Win32_Volume | Select-Object DriveLetter, FileSystem, BlockSize| Format-Table -AutoSize

$Path001 = 'C:\DiskSpd\amd64\'

$Sp = $Path001 + "diskspd.exe"

cd $Path001

$Rn = Get-Random -Minimum 1 -Maximum 10

$Version = "070_" + $Rn

$Drives = @("C")

$FilesTemp = "Data4del"

$File001 = "deleteme_01a.dm"

$File002 = "deleteme_02a.dm"

$File003 = "deleteme_03a.dm"

$Out021 = $Drives[0] + ':\' + $FilesTemp + '\' + $File001

$Out022 = $Drives[0] + ':\' + $FilesTemp + '\' + $File002

$Out023 = "D" + ':\' + $FilesTemp + '\' + $File003

# $OutsFilesAA = @("$Out021", "$Out023", "$Out021 $Out022","$Out021 $Out023","$Out021 $Out022 $Out023") - не работает вот так и все.

$OutsFilesAA = @( "$Out022")

$Logs = @()

$Threads = @("-t1","-t2", "-t3", "-t4","-t5","-t6","-t7","-t8","-t9","-t10","-t11","-t12","-t13","-t14","-t15")

# $Threads = @("-t1")

# $Write = ("-w0","-w30", "-w100")

$Write = @("-w100")

#$BlockSize = ("-b4k","-b8k")

$BlockSize = @("-b4k")

# $Outstanding = @("-o2","-o4","-o8","-o16","-o32")

$Outstanding = @("-o2")

$Size = "-c200G"

$Time = "-d10"

foreach ($OutFilesGr in $OutsFilesAA){

foreach ($Drv in $Drives){

foreach ($Bl in $BlockSize) {

foreach ($Wr in $Write) {

foreach ($Outs in $Outstanding){

foreach ($T1 in $Threads){

$TimeNow = get-date -UFormat "-%d-%m-%Y-%R" | ForEach-Object {$_ -replace ":","-"}

Write-Host "TT " $TimeNow

$Out001 = $Drv + ':\' + $FilesTemp + '\' + $File001

$Out002 = $Drv + ':\' + $FilesTemp + '\' + $File002

$Out003 = "D" + ':\' + $FilesTemp + '\' + $File003

$Stat1 = $Drv + ':\' + $FilesTemp + '\' + $Version + $TimeNow + "_" + $T1 + $Drv + $Outs + $T1 +'_1.log'

$Stat2 = $Drv + ':\' + $FilesTemp + '\' + $Version + $TimeNow + "_" + $T1 + $Drv + $Outs + $T1 +'_2.log'

$Stat3 = $Drv + ':\' + $FilesTemp + '\' + $Version + $TimeNow + "_" + $T1 + $Drv + $Outs + $T1 +'_3.log'

$Logs += $Stat1

Write-Host "testing mode " $T1 $Wr $Bl $Outs 'time' $Time # "GR" $OutFilesGr

# &$Sp $T1 $Wr $Bl -W10 $Outs $Time -Suw -D -L $Size $Out021 $Out022 > $Stat1

&$Sp $T1 $Wr $Bl -W10 $Outs $Time -Suw -D -L $Size $Out021 > $Stat1

}}}}}}

И часть 2

$FilesTempDir = "c:\Data4del\"

$StatFiles = "069"

$StatFilesList = Get-ChildItem -Path $FilesTempDir | Where-Object {$_.Name -like ($StatFiles + '*') | Sort-Object -Property CreationTime  }

foreach ($MyFile in $StatFilesList){

$TempData1 = Get-Content $MyFile.FullName  | Where-Object {$_ -like "Command Line*"}

$TempData1

$TempData2 = Get-Content $MyFile.FullName  | Where-Object {$_ -like "total:*"}

$TempData2

}

Конечно, пользоваться ими я не стал. Это в корпоративной среде нужен User State Migration Tool (USMT) или forensit User Profile Wizard

Первым делом обновил Windows, конечно не забыв про
OOBE\BYPASSNRO
Вторым – выполнил скрипт DisableUnnecessaryWindowsServices. Всякие твикеры это тоже хорошо, но начать надо с простых, понятных и воспроизводимых вещей.
Со скриптом есть проблемы.
Без этого не будет звука
"Audiosrv", # Windows Audio
"AudioEndpointBuilder", # Windows Audio Endpoint Builder

Не уверен насчет задач:
"QWAVE", # Quality Windows Audio Video Experience
и без этого этого блютус работает, но не видит мышку.
"bthserv", # Bluetooth Support Service
Device Install Service почему-то устанавливается в manual, и без ручного запуска тоже не давал добавить мышь. Но все остальное вроде ок

Третьим делом выключил гибернацию.
powercfg.exe /hibernate off

Я в свое время с гибарнацией поел с лопаты, когда оперативка просто кончилась, и то, что она ушла на кеширование файла гибернации, было видно только в Sysinternals RAMmap.

И четвертым делом потыкал в Sysinternals  Autoruns

И на выходе получил ошибку отсюда:
Automatic Device Encryption Support  Reasons for failed automatic device encryption: PCR7 binding is not supported, Un-allowed DMA capable bus/device(s) detected

Это не про user space сервис, это про
"ShellHWDetection", # Shell Hardware Detection

Исправил и это тоже, иначе какое шифрование, какое авто монтирование.

Power plan

Оказывается, по умолчанию мне система поставила Balanced power, ну куда это годится. Пришлось покрутить ручки, но про это позже.

Hyper-V for Windows 11

Я много лет использовал VMware Workstation, но есть нюанс. У Windows есть разные режимы работы с виртуализацией, и VMware Workstation, особенно в части дисковых операций, из-за множества прокладок и трансляций, скажу так – не то чтобы не дает скорости, но становится крайне процессоро-зависима. Любой ПУК в хостовой системе, и дисковые операции в Workstation начинают думать. У ESXi такой проблемы, разумеется, нет – это абсолютно другая архитектура. В любом случае Dekiru Neko wa Kyou mo Yuuutsu

Потестирую хоть как-то.

Для процессора и памяти, конечно, берем
Free Mersenne Prime Search Software - Great Internet Mersenne Prime Search, GIMPS

Для диска берем DiskSPD последней версии, DISKSPD 2.2 – брать тут.

Конечно надо было померять скорость ДО включения Hyper-v, поскольку, если вы не знали, Hyper-V работает как нормальный гипервизор, подгружая Windows уже в виде виртуальной машины, что может быть и влияет на производительность. А может, и нет. То есть, конечно, да, но не совсем.

Что там на NTFS?
Get-CimInstance -ClassName Win32_Volume | Select-Object DriveLetter, FileSystem, BlockSize| Format-Table -AutoSize

ATTO Disk Benchmark (качать тут, статья с примером тут) показывает совсем не то, что хотелось бы. Потому что он работает в один поток, и только глубина очереди как-то регулируется.  

На DiskSPD, конечно, словил ошибку:

Попутно словил ошибку -
WARNING: Could not set privileges for setting valid file size; will use a slower method of preparing the file

И решение:
OK, so that's exactly what's happening. There is certainly (always) a longer description to attach to it (see above), but DISKSPD when run w/o privilege to assert SeManageVolumePrivilege cannot invoke SetFileValidData and therefore has to write the entire file through to get it into its standard if-created-by-DISKSPD state: with valid data at the end of the file.

Решение очевидное, от админа надо запускать.

Новый диск на новом ноутбуке выдает: (Файловая система – NTFS с блоком 4k, очередь по умолчанию – 2). Файлы по 200 Гб, не похоже на тестирование кеша.
Тестирование - 60 секунд.
1 тред, 1 файл – 35.000 IOPS блоком 4к на чтение, 15.000 IOPS блоком 8к на чтение
1 тред, 1 файл – 40k IOPS блоком 4к на запись (как так вышло – не знаю), 45k IOPS блоком 8к на запись. Это как?
2 треда, 1 файл – 25.000 на поток, итого 50.000 IOPS блоком 4к на чтение, и 2 по 30.000 на запись блоком 4к
3 треда – 23.000, всего 70 на чтение, и на запись 25, 25, и 35 тысяч, итого 85k. Блоком 8к показатели аналогичны
4 треда – 4 по 22.500,  всего 90к на чтение. И 4 по 23 к на запись, итого 92к.
5 тредов – 20.000 на тред, всего 100к на чтение.  Аналогично при блоке на 8k, те же 20.000 IOPS на тред на чтение,
На запись – примерно 10.000 IOPS блоком 4к на тред при первом тесте, до того как я покрутил настройки баланса.

Как бы так сказать «я ничего не понял», не говоря, что ничего не понял?
Проблема тестирования дисков наглядно показывает рост времени исполнения.

Что удивительно, но тестирования изнутри виртуальной машины (Windows server 2025, STD, обновления от 07-2025) показывают цифры, схожие с работой из управляющей операционной системы. Как бы так еще понять, в какой Windows 11 добавили новый NVME обработчик – в 11h22, h23 или h24.

Пропущу длинное русское поле экспериментов, итого:
Для физики:
Размер файла имеет значение. Windows пытается максимально закешировать что можно, и в итоге, если у вас 64 Гб оперативки, а тестовые файлы по 20-40 гигабайт, то цифры будут странные.
Надо брать для тестов файлы в 3-5 раз больше размера оперативки, 200 Гб на файл, два файла, на 64 Гб памяти – уже сойдет.
Количество реальных ядер и CCX имеет значение, причем для дисковых операций на хосте «потоки» AMD работают куда лучше «потоков» Intel. И, особенно, на последних мобильных интелах без HT и с энерго сберегающими ядрами.
На этом ноутбуке 6 ядер, 12 потоков – так вот, до 12 потоков включительно нагрузка растет линейно.
Конкретно этот NVME обрабатывает :
На чтение, 8 тредов: 4 треда по 40k, 4 по 20. 10 тредов – 10 по 35k, всего 350. 12 тредов – 12 по 35, всего 400k. 14 тредов – 10 по 30k, 4 по 15. 16 тредов – 8 по 28, 8 по 12. 18 тредов – 6 по 25, 12 по 10. Максимум достигается при числе тредов DISKspd = числу тредов в CPU.
И это около 400k IOPS. На чтение. Блоком 4к. При глубине очереди 2.

На запись картина другая. Есть подозрение на гигагерце зависимость по ядрам, авторазгон я не выключил.

Максимум получен для 8 тредов – 8x32k, около 256k IOPS на запись блоком 4k.
При 10 тредах получается по 19k на запись, всего 190к. Но расхождения по тредам нет. 12 тредов – падение до 12k IOPS на запись на тред, всего 145k, но все еще нет расхождения.
14 тредов – 10 тредов по 12 к и 4 треда по 7к. Всего 155k. 16 тредов – 8 тредов по 10к и 8 тредов по 5.5k - всего 125. 18 тредов – 6 по 10к, 12 по 6.5

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

Изнутри виртуальной среды картина чуть другая

Тестовая виртуальная машина, 4 ядра, 8 Гб памяти, и, для начала, просто 2 файла по 20, не по 200, Гб.

Чтение, 2 треда: 24k IOPS на тред, всего 48k
Запись, 2 треда: 12k IOPS на тред при 2 тредах, всего 24k

Падение на чтение в 1.5 раза, падение на запись в 3 раза. Но, это тестирования НОУТБУКА, с домашним NVME SSD, и Windows 11. На Windows Server картина может быть абсолютно другой.
Чтение, 4 треда: 3 треда по 15K IOPS, 1 тред на 2k IOPS. Суммарно 47k
Запись, 4 треда – 3 по 8k, 1 на 5k, итого 30 (данные округлены)

Дальше начинается колдовство и магия. Файлы по 200 Гб, 2 файла.
чтение, 4 треда на файл, всего 8 тредов: 6 тредов дают по 16к, 2 треда по 2к. Итого 100k IOPS изнутри виртуалки на 4 процессора.
Чтение, 5 тредов на файл, всего 10 трелов. 7 тредов по 15к, 2 по 1к. Итого 110к
Чтение, 6/12. 9 по 18к, 3 по 2.5. Итого 170к. Идет, к слову так, блоками по 3 группы «больших» IOPS.
Чтение, 7/14. 10 по 14к, 4 по 1к. Итого 150к.
Чтение, 8/16. 12 по 20k IOPS, 4 по 2. Итого 260K IOPS на чтение изнутри VM на 4 ядра.
Чтение, 9/18. 13 по 18..22, 5 по 1.5. Итого 280k.
Чтение, 10/20. 15 по 21, 5 по 2. Итого 330k.
Чтение,11/22. 343k IOPS
Чтение, 12/24. 18 тредов по 22k IOPS, 6 тредов по 2к. Итого почти 400k IOPS на чтение. 
То есть, 4 процессорная виртуальная машина на 24 треда выдала почти столько же IOPS, сколько физика при 12 тредах.
Для физики параметры были: -t6 -w0 -b4k -W10 -o2, и два файла по 200 Гб, то есть 12 тредов итого.

Файлы по 200 Гб, 1 файл. Чтение внутри виртуальной машины.

1 тред – 31k IOPS , 2 треда = 2x24 = 48, 3 треда 2x25+ 1x12 = 62(k IOPS), 4 треда – 3 по 16 и 1 тред на 2, итого 50.
5 тредов = 3 по 16 и 2 по 1.5, 6 тредов – 4 по 15 и 2 по 1.5, всего 62. ,7 тредов -  5 по 14.5 и 2 по 1.8. 8 тредов – 6 по 13 и 2 по 2.5, итого 83k
9 тредов – 6 по 12, 3 по 1.2 , итого 75. 10 – 85k IOPS, 11 – 92k IOPS, 12 – 102k IOPS
Логика какая-то странная.

Дописал текст, и увидел внутри виртуальной машины active power scheme: Balanced
Похоже, надо дополнительно смотреть на параметр:
ag  Group affinity – affinitize threads in a round-robin manner across Processor Groups, starting at group 0. This is default. Use -n to disable affinity.

Или выделять не по 4 ядра на виртуальную машину, при физических 6, которые может еще надо как-то делить, а по 3. Или по 6.
Я в курсе про CCXs (Core Complex), но как-то странно это все.

Дожил, неужели NUMA имеет значение. Но не в 10 же раз разницы из-за Numa (CCX/CCD). И самое главное, не понятно, как изнутри 4 процессорной VM – дисковые задачи раскладываются на физические ядра и процессорные треды / потоки. Как 24 треда разложились на 18 быстрых и 6 медленных. И как из этой конструкции получить например 12 средних. Как вообще CPU scheduler что-то куда-то кладет в такой конфигурации. И не отпилить ли root.

Еще оказалось очень полезно посмотреть на итоговый размер файлов виртуальных машин. Поскольку тесты шли по 30-60 секунд, то максимально за это время записалось всего по 1.5 – 2 гигабайта. Но я еще посмотрю более детально.

Литература

скрипт DisableUnnecessaryWindowsServices
Windows Server 2025 Storage Performance with Diskspd
Sample command lines
Command line and parameters
Execution time longer than the parameter execution time on WSL Ubuntu #203

В следующих сериях:
Опыты на виртуальной машине на 3 ядра.

CPU affinity
Опыты на Debian внутри Hyper-V, опыты с Proxmox nested. Stay tuned!

Бонус

# 01

$pciStats = (Get-WMIObject Win32_Bus -Filter 'DeviceID like "PCI%"').GetRelated('Win32_PnPEntity') |

foreach {

# request connection properties from wmi

[pscustomobject][ordered]@{

Name = $_.Name

ExpressSpecVersion=$_.GetDeviceProperties('DEVPKEY_PciDevice_ExpressSpecVersion').deviceProperties.data

MaxLinkSpeed =$_.GetDeviceProperties('DEVPKEY_PciDevice_MaxLinkSpeed' ).deviceProperties.data

MaxLinkWidth =$_.GetDeviceProperties('DEVPKEY_PciDevice_MaxLinkWidth' ).deviceProperties.data

CurrentLinkSpeed =$_.GetDeviceProperties('DEVPKEY_PciDevice_CurrentLinkSpeed' ).deviceProperties.data

CurrentLinkWidth =$_.GetDeviceProperties('DEVPKEY_PciDevice_CurrentLinkWidth' ).deviceProperties.data

} |

# only keep devices with PCI connections

Where MaxLinkSpeed

}

$pciStats | Format-Table -AutoSize

Get-CimInstance -ClassName Win32_Volume | Select-Object DriveLetter, FileSystem, BlockSize| Format-Table -AutoSize

$Path001 = 'C:\DiskSpd\amd64\'

$Sp = $Path001 + "diskspd.exe"

cd $Path001

$Version = "007g1"

$Drives = @("C")

$FilesTemp = "Data4del"

$File001 = "deleteme_01.dm"

$File002 = "deleteme_02.dm"

$File003 = "deleteme_03.dm"

$Logs = @()

# $Threads = @("-t1","-t2", "-t3", "-t4","-t5","-t6","-t7")

$Threads = @("-t4","-t5","-t6","-t7","-t8","-t9")

# $Write = ("-w0","-w30", "-w100")

$Write = @("-w0")

#$BlockSize = ("-b4k","-b8k")

$BlockSize = @("-b4k")

# $Outstanding = @("-o2","-o4","-o8","-o16")

$Outstanding = @("-o2")

$Size = "-c200G"

$Time = "-d30"

foreach ($Drv in $Drives){

foreach ($Bl in $BlockSize) {

foreach ($Wr in $Write) {

foreach ($Outs in $Outstanding){

foreach ($T1 in $Threads){

$TimeNow = get-date -UFormat "-%d-%m-%Y-%R" | ForEach-Object {$_ -replace ":","-"}

Write-Host "TT " $TimeNow

$Out001 = $Drv + ':\' + $FilesTemp + '\' + $File001

$Out002 = $Drv + ':\' + $FilesTemp + '\' + $File002

$Out003 = $Drv + ':\' + $FilesTemp + '\' + $File003

$Stat = $Drv + ':\' + $FilesTemp + '\' + $Version + $TimeNow + "_" + $T1 + $Drv + $Outs+$T1+'.log'

$Logs += $Stat

Write-Host "testing mode " $T1 $Wr $Bl $Outs 'time' $Time

&$Sp $T1 $Wr $Bl -W10 $Outs $Time -Suw -D -L $Size $Out001 $Out002 > $Stat

}}}}}