FreeBSD

Linux vs FreeBSD

Не могу не попиарить мегатред про Linux vs FreeBSD (зачин: Рамблер-почта переезжает с FreeBSD на Linux, там же в каментах про аналогичный переезд Яндексовского кластера).

От себя хочу заметить что хотя часть аргументов лично мне кажется неубедительной (на мой взгляд "монолитная система" - это преимущество, а репозиторий бинарных пакетов для больших кластеров все едино надо иметь локальным), остальные аргументы верные:

  • виртуализация;
  • средства разработки (и не только поминаемый valgrind, но и VTune, например);
  • вообще поддержка новых технологий: OpenCL, CUDA (это если брать мои интересы), Java опять же.
  • да и вообще ВСЕ: Linux стал mainstream, а FreeBSD - увы.
То есть, натурально, единственный настоящий плюс, который я вижу у FBSD на сегодня - это ZFS (ну и разные мои личные тараканы: от iptables меня тошнит, а от ipf - нет). Ну и монолитность, да, выбрать "Linux-дистрибутив", где все было бы достаточно свежим, но при этом не долбанутым на всю голову - лично мне достаточно трудно, ну так у меня и опыта такого мало, впрочем.

Пора, короче, домашний сервер на Linux переводить. Да и виртуальную рабочую станцию разработчика - тоже.

FreeBSD ZFS performance: просто возьмите молоток побольше

Если поискать в этом блоге, особенно в каментах, то найдете что ZFS на трех дисках (RAIDZ) давала у меня скорость чтения/записи порядка 75-80 Mb/sec. Так оно и было до недавнего времени, пока я с этой скоростью не уперся в скорость на сети (samba).

Пришлось навести следствие. Выяснилось очень простое, хотя и не вполне очевидное:

  • У меня был даунклоченый Core2Duo: 1.86Ghz работающий на ~1.6, задаунклочил летом, по случаю жары, просто на всякий случай.
  • При этом при чтении с ZFS system time как правило не рос выше 50%, что я неверно интерпретировал как однопоточность ZFS (судя по всему, неверно, ибо потом в тестах видел и 70% system) и верно интерпретировал как упертость в процессор.
  • Банальный оверклок того же горшка (и памяти) приводил к почти линейному росту скорости FS.

Тогда я пошел в лабаз и купил там еще один 2TB диск и 3.06-гигагерцовый C2D (E7600), собрал все в кучку (дисков стало 4) и результат:

  • 170-195 Mb/sec на запись
  • 230-280 Mb/sec на чтение
Скорость, судя по всему, зависит от того, в какую зону диска, побыстрее или помедленнее, файловая система положила файл. System при этом держится на уровне 20-30%, а изменение частоты горшка на производительность почти не влияет. Ну и Samba в диск больше не упирается.

Все тестирование делалось методом

dd if=/dev/zero of=file bs=1M count=20000
dd if=file of=/dev/null bs=1M
То есть речь о больших файлах, с мелкими всегда все сложнее и хуже.

802.3ad, EtherChannel и прочие....

А я правильно понимаю, что все виды агрегирования двух (и более) Ethernet-ов в один логический линк - они распределяют трафик по отдельным линкам исходя из адресов (MAC или IP) конкретного пакета?

То бишь стандартов я не читал, естественно, но читал википедию и читал интеловский текст про teaming, в обоих местах написано примерно это.

Никаких стандартных способов раскидать по двум линкам пакеты от одного TCP-соединения нету?

А счастье было так близко.....

P.S. Нет, я знаю что у FreeBSD-шного lagg есть round-robin, проблема в том что у меня с другой стороны работают или LACP или EtherChannel, а имеющийся там же LoadBalance работает как-то удивительно.... (это Realtek Ethernet Teaming, если интересно). Но похоже, даже если интеловскими средствами пользоваться (поменять сетевую карту и так далее...), которые более человечные, запихать один TCP-коннект в две трубы - не выйдет.

Поэтосамое по-настоящему

Если вы хотите поеба потрахаться по-настоящему, предлагаю такой вот метод:

  • Создаете ZFS-том терабайт эдак на шесть (меньше не пробовал) на FreeBSD 8.1-RELEASE/STABLE.
  • И записываете туда пару-тройку сотен тысяч файлов с русскими (и европейскими) именами в кодировке UTF-8.
Если вам очень повезет, то вы получите ненулевое количество каталогов в которых нельзя сделать ls или find (и естественно, все остальные, получающие список файлов, вроде du). Если повезет слегка, то ls работать будет, а вот rm * - нет. И rm конкретный-файл - тоже нет.

Единственная выявленная система - это очень длинные, под лимит, имена файлов. Не только русские, но и европейские (с умляутами).

gptzfsboot и все все все....

В копилку знаний сисадмина:

Если у вас ZFS, RAIDZ и загрузка с RAIDZ и вы ставили FreeBSD 8.1-RELEASE

То не поленитесь поапгрейдить бут-блоки на более свежие, те которые в 8.1 - не умеют грузиться с degraded array.

Подробности тут: www.freebsd.org/cgi/query-pr.cgi?pr=148655

Да, а если ваш массив в состоянии resilvering (навернувшийся диск заменили, но массив не успел перестроиться), то и новые бутблоки имеют шанс не загрузиться...

P.S. Нет, диск не ломался, это я просто like to move it, move it, все массивы в доме наращивал до размера побольше....

Народная мудрость

Примета:

Сделать zpool upgrade, но не сделать gpart bootcode ... -p gptzfsboot - означает поипаться от души поиметь немало веселых минут.

Особенно с учетом того, что zpool upgrade делается на лету, а отсутствие нужной версии boot loader становится заметно после перезагрузки. Которая у меня, например, случилась через две недели.

Наука о контактах

Вот такие вот приятные сообщения стал я получать от системы.

Dec 15 07:39:40 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left)
Dec 15 08:02:37 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left)
Dec 15 08:31:23 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left)
Dec 15 08:55:29 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left)
Dec 15 08:58:23 home-gw kernel: ad2: TIMEOUT - FLUSHCACHE48 retrying (1 retry left)
Dec 15 09:01:10 home-gw root: ZFS: vdev I/O failure, zpool=zroot path=/dev/ad2p2 offset=412440274432 size=1536 error=5
Dec 15 09:01:10 home-gw kernel: ad2: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=805547573
Dec 15 09:01:10 home-gw kernel: ad2: FAILURE - WRITE_DMA48 
Как видно, несколько раз в час.

Поменял кабель - не помогло. Подумал, воткнул в другой порт (диск стал ad6). Как рукой сняло, уже полтора дня ни одного разрыва все тихо.

Вот и верь после этого в электронику.

root on ZFS

Для тонких ценителей.
zroot on / (zfs, local)
zroot/home on /home (zfs, local)
zroot/tmp on /tmp (zfs, local, nosuid)
zroot/usr on /usr (zfs, local)
..... и еще с десяток томов под разные нужды....
3 диска, RAIDZ1, 4 терабайта места, "домашний роутер".

Но пришлось раз 10 подойти к снаряду на виртуальной машине, прежде чем многочисленные мелкие грабли оказались обнаружены.

В частности, расширять root pool нельзя, поэтому идея-фикс по переносу данных без многократного переписывания данных не проканала. А была она такая:

  • Было два двухтерабайтника в зеркале, место кончилось, купил третий.
  • Разбиваем зеркало, из двух дисков (один старый, один новый) делаем RAIDZ1, переписываем туда данные.
  • Добавляем второй старый диск в тот же RAID.
Увы, пришлось вылить на внешние диски, собрать массив, налить обратно....

По органолептическим ощущениям, диски сильно меньше нагружены, чем в gmirror, отчего меньше греются. Какой-то статистики наберу за неделю, расскажу....

Упражнения с бревном - 2 (graid5 + gjournal)

Не удержался и попробовал комбинацию из geom_raid5 + gjournal.

Пробовались варианты:

  • Журнал на отдельном диске (старый WD Raptor 36Gb, скорость линейной записи около 60 MB/sec)
  • Журнал на том же массиве, что и файловая система (RAID5 из 750GB дисков Western Digital)

Упражнения с бревном (FreeBSD raid5 performance)

Бурное обсуждение моей предыдущей заметки про аппаратный RAID заставило меня потратить немножко времени в выходные на изучение software raid5 в FreeBSD (других подопытных ОС не оказалось).

Приборы и материалы

FreeBSD 7.1-PRERELEASE - i386, Core2Duo 1.86, 2GB RAM, 3 диска Western Digital WD7500AAKS (750Gb).

Диски я извлек из рабочей станции, там они показывали 140MB/sec на чтение и 120-125 на запись будучи прицеплеными к Areca ARC-1120 в режиме RAID5 под WinXP/Vista.

GEOM RAID5 все еще не входит в комплект FreeBSD, поэтому использовались две из трех имеющихся внешних реализаций: GEOM RAID5 TNG и GEOM RAID5 PP. Забегая вперед скажу, что существенной разницы в производительности я не увидел.

Помимо этого, я посмотрел на производительность RAID0 (GEOM stripe).

Тестирование проводилось на чтении-записи длинных файлов т.к. меня интересуют именно они. На коротких операциях всё может быть иначе, все "короткие" нагрузки настолько разные, что требуют тестирования по месту.

Чудеса виртуализации

Давно собирался, но руки дошли только сейчас.
FreeBSD 6.3-STABLE, amd64, делаем make -j Ncpu buildworld

  • Dual Opteron 275: 22 минуты (user time: 55 минут)
  • Core2Quad, операционка запущена под VMWare, доступны два ядра: 31 минута (user time: 42 минуты)
Другими словами, оверхед на виртуализацию ну процентов 15-30, не больше. То бишь вообще никакой.

Очередная нечистая сила в FreeBSD7

Расшиб себе лоб об семерку в очередной раз. Хочу поставить систему на gmirror, делаю по прописям в Handbook: поставить на отдельный диск, сделать зеркало на другом, переписать туда поставленное, исходный диск добавить в зеркало.

На FreeBSD-7.0-RELEASE/amd64 команда dump 0Luaf /dev/null / работает отлично. А если вместо /dev/null сделать пайп или просто файл на диске (не на / !), то прочитав мегабайт 50-100 оно просто останавливается и стоит.

Апгрейд до -STABLE проблему полностью излечивает, а так я и диски менял и систему после этого переставлял, полдня потратил зря.

Ну и кто они после этого?

Прогресс - зло!

Потерял полдня, прежде чем сложил все кубики в пирамидку (и то, не уверен что правильно).

Нужно: получить PHP5 с клиентом PosgreSQL (всякие прочие extensions на вырост), в виде апачевского модуля, все происходит под FreeBSD7.

  • Apache 1.3, все собираем из ports - не работает. SIGSEGV где-то внутри инициализации pthreads, хотя никому из участников эти threads нафиг не нужны и непонятно кто их приволок. /usr/local/bin/php - работает.
  • Apache 1.3, собираем PHP --with-pgsql - все работает, пока нет загружаемых extensions. Как только появляется хоть одно - падаем.
  • Apache 2.2, собираем все из ports - работает.
  • FreeBSD6 в этот раз не пробовал, но когда в прошлый раз пробовал - работало.

Получается, из-за скромненькой фигулинки всем проектам показан переезд под Apache2 ? И mod_perl2 ? А mod_perl2 небось тоже не работает ?

MySQL не предлагать. С Apache я совладаю как-нибудь, а два сервера баз данных в моей жизни - это уже перебор. Снести семерку тоже не предлагать, UFS2 на терабайтных FS - уже перебор.

Нечистая сила! FreeBSD 7 тоже больно бьется

Продолжаем про острые углы.

Очень больно ударился об FreeBSD 7-STABLE на amd64, точнее об ейный компилятор C++.

Собирал buildworld 29-го февраля, с виду все как обычно. Однако часть собираемых на этой системе бинарников (наших, C/C++, никакого экстремизма) работает странно:

  • один падает на ровном месте (не всегда, но есть test case), если отнести его на другую машину - продолжает падать. А если взять с другой машины (собранный там) и принести ко мне - все отлично работает;
  • другой не может создать файлик BerkeleyDB 4.x (создав перед этим другой почти такой же). Аналогично, собранный на другой машине - у меня работает.
Полдня коту под хвост, правда биясь об эту проблему нашел еще ошибок в нашем новом варезе.

Сейчас опять делаю buildworld, если не поможет, то что, на 6.x откатываться ? А ZFS ?

Update

  1. бинарный апгрейд на 7.0-RELEASE amd64 - не помог;
  2. на 7.0-RELEASE 32bit - все отлично;
  3. порча наступает на db->open(filename,DB_CREATE|DB_TRUNCATE), при этом файл создается (!) но код ошибки ENOENT
Пошел пересаживаться на 7.0 32 бита.

Update 2. На 32 бита не пересел, обидно ведь! С Berkeley DB совладал, но не понимаю почему этой проблемы не было на gcc 3 :). С самопадающим - совладать не могу пока.

FreeBSD: UTF-8 russian collate (вторая попытка)

Несколько дней назад я опубликовал исходник LC_COLLATE для кодировки ru_RU.UTF-8 для использования в FreeBSD. Там же я обещал, что если понадобится не "универсальная" сортировка, а такая же, как в FreeBSD, то сделаю и ее, а обещания нужно выполнять.

Помимо этого, старый вариант не имел вообще никаких шансов попасть в FreeBSD (причины этого мне объяснил Андрей Чернов: нарушается FreeBSD-шное правило, что большие буквы отдельно, а маленькие - отдельно), а новый - такие шансы еще не потерял.

FreeBSD: ru_RU.UTF-8 LC_COLLATE

Несмотря на мой пессимизм относительно сортировки строк с многобайтными символами в FreeBSD, жизнь оказалась лучше, чем мне казалось.

Наш читатель, Александр Загребин, любезно поделился исходником locale LC_COLLATE для FreeBSD, который лечит проблему сортировок для ru_RU.UTF-8. Я немножко поправил Makefile, чтобы результат ставился прямо поверх системного файла, выкладываю (с согласия автора, естественно) это для всеобщего использования:

Update
Я сделал работу над ошибками, обновленный вариант (с тем же URL) и комментарии к нему берите здесь.

Pages

Subscribe to FreeBSD