Про P.S.: Автор мог-бы сказать, что с удовольствием обновит устаревшее приложение, если google профинансирует эту работу, компенсируя затраты времени и других ресурсов на разработку.
"Однако возможно в вашем описании так же имеются не точности. Например, довольно важный факт, вынесенный из статьи: данные из ZIL никогда не читаются. (не перемещаются из ZIL в пул)"
Проявите ещё немного внимательности — я ни разу не утверждал, что из ZIL что-либо перемещается в пул. Такое возможно только в момент импорта пула или при принудительных операциях по откату транзакции.
Зачем репостить, то что и так есть в документации?
И ZIL (по умолчанию, при sync=on) всегда синхронизирует только операции с метаданными, остальное по мере того, как ОС или ПО подёргает fsync и/или на основании настроек своего драйвера. И даже без ZIL ZFS поддерживает согласованное состояние данных -https://blogs.oracle.com/roch/nfs-and-zfs,-a-fine-combination:
"We note that, even without a ZIL, ZFS will always maintain a coherent local view of the on-disk state"
И ZIL не базовая часть ZFS, а вспомогательная для обеспечения надёжности записи и восстановления после сбоев, без ZIL ZFS может использоваться.
Перестаньте поучать.
ARC имеет прямое отношение к записи, вся запись через него идёт. ZIL, собирает в лог все записи и досылает их на диск, прилетит fsync, он выставит для набора записей метку подтвердив транзакцию, вернув ответ в ARC, а уже ARC вернёт ответ fsync. И ZIL может вообще не использоваться для записи, асинхронно всё может лететь на накопитель сразу из ARC, ZIL же только метаданные фиксирует по умолчанию. А вообще надо у ТС спросить, что у него там в zfs get sync.
С какого рожна вообще оператор должен платить за оборудование и хранение данных, которые конкретно ему вообще нафиг не сдались. Этот "закон" нарушает все права, как тех, против кого он направлен, так и права исполнителей.
Субъективно, Вы всё попутали )
Причём тут отмена однопоточности? Речь о производительности.
io — который сейчас очень быстрый или aio — когда у тебя ssd хранилище на 1млн iops, а redis упёрся в потолок производительности одного ядра процессора при загрузке по io <1%.
> ну, норм вариант — ставить на один сервер несколько редисов, не?
Если нагрузки нет, можно хоть по пять redis'ов на ядро процессора.
НО когда есть нагрузка, то хоть у процессора и 128 ядер, а кеш (LLC) один и его когерентность выходит боком, когда redis активно задрачивает кеш в один thread на максимуме
Вы попутали.
nodejs — eventloop для сокетов и нормальным образом создаёт thread per worker.
golang — см. runtime.GOMAXPROCS()
Redis все запросы лопатит в одном thread, т.е. вообще в одном, причём этот один thread является main процессом. Ещё три thread'а, служебные (сброс на диск, лог...). Этот же main и моет CPU-кеш так, что всем остальным процессам в системе просто приходится курить, ну или начать конкурировать роняя производительность этого «супер-пупер-дупер быстрого» Redis в пол вместе с ростом латентности в потолок. Т.е. настроить его под нагрузку толком нельзя, кроме как запустить по redis'у на сервер и воткнуть перед ними какой-нибудь twemproxy, при этом это всё адский оверхед по железу и выглядит всё как костыль на костыле.
Он и сейчас нормально не кластеризуется. И вообще эта недософтина полностью игнорирует архитектуру многоядерных ЦПУ утилизируя только одно ядро и выедая с его помощью кеши так, что рядом ничего толком не может крутиться.
Это прекрасно, что Guix так развился.
Да apt, portage и подобные обросли, но у них нет будущего.
Надеюсь, Guix и Nix вытеснят уже архаичные костыли apt, yum и им подобное.
Ну я думаю, что проблем с чтением температуры CPU в BMC не было, по крайней мере BCM её показывал такой-же, как lm-sensors.
И вращались вентиляторы тоже с приемлемой скоростью (~10k оборотов) для idle или небольшой нагрузки, но под значимой нагрузкой этого был недостаточно.
Так же, я связываю это с тем, что отключил C-States, т. к. постоянно валились сообщения:
[Tue Nov 13 14:35:35 2018] Uhhuh. NMI received for unknown reason 21 on CPU 84.
[Tue Nov 13 14:35:35 2018] Do you have a strange power saving mode enabled?
[Tue Nov 13 14:35:35 2018] Dazed and confused, but trying to continue
Кстати, в этой платформе, каждые две ноды обдуваются парой вентиляторов (80x80x38 mm, 16.5K RPM, Non-hot-swappable):
Redis один или стадо? Если стадо, то в связанном кластере или каждый redis сам по себе?
redis не нужен. Можно применить memcached и получить на одном хосте в 10 раз большую производительность при меньших задержках, не настраивая костылей.
Годно! Однако, есть вот такая штука — https://github.com/netdata/netdata, к которой было-бы логично прикрутить консольный фейс.
Про P.S.: Автор мог-бы сказать, что с удовольствием обновит устаревшее приложение, если google профинансирует эту работу, компенсируя затраты времени и других ресурсов на разработку.
del
Проявите ещё немного внимательности — я ни разу не утверждал, что из ZIL что-либо перемещается в пул. Такое возможно только в момент импорта пула или при принудительных операциях по откату транзакции.
Зачем репостить, то что и так есть в документации?
И ZIL (по умолчанию, при sync=on) всегда синхронизирует только операции с метаданными, остальное по мере того, как ОС или ПО подёргает fsync и/или на основании настроек своего драйвера. И даже без ZIL ZFS поддерживает согласованное состояние данных -https://blogs.oracle.com/roch/nfs-and-zfs,-a-fine-combination:
И ZIL не базовая часть ZFS, а вспомогательная для обеспечения надёжности записи и восстановления после сбоев, без ZIL ZFS может использоваться.
Перестаньте поучать.
ARC имеет прямое отношение к записи, вся запись через него идёт. ZIL, собирает в лог все записи и досылает их на диск, прилетит fsync, он выставит для набора записей метку подтвердив транзакцию, вернув ответ в ARC, а уже ARC вернёт ответ fsync. И ZIL может вообще не использоваться для записи, асинхронно всё может лететь на накопитель сразу из ARC, ZIL же только метаданные фиксирует по умолчанию. А вообще надо у ТС спросить, что у него там в zfs get sync.
Не там где вас, очевидно же.
Сферическое сравнение. На ZFS в FreeBSD fsync при записи вернёт факт записи из ARC. В linux на ext4 fsync будет дожидаться сброса на накопитель.
С какого рожна вообще оператор должен платить за оборудование и хранение данных, которые конкретно ему вообще нафиг не сдались. Этот "закон" нарушает все права, как тех, против кого он направлен, так и права исполнителей.
IBS в своём репертуаре, то диски с СПО криво запишут, то на слайдах написать два слова раздельно и без ошибок не могут:
Да, я опечатался — имеется ввиду "история 2"
Данные патчи зарелизены в ядре 4.19
Причём тут отмена однопоточности? Речь о производительности.
io — который сейчас очень быстрый или aio — когда у тебя ssd хранилище на 1млн iops, а redis упёрся в потолок производительности одного ядра процессора при загрузке по io <1%.
Если нагрузки нет, можно хоть по пять redis'ов на ядро процессора.
НО когда есть нагрузка, то хоть у процессора и 128 ядер, а кеш (LLC) один и его когерентность выходит боком, когда redis активно задрачивает кеш в один thread на максимуме
nodejs — eventloop для сокетов и нормальным образом создаёт thread per worker.
golang — см. runtime.GOMAXPROCS()
Redis все запросы лопатит в одном thread, т.е. вообще в одном, причём этот один thread является main процессом. Ещё три thread'а, служебные (сброс на диск, лог...). Этот же main и моет CPU-кеш так, что всем остальным процессам в системе просто приходится курить, ну или начать конкурировать роняя производительность этого «супер-пупер-дупер быстрого» Redis в пол вместе с ростом латентности в потолок. Т.е. настроить его под нагрузку толком нельзя, кроме как запустить по redis'у на сервер и воткнуть перед ними какой-нибудь twemproxy, при этом это всё адский оверхед по железу и выглядит всё как костыль на костыле.
Да apt, portage и подобные обросли, но у них нет будущего.
Надеюсь, Guix и Nix вытеснят уже архаичные костыли apt, yum и им подобное.
Это /etc/apt/preferences.d/ — приоритеты для реп в apt
Ну я думаю, что проблем с чтением температуры CPU в BMC не было, по крайней мере BCM её показывал такой-же, как lm-sensors.
И вращались вентиляторы тоже с приемлемой скоростью (~10k оборотов) для idle или небольшой нагрузки, но под значимой нагрузкой этого был недостаточно.
Так же, я связываю это с тем, что отключил C-States, т. к. постоянно валились сообщения:
Кстати, в этой платформе, каждые две ноды обдуваются парой вентиляторов (80x80x38 mm, 16.5K RPM, Non-hot-swappable):