Как стать автором
Обновить
18
0

Пользователь

Отправить сообщение

Там ключевой косяк теста: "Issue #1 is that in Kafka’s server.properties file has the line log.flush.interval.messages=1 which forces Kafka to fsync on each message batch... So I removed that from the server.properties file...", автор убрал этот параметр, и весь его тест превратился в фуфло. Т.к. по default log.flush.interval.messages=10000 (было раньше, а сейчас вообще лимита нет по сути), т.е. kafka сбрасывает на накопитель каждые 10000 msg (в старых версиях, в новых версиях применяются default'ы checkpoint интервалов - 1 минута), если так подходить, то логично было-бы для redpanda выставить --unsafe-bypass-fsync и тогда сравнивать. А в своих тестах команда redpanda делает акцент на надёжности - демонстрируя потерю данных в kafka: https://github.com/redpanda-data/kafka-fsync.

Повторите тесты для zfs с:

zfs_vdev_async_write_min_active=1024
zfs_vdev_async_write_max_active=2048
zfs_vdev_async_read_min_active=1024
zfs_vdev_async_read_max_active=2048
zfs_vdev_sync_write_min_active=1024
zfs_vdev_sync_write_max_active=2048
zfs_vdev_sync_read_min_active=1024
zfs_vdev_sync_read_max_active=2048
zfs_vdev_queue_depth_pct=100

По этому поводу мной был оставлен первый комментарий - https://habr.com/ru/companies/vk/articles/770300/comments/#comment_26109430. Рекурсия ;)

Эм... а что не так? Есть smart инфа на одном и есть сбой на другом. Зеркало из nvme на pci и nvme на usb переходнике видимо было сделано для проверки.

Чел интересовался за ZFS. А так это вообще относится ко всем данным находящимся в ОЗУ.

Чем выше радиационный фон, тем выше вероятность инвертирования значений в ячейках памяти. ZFS всё протаскивает через ARC, который большой и постоянно в ОЗУ. Дальше сами считайте вероятность возникновения ошибок в данных прошедших через ОЗУ без ECC и решайте насколько важны ваши данные. У меня дома ZFS на ПК без ECC - пока не заметил искажений данных. Но это не отменяет факта: ОЗУ без ECC - недоразумение.

А, например, нам не хватает. И multi-master кластер в keydb поднимает лапки под реальной нагрузкой, к сожалению. Да и подход - копировать в/из ОЗУ файл дампа при рестартах с большими объёмами - это неприличный даунтайм.

Распространение ОЗУ без ECC и является недоразумением. В ОЗУ должен быть ECC.

Есть ещё интересные фокусы с zvol, видел как iostat кажет на группе nvme накопителей загрузку около 1%, а на /dev/zd0 (raidz на эти самые nvme накопители, сам volume выставлен FC target'ом на другой хост) - 100% и скорость записи втрое ниже чем на Solaris с HDD (ZStorage). Но насколько актуальны эти фокусы, относительно версии драйвера и ядра linux, не уточню - не я производил сетап хоста и не я эксплуатирую.

Насчёт производительности, если вот эти проблемы решены:
https://github.com/openzfs/zfs/issues/14346
https://coda.io/@ff0/zvol-performance-issues
https://github.com/openzfs/zfs/issues/11933
, то гуд, если нет, то ждёмс...

https://github.com/openzfs/zfs/issues/9172 - и эта проблема и похожие - закрыты автоматически за неактивностью, а не по исправлению. Это как сказал один из пользователей github:
it's like sweeping dirt under the carpet (https://github.com/openzfs/zfs/issues/9693#issuecomment-882027592)

Чётка FS, но с ZVOL проблемы (под Linux) и давно...

redis-benchmark посредственно тестирует, проверяйте с помощью memtier, особенно если накинете тредов на keydb.

статья подустарела, в redis появилась многопототочность, по крайней мере для io. И Redis все, есть KeyDB.

Про "плаформонезависимость" - непонял о чём вы, но я имел ввиду, "способность" програм для jvm работать на любой ОС где работает jvm без изменений под конкретнуюю ОС, на практие оно только на десктопах и годится.
Про эффективность, я вам уже привёл пример: ScyllaDB.
Про "есть/нет программисты" - неверно.
Есть бюджет, что-бы:
а) нанять программистов
б) оплатить эффективное решение.
Бюджетом можно распорядиться рационально, а можно разбазарить.
300 разрабов собравшихся вокруг биллинга - разбазаривание бюджета.
40 инстансов субд на java (в облаке-ли, on-premise-ли), там где справятся 3-5 инстансов субд на cpp - разбазаривание бюджета
И вопрос только в том, разберёт "заказчик музыки", что ему впарили "какофонию" или нет. Увы, но часто, выбор эффективного языка, вообще не стоит в начале, пишут не оценивая будущее TCO, в результате имеем кучу легаси с тремя сотнями разрабов плящущими вокруг и доказывающими что "хуяк-хуяк и в продакшин" это time-to-market.

Не "хочешь", а надо или не надо.
Вот "платформонезависимость" - не надо. Своей тонны java кода нет, что-бы пытаться не переписывая получить профит в производительности и эффективности. А начинать писать на java, то что можно эффективнее и оптимальнее реализовать на C/C++ - лишено смысла, кроме как в случае, если вокруг одни java-программисты и ты один со своим cpp.

Да никто не мешает, пусть кому надо тот и делает. Мне не надо.
"малейшее изменение платформы и нужно переписывать JVM" - ну как-бы с ОС именно так. Ведь основная фишка jvm: абстрагировать, вируализировать, эмулировать - ну и логично тогда уже сразу вместо ОС применять jvm.

Информация

В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность