Pull to refresh

Comments 21

Можно только вас поздравить с завершением очередного этапа. Дерзайте дальше, нас остаётся только верить в хорошее продолжение.

Спасибо!

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

МЦСТ насколько я знаю очень даже хочет апстримить свои труды, тк это позитивно скажется на развитии ИТ-сообщества. Но между "хотеть и мочь" стоят обязательства перед могучим министерством, которые нельзя нарушать, во всяком случае пока. Возможно скоро будут подвижки.

На данный момент даже у самых ярых пессимистов уже не повернется язык назвать процессор Эльбрус медленным, все – таки полтора миллиона IOPS – это много.

Используете любую возможность, чтобы похвалить себя в каждом выступлении и/или статье. Ребят, серьёзные люди так не делают. Вы показали цифры, этого вполне достаточно.

Кто вам такое сказал? Пиар это необходимое и обязательное условие роста. Посмотрите на Эппл, Илона "наше все" Маска, даже на НАСА. Хороший, качественный Пиар в информационной эпохе необходим даже больше чем цифры. Это реалии.

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

Тогда бы вы наверное тестировали ваш write-back cache так. Вы не используете параметр offset_increment при seq нагрузке. У вас все потоки пишут\читают одни блоки. Переписывались бы одни сегменты write-back кэша, это дало бы невероятный буст производительности на запись в многопотоке.

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

Чето маловаты у вас результаты случайных нагрузок. 100кIOPS это скорость одного диска нормального. С учетом, что у вас простой RAID, куда подевалось все остальное? RAID10 из 12 дисков это 600кIOPS записи в теории и все 1.2mIOPS чтения.

Есть планы на nvme решения? SATA и SAS все таки отмирают.

Здравствуйте, в теории действительно так, но на практики чуть-чуть по другому :-)


Есть номинальная заводская характеристика диска, допустим 100k IOPS. То есть если в идеальных условиях напрямую пустить в диск нагрузку, то он покажет с одного диска 100к IOPS. Чтобы эти условия создать, нужно исключить влияние файловой системы хостовой ОС, мультипасинга ОС, таргета СХД, защиты RAID СХД, а также псевдофайловой системы СХД, которая делит пулы на чанки. Если всего этого не будет, то с одного диска можно получить 100k IOPS. Но без всех этих прослоек не будет ни избыточности, ни мониторинга, ни отказоустойчивости, ни интеллекта. Будет просто диск в вакууме, который дает 100k IOPS, что никакой полезной функции в себе не несет.


Что касается NVMe, планов очень много, но нужно чуть-чуть подождать, скоро объявим :-)

Я поэтому и написал, в теории. Но все равно выглядит, что в системе где-то ботлнек. Я бы понял, будь у вас SDS какое-то распределенное. Тут же просто коробка с дисками и рейдом и падение скорости чтения в 10 раз от теоретической. Может быть вполне, что причина в низкой глубине очереди. 64 все таки довольно маловато.

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

Интересные цифры. Спасибо, что поделились. Приятно наблюдать явный прогресс и движение вперëд.

Отмечаем, что для Эльбруса в отличии от других процессоров работа в режиме постоянной загрузки близкой к 100% является штатной ситуацией (он для этого создавался).

гхм…
интересно, автор текста правда верит в эту чушь?

Звучит и правда глупо. Ладно они там железку рассчитывали, что она не деградирует может от подобного, но близкая к 100% загрузке это просто в плане корректной работы софта некорректно. Для СХД это означает банально, что конфигурация несбалансированна.

Если смотреть на процессоры x86, то да, работать на них при утилизации выше 90% действительно глупость, т.к. они для этого не предназначены.


Но если смотреть например на RISC (самый известный это Power), то для таких процессоров — это норма. Можно конечно спорить, но e2k ближе как раз ко 2-ому, ну и наша практика с МЦСТ подтверждает эту "чушь"

Сам процессор ладно, железо действительно для разных условий работы предназначено. Но в плане софта ничего не меняется. Это просто хорошая практика оставлять запас, чтобы иметь возможность переварить случайные всплески нагрузки. Если же 100% уже и так занято клиентами, то любой чих просадит скорость их работы. И это в лучшем случае.

100% процентов — это конечно перебор, обычно 90%-95% на Паверах и СПАРКах я наблюдал либо в производстве, либо в биллинге (где нагрузка хоть и большая, но предсказуемая).

Если смотреть на процессоры x86, то да, работать на них при утилизации выше 90% действительно глупость, т.к. они для этого не предназначены.

Дайте, пожалуйста, ссылку на документацию от intel или amd, в которой указано что-то вроде «рекомендуется нагружать не более, чем на X% не более, чем Y часов в сутки.

Sign up to leave a comment.