Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Хорошая новость. Очень радует подержка Hyper-V, вплоть до Live-migration.
Новость хорошая, безусловно, но я считаю, что все же можно было перевести список изменений. А то как-то не серьезно статья из 4х ссылок.
LDNS and Unbound will replace BIND
Выпили BIND? Все меняется. Эра подошла к концу.
Еще бы sendmail выпилили. Непонятно зачем он там со своим языком программирования
Надеюсь вы правда не знаете, а не троллите :)
Скрытый текст
Доподлинно известно, что FreeBSD основана на кодовой базе BSD, в разработке которой участвовал Маршал Кирк МакКузик (Marshall Kirk McKusick). Также доподлинно известно, что оный является сексуальным партнёром соавтора FreeBSD и разработчика sendmail — Эрика Олмана (Eric Allman), с коим открыто сожительствует в течение over 20 лет в любви и согласии.
А есть ли сейчас смысл использовать FreeBSD в новых разработках? Мир так плотно перешел на Linux.
Или есть какие то области, где FreeBSD удобнее чем Linux?
Или есть какие то области, где FreeBSD удобнее чем Linux?
У меня встречный вопрос: зачем мир так массово начал убегать на Linux, там где раньше отлично была FreeBSD.
Недавно проходил собеседования, так вот там открыто сказали «FreeBSD для нас ужас».
Почему так?
Лично для себя: FreeBSD у меня держит nginx, mysql, php-fpm. В среднем около 2000 QPS, 500 RPS…
Недавно проходил собеседования, так вот там открыто сказали «FreeBSD для нас ужас».
Почему так?
Лично для себя: FreeBSD у меня держит nginx, mysql, php-fpm. В среднем около 2000 QPS, 500 RPS…
Ответы лежат в плоскости управляемости бизнес-решений и коммерческой продуктовой поддержки конкретных дистрибутивов GNU/Linux.
Проект FreeBSD не ставит целей коммерциализации, получения какой-то выгоды и, следовательно, не берёт никакой ответственности за судьбу операционной системы в руках пользователей. Интеграторы тоже не видят преимуществ в корабле «свободного плавания», так как не могут быть чётко определены векторы развития и заранее спланированы в связи с ними определённые коммерческие решения.
Проект FreeBSD не ставит целей коммерциализации, получения какой-то выгоды и, следовательно, не берёт никакой ответственности за судьбу операционной системы в руках пользователей. Интеграторы тоже не видят преимуществ в корабле «свободного плавания», так как не могут быть чётко определены векторы развития и заранее спланированы в связи с ними определённые коммерческие решения.
Ну года до 2004 FreeBSD на серверах в рунете на мой взгляд преобладало.
Я думаю, что следующие тренды ее популярность
— В ядре 2.4 или 2.6 ( не помню уж) запилили нормальные достаточно «легкие в создании» треды, которые балансировались по процессорам. Это давало возможность тому же MySQL с выгодной использовать более одного процессора. Во FreeBSD это сделали сильно позже, до этого было ограничение что все треды выполняются на процессоре основого процесса. А тут в индустрии многоядерность уже на подходе.
— Народ оценил удобство apt-get и прочих пакетных систем, и потихоньку пришло просто нежелание возиться с установкой FreeBSD и тратить на это время.
— По моему журналируемые FS тоже как-то подостали на FreeBSD в какой-то момент, но я не уверен.
— Как то так разработчики коммерческого софта тоже на Linux сориентировались. Потому что был коммерчески успешный RedHat.
Я думаю, что следующие тренды ее популярность
— В ядре 2.4 или 2.6 ( не помню уж) запилили нормальные достаточно «легкие в создании» треды, которые балансировались по процессорам. Это давало возможность тому же MySQL с выгодной использовать более одного процессора. Во FreeBSD это сделали сильно позже, до этого было ограничение что все треды выполняются на процессоре основого процесса. А тут в индустрии многоядерность уже на подходе.
— Народ оценил удобство apt-get и прочих пакетных систем, и потихоньку пришло просто нежелание возиться с установкой FreeBSD и тратить на это время.
— По моему журналируемые FS тоже как-то подостали на FreeBSD в какой-то момент, но я не уверен.
— Как то так разработчики коммерческого софта тоже на Linux сориентировались. Потому что был коммерчески успешный RedHat.
А в чем преимущество apt-get перед pkg_add?
Я, лично, последнюю не использовал.
Предпочитаю порты.
А про стратегическое отставание — увы, тут сложно поспорить.
Я, лично, последнюю не использовал.
Предпочитаю порты.
А про стратегическое отставание — увы, тут сложно поспорить.
А а чем для вас разница между тем, как вы представляете пакетный менеджер и тем, чем является pkg_add?
Спасибо. Действительно, никогда не задумывался. Всегда использовал порты.
Да и как-то на FreeBSD серверах вот эти особенности pkg_add не доставляли хлопот.
Из-за моей специфики, у меня в FreeBSD обычно 3-10 пакетов, большая часть из которых — самописные.
И, на мой взгляд, наибольший плюс FreeBSD — базовая система. Когда ты точно знаешь, что у тебя будут такие-то утилиты из коробки и ты с легкостью проверишь pkg_info те 3-10 пакетов, что ты поставил (обычно это делают скрипты).
На ubuntu с ее огромным количеством пакетов, мы уже попадали в ситуацию, когда очередное обновление на -lts системе, что-то кардинально меняло и сервера начинали «сыпаться» после обновления.
Да и как-то на FreeBSD серверах вот эти особенности pkg_add не доставляли хлопот.
Из-за моей специфики, у меня в FreeBSD обычно 3-10 пакетов, большая часть из которых — самописные.
И, на мой взгляд, наибольший плюс FreeBSD — базовая система. Когда ты точно знаешь, что у тебя будут такие-то утилиты из коробки и ты с легкостью проверишь pkg_info те 3-10 пакетов, что ты поставил (обычно это делают скрипты).
На ubuntu с ее огромным количеством пакетов, мы уже попадали в ситуацию, когда очередное обновление на -lts системе, что-то кардинально меняло и сервера начинали «сыпаться» после обновления.
Да хотя бы MPD. В Linux, увы, такого суперкомбайна нету.
А мне непонятно, зачем вообще нужен какой-то линукс, если есть FreeBSD?
Потому что он стал более распространеным. Больше внедрен на всякие устройства. Больше диструбутивов. Больше комьюнити. Легче найти решение проблемы.
Если судить с точки зрения домохозяйки, то вы конечно правы. Популярно, распространено, легко — мечта любой тётеньки. Но мы же должны смотреть на вещи с точки зрения гиков, мне так кажется.
Да и кстати, наличие большого количества кривых и хромых дистрибутивов — как раз наверно самое противное в линуксе. BSD — это целостная система, это не сборка чего попало откуда попало в одну кучу и прилепливание очередного гордого названия.
Да и кстати, наличие большого количества кривых и хромых дистрибутивов — как раз наверно самое противное в линуксе. BSD — это целостная система, это не сборка чего попало откуда попало в одну кучу и прилепливание очередного гордого названия.
Насчет удобства — в выборе между «сидеть на старом ядре/OS» и «обновиться и искать и исправлять возникшие проблемы из-за смены API/ABI/форматов конфигов/вообще полной смены одной подсистемы на другую и т.д. и т.п.» я выбрал «обновиться и работать дальше, ибо ребята из FreeBSD сами позаботились о совместимости».
Ок, сегодняшний пример с заменой системного named на unbound может заставить усомниться в моих словах, но такое происходит нечасто, и лично я давно уже перестал использовать named и только приветствую такую замену.
Что касается разработок — возможно Вы не поверите, но для стриминга видео с SATA-дисков UFS2 + nginx + aio рвет любые комбинации Linux-овых файловых систем, дисковых шедулеров и прочих настроек как sysctl/proc так и nginx. Для обработки сетевых пакетов есть весьма продуманная система Netgraph, для операций ввода-вывода — GEOM.
Разумеется, есть и области, в которых Linux-у нет конкурентов, мультимедиа например, но в целом позиции FreeBSD вполне крепкие, имхо.
Ок, сегодняшний пример с заменой системного named на unbound может заставить усомниться в моих словах, но такое происходит нечасто, и лично я давно уже перестал использовать named и только приветствую такую замену.
Что касается разработок — возможно Вы не поверите, но для стриминга видео с SATA-дисков UFS2 + nginx + aio рвет любые комбинации Linux-овых файловых систем, дисковых шедулеров и прочих настроек как sysctl/proc так и nginx. Для обработки сетевых пакетов есть весьма продуманная система Netgraph, для операций ввода-вывода — GEOM.
Разумеется, есть и области, в которых Linux-у нет конкурентов, мультимедиа например, но в целом позиции FreeBSD вполне крепкие, имхо.
И ZFS еще :)
ZFS это отдельный разговор.
Во первых, она уже и в Линуксе есть, а во вторых, кроме фич у ZFS есть ещё и серьезные недостатки:
— обычно медленнее чем UFS2 (кроме очень специфических нагрузок)
— забирает себе для работы много памяти
— CoW приводит к серьезной фрагментации
— дедупликация — тормоз и требует очень! много памяти
— нет интеграции с vm — кеш держится строго в адресном пространстве ядра, это вообще epic fail
— чексуммы данных — дополнительная нагрузка, при том что hdd и так делает посекторные чексуммы.
— сжатие данных — годится для несжатых логов и исходников, но на сторах обычно архивы и мувики с музыкой )
— кеширование на ssd — как-то неубедительно, надежнее скопировать популярный файл на ssd и симлинкой привязать.
Справедливости ради стоит сказать что быстрые снепшоты — отличная штука для бекапинга )
Во первых, она уже и в Линуксе есть, а во вторых, кроме фич у ZFS есть ещё и серьезные недостатки:
— обычно медленнее чем UFS2 (кроме очень специфических нагрузок)
— забирает себе для работы много памяти
— CoW приводит к серьезной фрагментации
— дедупликация — тормоз и требует очень! много памяти
— нет интеграции с vm — кеш держится строго в адресном пространстве ядра, это вообще epic fail
— чексуммы данных — дополнительная нагрузка, при том что hdd и так делает посекторные чексуммы.
— сжатие данных — годится для несжатых логов и исходников, но на сторах обычно архивы и мувики с музыкой )
— кеширование на ssd — как-то неубедительно, надежнее скопировать популярный файл на ssd и симлинкой привязать.
Справедливости ради стоит сказать что быстрые снепшоты — отличная штука для бекапинга )
Конечно, отдельный и очень большой разговор :) А в Линуксе ZFS, кстати, разве не в юзерспейсе работает?
1) Можно ссылку на источник, где сравниваются производительности UFS2 и ZFS?
2) Потребление памяти в ZFS можно ограничить sysctl-переменными, но это не стоит делать по причине кэширующей природы файловой системы и минимизации «общения» с физическим устройством накопителя. Кэш ARC, кстати, динамический и ужимается до необходимого минимума при востребовании памяти приложениями.
3) При этом у ZFS переменный размер блока не превышающий 128k на блок — существенно широкий разнос, чем у классических файловых систем.
4) Да, дедупликация несёт большие накладные расходы.
5) Ничего не могу сказать — не специалист по адресации памяти.
6) В блоге архитектора ZFS описывалось, почему введение программного чексуммирования более правильно, чем надежда на аппаратные устройства подсчёта контрольных сумм данных. Кроме того, с точки зрения задействования ресурсов CPU это практически ничего не стоит.
7) Сжатие LZ4 годится для всего, так как эффективна детекция несжимаемых данных и подстройка алгоритма под такие данные.
8) Кэширование на SSD ZIL (для операций модификации ФС) и L2ARC (для чтения данных) весьма способствуют увеличению производительности дисковой подсистемы.
9) Для бэкапинга снапшоты пригодны только при условии консистентности операций с ФС запущенных приложений. Базу данных через снапшот нельзя бэкапить, если база данных не остановлена и все операции с ней не прекращены.
2) Потребление памяти в ZFS можно ограничить sysctl-переменными, но это не стоит делать по причине кэширующей природы файловой системы и минимизации «общения» с физическим устройством накопителя. Кэш ARC, кстати, динамический и ужимается до необходимого минимума при востребовании памяти приложениями.
3) При этом у ZFS переменный размер блока не превышающий 128k на блок — существенно широкий разнос, чем у классических файловых систем.
4) Да, дедупликация несёт большие накладные расходы.
5) Ничего не могу сказать — не специалист по адресации памяти.
6) В блоге архитектора ZFS описывалось, почему введение программного чексуммирования более правильно, чем надежда на аппаратные устройства подсчёта контрольных сумм данных. Кроме того, с точки зрения задействования ресурсов CPU это практически ничего не стоит.
7) Сжатие LZ4 годится для всего, так как эффективна детекция несжимаемых данных и подстройка алгоритма под такие данные.
8) Кэширование на SSD ZIL (для операций модификации ФС) и L2ARC (для чтения данных) весьма способствуют увеличению производительности дисковой подсистемы.
9) Для бэкапинга снапшоты пригодны только при условии консистентности операций с ФС запущенных приложений. Базу данных через снапшот нельзя бэкапить, если база данных не остановлена и все операции с ней не прекращены.
1) Тестил лично, замеры в паблик не выкладывал. Под большим трафиком ZFS еле дышит. Хотя однопоточную нагрузку обслуживает нормально.
2) Уменьшить можно, но не нужно. В любом случае, повышенное потребление памяти ZFS для нормальной работы — печальный факт.
3) В UFS2 используются фрагменты размером от 1/8 блока, максимальный размер самого блока — 64К. Но это имеет малое отношение к сильной фрагментации в ZFS из-за CoW.
5) Если вкратце — во первых, кеш ZFS ограничен размером адресного пространства ядра (на 32-х битных это серьезная проблема), а во вторых — нужно дополнительно копировать данные из кеша ZFS (и обратно), хотя «нормальные» ФС во многих случаях могут с поддержкой VM просто забиндить страницу в адресное пространство процесса (или ядра для sendfile() например)
6) Да, оно делает и так маленькую вероятность одновременного согласованного сбоя в данных и чексумме совсем мизерной. Нужно ли это при использовании чексуммирования блоков на дисках и фреймов SATA — сомнительно. А насчет повышенной нагрузки — я имел ввиду не CPU, а собственно диски — на обновление чексумм расходуется IOPS.
7) Годится, но эффект от сжатия все равно минимальный, т.к. слишком мало данных поддаются сжатию.
8) Способствует, но те, кого интересует максимум производительности будут использовать SSD более прямым способом, т.к. это будет во многих случаях очень сильно эффективнее. Хотя ZFS удобнее, т.к. все происходит само )
9) Все правильно, но особых сложностей с этим нет. Для postgresql есть
2) Уменьшить можно, но не нужно. В любом случае, повышенное потребление памяти ZFS для нормальной работы — печальный факт.
3) В UFS2 используются фрагменты размером от 1/8 блока, максимальный размер самого блока — 64К. Но это имеет малое отношение к сильной фрагментации в ZFS из-за CoW.
5) Если вкратце — во первых, кеш ZFS ограничен размером адресного пространства ядра (на 32-х битных это серьезная проблема), а во вторых — нужно дополнительно копировать данные из кеша ZFS (и обратно), хотя «нормальные» ФС во многих случаях могут с поддержкой VM просто забиндить страницу в адресное пространство процесса (или ядра для sendfile() например)
6) Да, оно делает и так маленькую вероятность одновременного согласованного сбоя в данных и чексумме совсем мизерной. Нужно ли это при использовании чексуммирования блоков на дисках и фреймов SATA — сомнительно. А насчет повышенной нагрузки — я имел ввиду не CPU, а собственно диски — на обновление чексумм расходуется IOPS.
7) Годится, но эффект от сжатия все равно минимальный, т.к. слишком мало данных поддаются сжатию.
8) Способствует, но те, кого интересует максимум производительности будут использовать SSD более прямым способом, т.к. это будет во многих случаях очень сильно эффективнее. Хотя ZFS удобнее, т.к. все происходит само )
9) Все правильно, но особых сложностей с этим нет. Для postgresql есть
SELECT pg_start_backup('label');
FLUSH TABLES WITH READ LOCK;
8) SSD для кэширования гораздо дешевле, чем для прямого хранения на них данных. SSD сравнительно небольшого объёма 64-128 ГБ способны поднять производительность дисковой подсистемы с медленными HDD в десятки раз. В этой связке и латентность доступа к часто используемым данным будет мизерной.
Под ZIL отводят зеркало из двух-трёх SLC SSD небольшого объёма, под L2ARC отводят зеркало MLC SSD большего объёма. Всё зависит от интенсивности запросов на ввод-вывод свежих данных, а ресурс флэша той или иной технологии известен. Выпадающие из работы кэширующие составляющие детектятся on-line и на работу в общем-то не оказывают вредного влияния.
Есть такая связка: pf + pfsync + carp, что позволяет красиво строить отказоустойчивые кластеры (без потери пакетов).
а еще есть нормальный трассировщик ktrace, который не зависнет вместе с трассируемой программой и не утянет её в корку.
.
Уже играюсь с bhyve. Works good.
BackupExec не имеет агента под фряху… :( Под линукс имеет.
Если кому интересно, доклад одного из разработчиков ядра на ruBDS 2013: Что нового в FreeBSD 10.0
Вышел официальный анонс!
Список изменений тут www.FreeBSD.org/releases/10.0R/relnotes.html
Список изменений тут www.FreeBSD.org/releases/10.0R/relnotes.html
А зачем повторно анонсировать netmap, если он был проанонсирован в 9.1R?
Великолепная новость, надо будет на досуге посмотреть, что добавили в разрезе zfs
Просмотрел whats new. Основные изменения — допилы виртуализации и embedded устройств.
Для веб-серверов не увидел ничего интересного. Остаемся на 9.
Для веб-серверов не увидел ничего интересного. Остаемся на 9.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышел релиз FreeBSD10.0 (анонс ожидается, доступны iso файлы FreeBSD 10.0-RELEASE)