Pull to refresh
21
0
Сергей Качкин @kachini

User

Send message

PTS тоже не идеальна. Например, в части последовательно доступа , тест только с TC1/QD32 - какой вывод из этого можно сделать? Кмк, это взяли с HDD, и перенесли на SSD. Часть тестов XSR, CBW ,.. - выглядят несколько хммм.. академично.

SPDK пишут отличные full disclosure report, но у них просто коробка с дисками, подключённая по NVMe, это всё таки не СХД и проверяют они софтовый стек.

да, посмотрел все части и трогал HCIbench тоже. ) Я встречался с результатами HCIbench от заказчиков и было много спорного и непонятного (для меня). Насколько адекватно выбрана смешанная нагрузка - вопрос. Как понять, насколько она правильно выбрана? Верить разработчикам HCIbench на cлово? Например, в некоторых тестах 90% рандом, а почему именно 90%? Зачем нужны 10% seq и почему 10, а не 5 и не 20%. Где-то должно быть обоснование, но я не встречал.

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

Оо.. интересный материал, спасибо. Но не могу отделаться от настороженного отношения к HCIbench. Однокомпонентные нагрузки как-то понятнее, без Random/Sequential Ratio, например. Но когда виртуалки и облака, видимо всё равно к этому приду.

хм, вы правы, действительно сложно отделить одно от другого. Может быть, разница в осознанности действий. В одном случае её больше, чем в другом.

Подскажите пожалуйста про SPEC CPU, это же цифры для base и peak запусков?

То есть peak оптимизация дала +20%? Примерно цифры Итаниума 2009 года, если я правильно понимаю.

в Итаниуме был spill/fill регистров в память, автоматическое переименование регистров. Это разве есть в Эльбрусе?

Итаниум изначально был совсем не айс. Полсоны по производительности были OK, но было уже поздно.

спасибо за вопрос, для NVMe в Linux не используется IO scheduler. Диски сами по себе быстрые, им не нужна оптимизация на стороне хоста. Более того, она оказывается вредна, так как делает IO нагрузку затратной для процессора. Все решает время отклика от диска, ~120 IOPS для механики и > 800,000 IOPS для NVMe. NVMe стек в Linux максимально облегчен. По тестам быстрее всего был Micron.
в AMT, честно говоря, подробно не вникал, и могу ошибаться. Например, в связи с его десктопным назначением там нет интерфейсов наружу, которые бывают в разных BMC, т.е. IPMI(RMCP), SMASH, REST, RedFISH, доступ по SSH. Зато есть фичи для десктопов типа «Anti-Theft», «System Defense Heuristics». В общем, в технологиях есть общее, но задачи решают разные и по аппаратному исполнению разные.
AMT предназначен для PC/ноутбуков, в то время как BMC/IPMI для серверов. Так что имхо нельзя сравнивать, хотя функциональность пересекается.
похоже на vxvm split brain… Но группу инитить стемно конечно
вообще, на Intel Itanium идея очень похожа, ну прямо очень. Там тоже думали всю работу по распараллеливанию переложить на компилятор.
256 сдвигаемых регистров, итд.
ok, я тож про бэкапы подумал.
Но скорость ввода-вывода редко меряют в MB/s.
Обычно, это все-таки iops и время отклика.
— при _первой_ записи на ThP том вполне ожидаема просадка производительности. Что с повторной записью? Она быстрее? (должна-быть по идее)
Имхо на ThP нет смысла мерять скорость первой записи, тк это ожидаемо медленнее.
— вы исплользуете размер блока 1MB, с последовательной записью/чтением. Какую нагрузку вы эмулируете данным способом?
Бэкап и восстановление?

Например, если вы хотите эмулировать базу данных, то надо делать тест c random и блок 8KB, если web, то что-то еще.

ps. производительность измеренная «dd», частый кошмар служб поддержки.
C этим на linux проблема. Я работаю с HP-UX, там есть такая профилировка. По окончании каждого тайм слайса генерится per cpu эвент и в ring buffer скидывается чем занимался процессор (PID, функция ядра, стек !). Очень полезная функция для изучения чем занимаются процессоры. На Linux, насколько знаю, код в ядре для реализации есть, но с утилитами дефицит.
Подождите, откуда TCP в SAN? Вы кажется путаете SAN (Fibre channel) c чем-то еще.

Спасибо, за предложение, но у меня есть собственный опыт на эту тему. Обычный proliant с двумя 4GB карточками запросто генерит 60,000 IOPS, и это далеко не предел, так как мы уперлись на стороне массива.

По поводу вашего теста, надо смотреть детали. Я не уверен какой массив вы тестировали, но видимо какой-то большой.
То есть чтобы давать 36k IOPS при ~120 IOPS/диск вам нужно ~ 300 физических дисков.
сложно сказать, так как service time (latency) не указан… Вообще, 522 IOPS очень странная цифра… для одного диска многовато. Это raid ил 2-3 дисков? Либо много кеш хитов
Автор вроде все расписал, а чего-то не хватает. А именно:
— ничего не сказано про такой параметр как утилизация дисков. В случае если мы говорим об отдельном диске — это легко меряется. Например вот тут, слайды 12-15
www.ruoug.org/events/20091111/perf_IO_presentation.pdf
— про SAN/ NAS ни разу не надо тестить с нескольких серверов. Один сервер запросто генерит такую нагрузку чтобы напрочь убить любую дисковую подсистему. Характер нагрузки при этом легко настраивается увеличением числа параллельных потоков.
«Вот эти пять шкафов — это самое большое дисковое хранилище (непонятно только — самое большое где?):»

Это XP24k в максимальной конфигурации (5 шкафов). имхо в России больше ни у кого ничего подобного нет (максимум 1-2 шкафа).
ксен -да, но там же вроде XenLinux какой-то специфический? Или я ошибаюсь?
На него можно поставить RedHat?

gdb пойдет для анализа core свалившегося процесса, но crash dump операционки им анализировать — нереально. допустим надо вам загрузить все vnode в буфер, оставить только те которые относятся к определенной файловой системе и вывести определенные поля. C gdb мне кажется это проблемно будет сделать
Поддерживаю, хочется более развернутого пояснения
1

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity