Все версии были. В работе были и server и advanced server и datacenter (с PAE и без, со всеми паками и без) - те же проблемы и на 4 процессорной железке возникали.
Не была w2k стабильной. В 2003 году 200-250 запущенных процессов и всё рушилось, как и в win2k3, в то время как, на той же машине под linux коматоз наступал только после 4k процессов. И сетевая производительность w2k/w2k3 составляла 1/4 от той что была доступна в linux. И bsod мог на ровном месте вылететь. А полным фиаско было появление mydoom и blaster - для меня они похоронили windows в качестве сервера и рабочей станции окончательно.
Там ключевой косяк теста: "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 всё протаскивает через ARC, который большой и постоянно в ОЗУ. Дальше сами считайте вероятность возникновения ошибок в данных прошедших через ОЗУ без ECC и решайте насколько важны ваши данные. У меня дома ZFS на ПК без ECC - пока не заметил искажений данных. Но это не отменяет факта: ОЗУ без ECC - недоразумение.
А, например, нам не хватает. И multi-master кластер в keydb поднимает лапки под реальной нагрузкой, к сожалению. Да и подход - копировать в/из ОЗУ файл дампа при рестартах с большими объёмами - это неприличный даунтайм.
Есть ещё интересные фокусы с zvol, видел как iostat кажет на группе nvme накопителей загрузку около 1%, а на /dev/zd0 (raidz на эти самые nvme накопители, сам volume выставлен FC target'ом на другой хост) - 100% и скорость записи втрое ниже чем на Solaris с HDD (ZStorage). Но насколько актуальны эти фокусы, относительно версии драйвера и ядра linux, не уточню - не я производил сетап хоста и не я эксплуатирую.
Все версии были. В работе были и server и advanced server и datacenter (с PAE и без, со всеми паками и без) - те же проблемы и на 4 процессорной железке возникали.
Не была w2k стабильной. В 2003 году 200-250 запущенных процессов и всё рушилось, как и в win2k3, в то время как, на той же машине под linux коматоз наступал только после 4k процессов. И сетевая производительность w2k/w2k3 составляла 1/4 от той что была доступна в linux. И bsod мог на ровном месте вылететь. А полным фиаско было появление mydoom и blaster - для меня они похоронили windows в качестве сервера и рабочей станции окончательно.
Не спасёт. Например, мне надо что-бы было вот так и за мало денег, и с обращением к одному серверу:
redis не работает быстро, и его однопоточность это беда, а не достоинство.
"Кажется, что C# не для того, чтобы большую часть проекта писать с использованием unsafe и с собственным менеджером памяти."
А ультимативная производительность говорит о том, что подход выбран правильный.
Там ключевой косяк теста: "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 с:
По этому поводу мной был оставлен первый комментарий - 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://habr.com/ru/companies/vk/articles/770300/#comment_26108856
https://habr.com/ru/companies/vk/articles/770300/#comment_26108856
Насчёт производительности, если вот эти проблемы решены:
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.