Комментарии 19
и что? какие выводы вы предлагаете сделать читателям вашей статьи?
Это все-таки раздел «Разработка», идет процесс, после которого будут и выводы. Но уже сегодня с помощью NIOBench можно
- сравнивать производительность дисковой подсистемы под Windows и Linux;
- сравнивать бенчмарки, полученные другими тестами (например, с AS SSD).
Вы проделали работу, из которой непонятно что следует. Зачем мне об этом знать? Зачем об этом знать другим читателям хабра? Что ваша работа им дает?
сравнивать производительность дисковой подсистемы под Windows и Linux;
С использованием каких из доброго десятка низкоуровневых api для io? Или как повезёт и сравниваете удавов с попугаями?
Для Windows и Linux используются одни и те же методы пакета java.nio, создание прямых буферов методом java.nio.ByteBuffer.allocateDirect(); обеспечивает минимизацию транзитных операций. Это тот случай, когда кроссплатформенность действует.
Да, тест интегральный и зависит не только от ОС, но и JVM.
Да, тест интегральный и зависит не только от ОС, но и JVM.
На это я и намекал. Какой метод io используется на конкретной версии jre — неизвестно, и измеряете вы, с большой вероятностью, неизвестно что, имеющее слабое отношение к реальной производительности io подсистемы.
Думаю, стоит скастовать amarao, может он что-нибудь расскажет хорошего ,)
А? Что? Какое java.nio.ByteBuffer.allocateDirect()? Оно libaio использует или просто O_DIRECT вешает на io? Даже при O_DIRECT запрос всё равно попадает в очередь устройства, дальше работает планировщик очереди — noop/deadline/cfq. Дальше там лимит на глубину команд в scsi стеке, количество свободных портов на enclosure, очередь устройства, плюс, разумеется, настройки кеширования устройства. Это если рейды не учитывать по дороге.
Сравнивать напрямую производительность блочных стеков linux/windows трудно, так как флаги и настройки решают очень много. Правильный вариант — iometer vs fio, а что тут java забыла… эм…
Сравнивать напрямую производительность блочных стеков linux/windows трудно, так как флаги и настройки решают очень много. Правильный вариант — iometer vs fio, а что тут java забыла… эм…
Какое java.nio.ByteBuffer.allocateDirect()? Оно libaio использует или просто O_DIRECT вешает на io?
А это неведомо, т. к. в каждой JRE может быть своя реализация. ByteBuffer.allocateDirect выделяет память вне кучи и используется в nio для того, чтобы можно было избежать дополнительного копирования буферов между кучей и реальными буферами.
На моей машине openjdk8 на linux при использовании java.nio.channels.SeekableByteChannel использует обычные open/read/lseek.
Вместо того чтобы конкретно сказать, что прямой буфер не улучшит ситуацию при взаимодействии с диском, разговор уходит в сторону.
В действительности, в дисковой операции есть два участника: диск и память. Прямой буфер не улучшит ситуацию с диском, но улучшит ситуацию с памятью, насколько это в данном случае можно разделять. Потому что java.nio.ByteBuffer.allocateDirect(), как метод создания буфера, минимизирует транзитные операции копирования данных между буферами JVM и нативными буферами ОС API. В идеале, при использовании этого метода, буфер, с которым работает Java-код, прямо соответствует буферу, с которым работает ОС API файловых операций. В системе команд x86 CPU тоже есть аналогичные, но «необязательные намеки», например, SSE prefetch hints для опережающей загрузки данных
В этом контексте опции файловых API (например, O_DIRECT) – это совсем другая тема, впрочем, также зависящая от реализации JVM. Но пользуясь всем набором опций нативных API по своему усмотрению, мы рискуем создать синтетические нетиповые сценарии.
Зависимость от JVM – нормальный и ожидаемый факт. Акцентируя внимания на особенностях той или иной реализации, мы упускаем из виду, что именно для оценки эффективности этих реализаций и разрабатывался NIOBench, как в общем-то и всякий другой тест.
JVM и NIO – это апробированные и респектабельные решения. Может, снимать метрики стоит с помощью тех профилей, которые они выбрали по умолчанию, а затем уже добавлять свои варианты, вплоть до NUMA-зависимого выделения памяти и прямой работы с регистрами AHCI/NVMe/SCSI?
> а что тут java забыла…
То же, что и здесь.
В действительности, в дисковой операции есть два участника: диск и память. Прямой буфер не улучшит ситуацию с диском, но улучшит ситуацию с памятью, насколько это в данном случае можно разделять. Потому что java.nio.ByteBuffer.allocateDirect(), как метод создания буфера, минимизирует транзитные операции копирования данных между буферами JVM и нативными буферами ОС API. В идеале, при использовании этого метода, буфер, с которым работает Java-код, прямо соответствует буферу, с которым работает ОС API файловых операций. В системе команд x86 CPU тоже есть аналогичные, но «необязательные намеки», например, SSE prefetch hints для опережающей загрузки данных
В этом контексте опции файловых API (например, O_DIRECT) – это совсем другая тема, впрочем, также зависящая от реализации JVM. Но пользуясь всем набором опций нативных API по своему усмотрению, мы рискуем создать синтетические нетиповые сценарии.
Зависимость от JVM – нормальный и ожидаемый факт. Акцентируя внимания на особенностях той или иной реализации, мы упускаем из виду, что именно для оценки эффективности этих реализаций и разрабатывался NIOBench, как в общем-то и всякий другой тест.
JVM и NIO – это апробированные и респектабельные решения. Может, снимать метрики стоит с помощью тех профилей, которые они выбрали по умолчанию, а затем уже добавлять свои варианты, вплоть до NUMA-зависимого выделения памяти и прямой работы с регистрами AHCI/NVMe/SCSI?
> а что тут java забыла…
То же, что и здесь.
То же, что и здесь.
Спасибо, рассмешили. Это обёртка над обычным sendfile(2).
Ожидаемо, что JVM (и как следствие NIO) использует ОС API, а не собственный драйвер или другие экзотические методы. Это тривиально, а не смешно.
Если бы это был низкоуровневый тест, работающий с регистрами контроллера в обход ОС и без участия ОС, тогда бы точно не получилось сравнения Windows и Linux.
Если бы это был низкоуровневый тест, работающий с регистрами контроллера в обход ОС и без участия ОС, тогда бы точно не получилось сравнения Windows и Linux.
Ещё раз, этих api в рамках ОС выше крыши. Даже в рамках одной платформы. Не поленитесь заглянуть в man fio(1).
Задача, озвученная вами
… NIOBench, с помощью которого можно получить бенчмарки магнитных и твердотельных носителей с различными интерфейсами
не выполняется. Это не бенчмарки накопителей или io подсистемы ОС. Пока ваш NIOBench выглядит как попугаемерка.
И зачем, если есть fio? Там вполне есть:
fio job params
zero_buffers
Initialize buffers with all zeros. Default: fill buffers with random data.
refill_buffers
If this option is given, fio will refill the IO buffers on every submit. The default is to only fill it at init time and reuse that data. Only makes sense if zero_buffers isn't specified, naturally. If data verification is enabled, refill_buffers is also automatically enabled.
scramble_buffers=bool
If refill_buffers is too costly and the target is using data deduplication, then setting this option will slightly modify the IO buffer contents to defeat normal de-dupe attempts. This is not enough to defeat more clever block compression attempts, but it will stop naive dedupe of blocks. Default: true.
buffer_compress_percentage=int
If this is set, then fio will attempt to provide IO buffer content (on WRITEs) that compress to the specified level. Fio does this by providing a mix of random data and a fixed pattern. The fixed pattern is either zeroes, or the pattern specified by buffer_pattern. If the pattern option is used, it might skew the compression ratio slightly. Note that this is per block size unit, for file/disk wide compression level that matches this setting. Note that this is per block size unit, for file/disk wide compression level that matches this setting, you'll also want to set refill_buffers.
buffer_compress_chunk=int
See buffer_compress_percentage. This setting allows fio to manage how big the ranges of random data and zeroed data is. Without this set, fio will provide buffer_compress_percentage of blocksize random data, followed by the remaining zeroed. With this set to some chunk size smaller than the block size, fio can alternate random and zeroed data throughout the IO buffer.
buffer_pattern=str
If set, fio will fill the IO buffers with this pattern. If not set, the contents of IO buffers is defined by the other options related to buffer contents. The setting can be any pattern of bytes, and can be prefixed with 0x for hex values. It may also be a string, where the string must then be wrapped with "".
Хороший вопрос! Подскажите, пожалуйста, fio поддерживает аппаратные источники энтропии?
Если правильно помню, там были только prng, но достаточно хорошие. А зачем вам там hardware rng? Это тут же убивает возможность воспроизводимого теста (fio поддерживает явное указание seed'а для этого.
Hardware RNG (в частности процессорная инструкция RDRAND) дает достаточно высокое качество случайных чисел. А если это на некоторых накопителях приведет к нарушению воспроизводимости, то выявление такого факта тоже неплохой результат. Хотя не думаю, что упаковщик в SSD диске настолько интеллектуальный, ведь он должен успевать отрабатывать в темпе чтения и записи данных, у него нет времени на детальный анализ этих данных. Что и проверим с помощью RDRAND.
Программный генератор псевдо-случайных чисел также поддерживается, режим всегда можно выбрать в соответствии с задачей.
Программный генератор псевдо-случайных чисел также поддерживается, режим всегда можно выбрать в соответствии с задачей.
Hardware RNG (в частности процессорная инструкция RDRAND) дает достаточно высокое качество случайных чисел. ...snip... Хотя не думаю, что упаковщик в SSD диске настолько интеллектуальный, ведь он должен успевать отрабатывать в темпе чтения и записи данных, у него нет времени на детальный анализ этих данных. Что и проверим с помощью RDRAND.
Вы оценивали разницу, которую даёт использование hw rng по сравнению с нормальным prng? Если да, то с какими prng вы сравнивали? И насколько велика эта разница при сравнении с нормальными prng, оправдывает ли использование hw rng?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Java-бенчмарки: случайные паттерны и закономерные результаты