@VBart Уже ответил. Уверен что если для Вас действительно важны все эти вопросы, то парни из Angie с удовольствием продадут вам платную поддержку. Как я понимаю, весь смысл Angie в том, чтобы можно было покупать платную поддержку "nginx" в России. Плюс появление тех фич, которые F5 не хотят делать по причине конкуренции с их платными фичами. Соответственно те, кто платит за Angie, опосредованно платят за разработку открытой версии. Можете присоединиться =)
У нас на TOSHIBA HDWL120 собран с помощью mdadm 6-й рейд из 8 дисков.
Device Model: TOSHIBA HDWL120
Serial Number: 6988PJ5AT
LU WWN Device Id: 5 000039 952503b28
Firmware Version: JT000A
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Form Factor: 2.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sun May 3 17:18:02 2020 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Таких серверов два.
Используются под clickhouse.
За пол года эксплуатации диски несколько раз произвольно вылетали из рейда.
При этом вылетевший диск нормально проходит тесты в лабе.
При добавлении диска обратно в массив продолжает работать без ошибок.
Похоже что и обычные рейды нельзя собирать на этих дисках.
В случае с hls, мы делаем чанки по 2 секунды и плейлист из 10 чанков.
Получается средняя задержка около 4-х секунд. Максимальная задержка может доходить до 20 секунд из-за необходимости обработать rtmp, играть с ключевых кадров и т.п.
В случае lhls, мы делаем чанки (frames) по 0,1 секунды. Средняя задержка около 1-й секунды. Максимальная задержка может доходить до 6 секунд по вышеуказанным причинам.
Как мне кажется лучше всего использовать websocket и fmp4/lhls.
Как раз будет обеспечена минимальная задержка и контролируемое соединение.
У нас это отлично работает в большинстве браузеров.
Kurento — не стабильная, не развивающаяся (https://www.kurento.org/blog/kurento-67-moving-forward) платформа, склонная к зависаниям на ровном месте при низких (от 100 пользователей) нагрузках.
Чего стоит баг (https://github.com/Kurento/bugtracker/issues/247), который правили больше года и так до сих пор и не исправили.
А что в данном случае подразумевается под «процессором»?
Илья пишет что используется GP107GL Quadro P400.
Имеется ввиду её процессор или обычный процессор?
А как она проявляется, если она бывает?
Я знаю что FRAG в выводе zpool list — это фрагментация свободного места в пуле. А не, как принято считать, фрагментация файлов.
zfs довольно устойчива к разваливанию. И судя по тому как она хранит данные, то нет особо смысла что-то там восстанавливать при отвалившихся n дисках.
Лично я жду draid в production. Время ребилда будет сильно уменьшено что несомненный плюс.
Я считаю что описанный выше случай с неконсистентностью просто не возможен в zfs by design. В связи с применением «сквозного контроля целостности данных».
Спасибо за статью, а вот ещё про «не готовность к большим инфраструктурам».
Сейчас вообще нет способа настроить биос автоматически.
Поэтому надо или заказывать себе особые биосы у производителя или настраивать руками все 100500 серверов.
Как видно из таблицы, большинство современных SSD имеют размер блока 8192.
2. Также вы напрасно игнорируете пропускную способность контроллера.
Вот хорошая статья про это: www.truesystem.ru/solutions/khranenie_danny/361566
Обратите внимание на максимальное количество iops, которое можно получить с вашего бюджетного контроллера.
3. Также стоит отключать prefetch для zfs.
options zfs zfs_prefetch_disable=1
Иначе вы дополнительно читаете с SSD, что в тесте на случайное чтение даёт худший результат.
4. recordsize.
По нашим тестам для SSD лучше всего использовать размер в 64K.
5. Раз вы используете zfsonlinux, было бы прекрасно после тестов приложить вывод следующих команд:
zpool iostat -w
zpool iostat -r
arc_summary.py
Сделать это после проведения каждого теста. Каждый тест начинать после полного ребута машины.
@VBart Уже ответил. Уверен что если для Вас действительно важны все эти вопросы, то парни из Angie с удовольствием продадут вам платную поддержку. Как я понимаю, весь смысл Angie в том, чтобы можно было покупать платную поддержку "nginx" в России. Плюс появление тех фич, которые F5 не хотят делать по причине конкуренции с их платными фичами. Соответственно те, кто платит за Angie, опосредованно платят за разработку открытой версии. Можете присоединиться =)
Посмотрите на angie, это форк nginx с большим количеством полезных доделок. Статистика, к примеру
Спасибо за статью.
Подскажите, а у вас реально есть vitastor в бою?
Device Model: TOSHIBA HDWL120
Serial Number: 6988PJ5AT
LU WWN Device Id: 5 000039 952503b28
Firmware Version: JT000A
User Capacity: 2,000,398,934,016 bytes [2.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Form Factor: 2.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sun May 3 17:18:02 2020 MSK
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Таких серверов два.
Используются под clickhouse.
За пол года эксплуатации диски несколько раз произвольно вылетали из рейда.
При этом вылетевший диск нормально проходит тесты в лабе.
При добавлении диска обратно в массив продолжает работать без ошибок.
Похоже что и обычные рейды нельзя собирать на этих дисках.
С http было бы точно также, если бы соединение порвалось в середине передачи чанка.
hls не рилтайм формат, его не стоит использовать для общения людей.
Сейчас для двухстороннего общения можно использовать webrtc или websocket/lhls/fmp4.
Получается средняя задержка около 4-х секунд. Максимальная задержка может доходить до 20 секунд из-за необходимости обработать rtmp, играть с ключевых кадров и т.п.
В случае lhls, мы делаем чанки (frames) по 0,1 секунды. Средняя задержка около 1-й секунды. Максимальная задержка может доходить до 6 секунд по вышеуказанным причинам.
Как раз будет обеспечена минимальная задержка и контролируемое соединение.
У нас это отлично работает в большинстве браузеров.
Чего стоит баг (https://github.com/Kurento/bugtracker/issues/247), который правили больше года и так до сих пор и не исправили.
Мы взяли 1080 TI, перепаяли и всё отлично встало в 1U Supremicro 1027GR-TRF.
Илья пишет что используется GP107GL Quadro P400.
Имеется ввиду её процессор или обычный процессор?
«Keep pool capacity below 80% for best performance»
Я знаю что FRAG в выводе zpool list — это фрагментация свободного места в пуле. А не, как принято считать, фрагментация файлов.
zfs довольно устойчива к разваливанию. И судя по тому как она хранит данные, то нет особо смысла что-то там восстанавливать при отвалившихся n дисках.
Картинка про то как хранит тут:
github.com/zfsonlinux/zfs/wiki/dRAID-HOWTO
Лично я жду draid в production. Время ребилда будет сильно уменьшено что несомненный плюс.
Я считаю что описанный выше случай с неконсистентностью просто не возможен в zfs by design. В связи с применением «сквозного контроля целостности данных».
Жаль что в наших супермикрах такого нет.
А как определяется «оптимальность» настроек?
Может есть какой-то общедоступный мануал?
Сейчас вообще нет способа настроить биос автоматически.
Поэтому надо или заказывать себе особые биосы у производителя или настраивать руками все 100500 серверов.
Проще всего воспользоваться готовой базой от maxmind:
dev.maxmind.com/geoip/geoip2/geolite2-asn-csv-database
Кроме ipv4 ещё бывают ipv6.
Выше вам указали на INET_ATON, для ipv6 надо использовать INET6_ATON.
p.s. Мой ipv6 адрес от домашнего провайдера:
2a00:1c78:1:1e95:1114:6cd:600a:111
Наш опыт показывает что так явно будет быстрее.
А также опыт коллективного разума говорит о том же.
www.reddit.com/r/zfs/comments/3tyyj7/why_doesnt_recordsize_default_to_blocksize
Вот тут есть правильная таблица размеров блока:
github.com/zfsonlinux/zfs/blob/ea39f75f64ff72e30900a36e00632f180f5f6676/cmd/zpool/zpool_vdev.c#L102
Как видно из таблицы, большинство современных SSD имеют размер блока 8192.
2. Также вы напрасно игнорируете пропускную способность контроллера.
Вот хорошая статья про это:
www.truesystem.ru/solutions/khranenie_danny/361566
Обратите внимание на максимальное количество iops, которое можно получить с вашего бюджетного контроллера.
3. Также стоит отключать prefetch для zfs.
options zfs zfs_prefetch_disable=1
Иначе вы дополнительно читаете с SSD, что в тесте на случайное чтение даёт худший результат.
4. recordsize.
По нашим тестам для SSD лучше всего использовать размер в 64K.
5. Раз вы используете zfsonlinux, было бы прекрасно после тестов приложить вывод следующих команд:
zpool iostat -w
zpool iostat -r
arc_summary.py
Сделать это после проведения каждого теста. Каждый тест начинать после полного ребута машины.