The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Тестирование производительности аллокаторов памяти FreeBSD и Linux

10.03.2008 11:00

Kris Kennaway провел серию сравнений производительности аллокаторов памяти FreeBSD (тестировалась ветка 8.0) и Fedora 8 Linux (ядро 2.6.24, glibc 2.7). Сравнивалась производительность на тесте ebizzy, симулирующем работу с памятью характерную для баз данных. В качестве аппаратной платформы был использован 8-ядерный сервер на базе Intel Xeon.

Кроме того Kris провел исследование производительности DragonFlyBSD 1.12 в сравнении с FreeBSD 4.11/7.0 и повторил тестирование производительности СУБД, при помощи утилиты sysbench (график тестирования mysql, график тестирования PostgreSQL). Общие выводы отражены в документе "Notes on SMP performance on FreeBSD".

  1. Главная ссылка к новости (http://people.freebsd.org/~kri...)
  2. OpenNews: Новые сравнения производительности FreeBSD и Linux
Автор новости: terminus
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/14649-freebsd
Ключевые слова: freebsd, linux, memory, benchmark
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (86) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, exn (??), 19:10, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    тоесть freebsd 8 круче всех?, так и запишем
     
     
  • 2.19, odmin (ok), 07:48, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Есть хоть какие-то шансы, что во фре появится быстрая FS Без этого пусть хоть в... большой текст свёрнут, показать
     
     
  • 3.20, odmin (ok), 07:58, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, используется 32-битный режим почему-то. Просто тупо молча. Наверное чтобы не говорить лишний раз, что у FreeBSD с её одной единственной веткой портов на ВСЕ семейства с 64-битами всё очень грустно.

    Короче, напрягают меня такие "честные сравнения" со стороны Кенни. Тем более, что у Ника Пиггина даже в предложенных Кеннавеем условиях линукс получается быстрее... С чего бы вдруг....

     
     
  • 4.23, Аноним (23), 08:47, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Что за бред про 32-битный режим? Все на 64бит, никаких проблем.
    Что за бред про одну ветку? А сколько вы хотели? По ветке на архитектуру? Сможете объяснить зачем? Broken на amd64 вообще-то всего 32 порта.
    Про тормозной и сырой ZFS - тоже посмеялся. 2 месяца в продакшне (пока на HA кластере, разумеется) - ни одной проблемы. Такой стабильной ФС я, пожалуй, еще не видел. Со скоростью тоже все ok - с большими файлами и raidz - 90% от теоретического максимума (пропускная способность дисков). На мелких файлах особо не мерял, но по крайней мере операции с деревом портов раз в 5 быстрее UFS.
    fsck мне никогда не был нужен. Хотя с ним потенциальная проблема есть, согласен. Только не поверю что ему нужна ядерная память.

    В общем, все как всегда. Руки.

     
     
  • 5.24, odmin (ok), 09:16, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Что всё Почему тестирование Кенни провёл в заскорузлых 32 битах Откуда дрова... большой текст свёрнут, показать
     
     
  • 6.28, Кирилл (??), 11:53, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/

    >Да, все баги, которые постоянно вылазят у подписчиков freebsd-stable@ твоих прямых рук
    >испугались и спрятались...

    Возможно это касается ветки Карент, но в Стабл никаких проблем в пределах означеной функциональности в обычной эксплуатации не замечал.

     
  • 6.31, portsman (?), 12:14, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >
    >Что "всё"? Почему тестирование Кенни провёл в заскорузлых 32 битах?
    >
    >>Что за бред про одну ветку? А сколько вы хотели? По ветке на архитектуру? Сможете >>объяснить зачем? Broken на amd64 вообще-то всего 32 порта.
    >
    >Откуда дрова? Ни в жисть не поверю, после всего прочитанного в разных
    >листах, что из 18 тысяч портов только 32 штуки в 64битах
    >не работают. ФАНТАСТИКА! Во фре намного больше просто BROKEN портов, не
    >говоря о специфике. Ещё скажите, что на других архитектурах тоже все
    >18 тыщ портов отлично работают... :)

    Зачем верить ну есть же сухая стистика:
    http://portsmon.freebsd.org/portserrcounts.py?buildenv=amd64
    http://pointyhat.freebsd.org/errorlogs/packagestats.html

     
  • 6.61, Аноним (23), 18:13, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Это не в курсе, у него спросите У меня ни на десктопе, ни на ноуте, ни на серве... большой текст свёрнут, показать
     
  • 3.22, i (??), 08:47, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    гг суровая реальность :)
     
  • 3.27, Кирилл (??), 11:44, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Если у вас есть разделы по Терабайту, то строго рекомендуется использовать журнализированную ФС. И кто вам сказал, что она "сырая"? Надо было хотя бы ознакомиться с возможностями и ограничениями различных ф/с перед тем, как терабайтный разделы пилить, а не рассуждать тут о том, что вот система какая плохая, я о неё нихрена не знаю, делаю абы чего, а она ещё работать отказывается, как я себе напридумывал.

    П.С: Господа пионеры, бросай привычку вякнуть абы чего, лишь бы голос подать.

     
     
  • 4.34, odmin (ok), 12:56, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Если у вас разделы по терабайту, то строго рекомендуется использовать нормальную ОС. Я правильно понял? :-D

    Потому как UFS2 якобы и больше поддерживает, но КАК? И в документации, кстати, ни слова про то, что оно будет fsck-аться 3 часа и что сам fsck будет валиться и жрать память как свинья помои. GJOURNAL только вышло из статуса беты, zfs ещё не вышло. Тот кто СЕЙЧАС использует FreeBSD по всем признакам пионер. А вовсе не те, кто ругает бзду...

     
     
  • 5.35, _Nick_ (??), 13:09, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    зачет :)
     
     
  • 6.40, Кирилл (??), 14:31, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >зачет :)

    Нет, _Nick_, не зачёт. Пионер лепит херню. Так что слюни пускать не советую.

     
     
  • 7.46, _Nick_ (??), 15:18, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Нет, _Nick_, не зачёт. Пионер лепит херню. Так что слюни пускать не
    >советую.

    ну, слюна уже пущена :))

    PS с сеня сам переползаю с JFS на ext4. Во де красота.
    И online resize (как в JFS), но и offline shrinking (чего ТАК не хватало
    в JFS), вагон рулей тюнинга, обратная совместимость с ext3 (пока на включишь
    новые фичи).

     
     
  • 8.55, Михрютка (?), 16:31, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    offline shrinking - это де опечатка если online shrinking, то в jfs2 вполне себ... текст свёрнут, показать
     
     
  • 9.57, _Nick_ (ok), 16:46, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    никаких опечаток Хоть какой shrinking Потому как в JFS Линуховом его нету ваще... текст свёрнут, показать
     
  • 5.36, Аноним (-), 13:21, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > будет fsck-аться 3 часа

    сократи кол-во inode'ов

    newfs(8)

         -i bytes
                 Specify the density of inodes in the file system.  The default is
                 to create an inode for every (4 * frag-size) bytes of data space.
                 If fewer inodes are desired, a larger number should be used; to
                 create more inodes a smaller number should be given.  One inode
                 is required for each distinct file, so this value effectively
                 specifies the average file size on the file system.

     
  • 5.42, BayaN (ok), 14:32, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Тот кто СЕЙЧАС использует FreeBSD по всем признакам пионер. А вовсе не те, кто ругает бзду...

    Так, а зачем тогда ты её используешь? Используй Linux, лично меня в нём всё устраивает.

     
     
  • 6.45, Кирилл (??), 14:46, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/

    >Так, а зачем тогда ты её используешь? Используй Linux, лично меня в
    >нём всё устраивает.

    А какие в линуксе есть встроенные механизмы защиты данных при нештатной перезагрузке? Я без иронии, просто не в курсе многих решений. И как Линукс обрабатывает терабайтные разделы с десятками миллионов файлов?

     
     
  • 7.48, _Nick_ (??), 15:25, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А какие в линуксе есть встроенные механизмы защиты данных при нештатной перезагрузке?
    >Я без иронии, просто не в курсе многих решений.

    журнал.
    если какой коммит не закончится полностью (что большая редкость, как ты понимаешь),
    то fsck пойдет полную проверку делать. Иначе (считай 99% сбоев) - просто откатит журнал.
    Секунды.

    >И как Линукс обрабатывает терабайтные разделы с десятками миллионов файлов?

    Да вот так же и обрабатывает :)
    Есть пара толстых стораджей с 4Тб рейдами.
    Ну, пара лет уже как, но ни разу полный чек не потребовалсо.
    Обычная ext3.

     
     
  • 8.53, andr.mobi (ok), 15:55, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    А почему журнал по-умолчанию отключен Не потому ли, что он так тормозит работу ... большой текст свёрнут, показать
     
     
  • 9.56, _Nick_ (ok), 16:42, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    ls -l my_file -rw-r--r-- 1 root root 1048577048576 Mar 11 05 40 my_file конеч... текст свёрнут, показать
     
  • 9.68, Michael Shigorin (ok), 20:33, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Долго думали такую несусветную глупость сообразить Нешто будете мерять UFS2 пр... большой текст свёрнут, показать
     
  • 7.52, BayaN (ok), 15:39, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Ну для начала в большинстве Linux овых ФС есть журналирование Во-вторых часть д... большой текст свёрнут, показать
     
     
  • 8.54, Аноним (-), 15:59, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    COW в ZFS не копирует неизмененные блоки, а только меняет метаданные на измененн... большой текст свёрнут, показать
     
     
  • 9.58, BayaN (ok), 17:41, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Ну ещё бы она копировала то, что уже и так на диске Чтение не составляет пробле... текст свёрнут, показать
     
  • 7.67, Michael Shigorin (ok), 20:22, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А какие в линуксе есть встроенные механизмы защиты данных при нештатной перезагрузке?

    Журнал, как обычно.

    >И как Линукс обрабатывает терабайтные разделы с десятками миллионов файлов?

    Нормально себе отрабатывает.  И многотерабайтные с непомнюсколькофайлов -- тоже.  Причём очень давно: в 2003 вовсю стораджи со специализированным дистрибутивом на базе ALT Linux с XFS и управлением томами разбирали :)

     
  • 5.43, Кирилл (??), 14:34, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/

    >Я правильно понял? :-D

    Не знаю. Видно, что с пониманием у тебя по жизни не лады.

     
  • 3.37, Аноним (-), 13:36, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Есть хоть какие-то шансы, что во фре появится быстрая FS? Без этого
    >пусть хоть в 2 раза быстрее аллокатор будет, в реальной жизни
    >FreeBSD будет в аутсайдерах.

    реальная жизнь это не только PC-серверы, а еще и embedded хотя бы. Не везде нужна такая FS как zfs.

    >ZFS ещё совсем сырое и по дизайну мегатормозное.

    сравни версию во фре и в солярке. Но тормозит скорее всего у тебя интерфейс между стулом и компьютером.

    > UFS2+SU?

    нет, просто ufs2 на gmirror или gstripe. softupdates - это вообще отдельная "веселая" песня.

    > при количестве inode-ов в 40млн

    а зачем тебе столько inode'ов? язык чесать?

     
     
  • 4.39, Юзеръ (ok), 14:17, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Во-во На этот случай нужна простая и легкая FS и желательно быстрая UFS тут топо... большой текст свёрнут, показать
     
     
  • 5.41, Аноним (-), 14:32, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А вы давно на емкость современных HDD смотрели?Далеко не любой файл весит
    >по 600 мегабайт, а?Ну в общем стандартные ответы из рубрики "свое
    >... не пахнет" :\

    Что ты будешь делать, если накроется журнал? Молиться на btrfs (ака vapourware от orcale'а)?
    для больших объемов есть FS с checksum'ами типа ZFS, HAMMER, NILFS, GPFS и тп. А вот JFS и XFS в пролете.
    Журналирование можно сделать и в VM, т.е. заюзать GJournal, и не использовать fsck. Но полагаться на журнал - это, конечно, плевать на все, кроме ребутов/зависаний. Если начнет глючить контроллер или драйвер, то как тебя твой журнал спасет?

     
     
  • 6.44, Аноним (-), 14:36, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Журналирование можно сделать и в VM, т.е. заюзать GJournal, и не использовать fsck.

    sorry,

           Gjournaled file system has to be fscked, but only to handle orphaned
           files. Such fsck on multiterabyte provider takes seconds, not hours.

     
  • 6.47, _Nick_ (??), 15:21, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Если начнет глючить контроллер или драйвер, то как тебя
    >твой журнал спасет?

    када глючит железо - надо его менять, а не выбирать ФС "понадежнее".

    Винт может глюкнуть так, что больше не определится даже в биосе.
    Так что, нужно на журналирование забивать из-за этого?

     
     
  • 7.49, Аноним (-), 15:30, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >када глючит железо - надо его менять, а не выбирать ФС "понадежнее".

    железо не вечно и backup никто не отменял, однако добавить к этому еще и надежную фс как ZFS не помешает

    >Винт может глюкнуть так, что больше не определится даже в биосе.
    >Так что, нужно на журналирование забивать из-за этого?

    это наоборот, повезло, т.к. ты узнаешь, что данные испорчены и может заюзать backup. А что ты будешь делать с silent error? Как от этого тя спасет журнал? checksum'ы помогут восстановить копиую из резерва или пометить файл как содержащий ошибку.

     
     
  • 8.50, _Nick_ (??), 15:32, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    нет предела наворотам За сим и смотрю на ext4... текст свёрнут, показать
     
  • 8.51, Аноним (-), 15:33, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    речь о комплексной политике обеспечения надежности Полагаться на один журнал, н... текст свёрнут, показать
     
     
  • 9.59, odmin (ok), 17:47, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Бред А ОЗУ заглючит или винт начнет вылетать, никакое ZFS не спасёт Тогда смыс... текст свёрнут, показать
     
     
  • 10.62, ZANSWER (??), 18:18, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    В ZFS есть IO checksum, кроме block checksum, так что глюки памяти и винта таки ... текст свёрнут, показать
     
     
  • 11.63, _Nick_ (ok), 18:26, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    что ты запоешь, когда в ZFS начнут находить проблемы съежжать на наличие ошибо... текст свёрнут, показать
     
     
  • 12.64, ZANSWER (??), 18:33, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю, что убью себя -D в чем-то достаточно большом и сложном их нет Nick, ды... текст свёрнут, показать
     
     
  • 13.65, _Nick_ (ok), 18:39, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    ну вот ... текст свёрнут, показать
     
  • 13.71, Michael Shigorin (ok), 20:42, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Не делайте этого, пожалуйста http www datacenterknowledge com archives 2008... текст свёрнут, показать
     
     
  • 14.81, ZANSWER (??), 07:52, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    http www datacenterknowledge com archives 2008 Jan 16 joye это в ZFS, но н... текст свёрнут, показать
     
  • 12.86, Кирилл (??), 10:16, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    _Nick_, вряд ли в ZFS найдут критические ошибки Всё таки это основная продакшэн... текст свёрнут, показать
     
     
  • 13.88, _Nick_ (??), 18:22, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    вряд ли в ext3 будут проблемы, это же, все-таки, основная система для всех Линух... текст свёрнут, показать
     
  • 13.90, ZANSWER (??), 20:25, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то Вы Кирилл не туда совсем, нет я понимаю, я вот жертва SUN-овских маркетол... текст свёрнут, показать
     
  • 11.79, odmin (ok), 05:59, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    И как поможет IO checksum ОЗУ или винт начали мусор гнать, zfs увидело ошибку,... текст свёрнут, показать
     
     
  • 12.80, ZANSWER (??), 07:49, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Запись не будет продолжаться, сюрприз Так вот в Solaris 10 так и происходит,... текст свёрнут, показать
     
  • 10.74, nuclight (ok), 22:21, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Точно тролль И дезинформатор, хоть бы почитать что потрудился Gjournal использ... текст свёрнут, показать
     
     
  • 11.78, odmin (ok), 05:52, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Я больше доверяю инфе с freebsd-stable , чем анонимным аналитикам с опеннета В ... текст свёрнут, показать
     
     
  • 12.83, nuclight (ok), 09:12, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Вот ты и есть анонимный аналитик, а я не только рассылки читаю, но и код пишу Т... текст свёрнут, показать
     
  • 7.85, Кирилл (??), 10:13, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/

    >> када глючит железо - надо его менять, а не выбирать ФС "понадежнее".

    Знать бы когда оно решит глючить. ZFS в этом плане очень удобное решение.

     
  • 6.69, Michael Shigorin (ok), 20:39, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Если начнет глючить контроллер или драйвер, то как тебя твой журнал спасет?

    Так, для справки: замечено, что при битой (разогнанной, перегретой...) памяти у людей xfs отваливало систему в ro с внятной руганью в лог.

    Про развал журнала пока только слышал, но "не фонтан".  Самому сталкиваться не доводилось.

    Кажется, там рейд с батарейкой суппорт радостно дёргал по питанию (то ли на агаве, то ли на мастерхосте).

     
  • 5.73, nuclight (ok), 22:11, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>> при количестве inode-ов в 40млн
    >>а зачем тебе столько inode'ов? язык чесать?
    >
    >А вы давно на емкость современных HDD смотрели?Далеко не любой файл весит
    >по 600 мегабайт, а?Ну в общем стандартные ответы из рубрики "свое
    >... не пахнет" :\

    А причем тут емкость HDD, а? покажите мне df -i хоть с одной промышленной системы, где есть разделы с более чем миллионом файлов.

     
     
  • 6.75, Michael Shigorin (ok), 23:14, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >покажите мне df -i хоть с одной промышленной системы,
    >где есть разделы с более чем миллионом файлов.

    До кластера отсюда не дотянуться :), а из того, что поближе --

    /dev/mdN       xfs      890M    986K    889M    1% ~ftp
    /dev/mdK       xfs      110M    324K    109M    1% ~ftp/pub/Linux/ALT

     
     
  • 7.82, nuclight (ok), 09:06, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>покажите мне df -i хоть с одной промышленной системы,
    >>где есть разделы с более чем миллионом файлов.
    >
    >До кластера отсюда не дотянуться :), а из того, что поближе --
    >
    >
    >/dev/mdN       xfs      890M    986K    889M    1% ~ftp
    >/dev/mdK       xfs     110M    324K    109M   1% ~ftp/pub/Linux/ALT

    Ну и? Оба раздела не превышают даже ОДНОГО миллиона. Тогда как в исходном посте говорилось про 40.


     
  • 6.76, fedya (??), 02:20, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > А причем тут емкость HDD, а? покажите мне df -i хоть с одной
    > промышленной системы, где есть разделы с более чем миллионом файлов.

    [root@lxwdc1 ~]# df -ih
    Filesystem            Inodes   IUsed   IFree IUse% Mounted on
    [...]
    /dev/mapper/VolGroup01-LogVol00
                            2.5G    129M    2.4G    6% /mnt/aoe1

     
     
  • 7.84, nuclight (ok), 09:13, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >
    > [root@lxwdc1 ~]# df -ih
    > Filesystem          
    > Inodes   IUsed   IFree IUse% Mounted on
    >
    > [...]
    > /dev/mapper/VolGroup01-LogVol00
    >            
    >          
    > 2.5G    129M    2.4G  6% /mnt/aoe1

    Хм. А что у вас там лежит, на такое количество файлов? И какая вложенность каталогов?

     
     
  • 8.92, fedya (??), 22:08, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Это e-discovery NAS http en wikipedia org wiki Data_processing_architecture_... текст свёрнут, показать
     
     
  • 9.93, nuclight (ok), 09:25, 13/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    А, ну так NAS SAN нередко имеют собственную FS, железка может даже не иметь на с... текст свёрнут, показать
     
  • 3.60, fedya (??), 17:59, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Вчера вычитал в рассылке freebsd-stable@

    Дайте, пожалуйста, ссылку...

    > Для проверки террабайтной UFS2 fsck надо гиг ОЗУ, причём в kernelspace, соответственно,
    > надо /boot/loader.conf править и перегружаться.

    Это странно, fsck работает в userspace и использует своп если ей надо.  fsck *может* потребоватся гиг виртуальной памяти на терабайт диска, но это не обязательно, зависит от параметров файловой системы.  См. http://groups.google.com/group/lucky.freebsd.fs/browse_thread/thread/d69ac01f

    Для сравнения, полная проверка 15T xfs c дефолтными настройками на CentOS 4.5 у меня заняла 26 часов и 18 гиг памяти. XFS, кстати, не поддерживает бэкграунд чекинг.

     
     
  • 4.77, Wulf (ok), 02:29, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >> Вчера вычитал в рассылке freebsd-stable@
    >Дайте, пожалуйста, ссылку...

    Вероятне всего, имеется ввиду следующий тред:
    http://groups.google.com/group/lucky.freebsd.stable/browse_thread/thread/c348

    Кстати, "матерый бздун Oliver Fromme" там и повторил, что при дефолтных newfs-ных параметрах для fsck на 1ТБ UFS2 надо 1G памяти, только в userspace. Естественно, совет добавить памяти им был дан для ускорения fsck, дабы последний не лез в swap. Я могу предположить, что проблема озвученная в треде была вызвана банальным неподмонтированым swap-ом в single user mode.
    Не про какую необходимость правки /boot/loader.conf и перезагрузку там и не упоминалось. Только топикстартер зачем-то прописал бесполезные параметры kern.maxdsiz и kern.dfldsiz, которые обычно осью определяются правильно. Но это его собственные тараканы. Могу напомнить что кол-во памяти для ядерного malloc, т.е. фактически kernelspace выставляется через vm.kmem_size и vm.kmem_size_max, но на fsck не особо влияют.

    Как резюме, можно посоветовать гражданину Одмину учить английский вместо олбанского, может тогда хоть смысл текста начнет понимать.

     
  • 3.66, nuclight (ok), 19:50, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Не, а кто чуваку виноват, что он отформатировал такой большой раздел с дефолтными параметрами. У людей вон есть UFS2 на 6 терабайт нормально отформатированная есть, и ничего, fsck работает. Что предложили вытащить - а что еще советовать чуваку, если он уже в ситуацию попал? Убиться об стену? Неконструктивно.

    >ZFS ещё совсем сырое и по дизайну мегатормозное. GJOURNAL ещё сырое.

    Ага, все умрем. Не все так печально. ZFS считается экспериментальной, и кстати довольно быстрой. И для экспериментальной FS у нее весьма высокая надежность. Плюс - класс задач - терабайты не везде нужны пока. У меня вот 300-гиговый раздел на UFS2+SU проверяется за считанные секунды.

     

  • 1.3, sauron (??), 20:10, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    О том что аллокатор памяти в libc фиговат для потоковых приложений известно давно.
     
     
  • 2.72, Michael Shigorin (ok), 20:50, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >О том что аллокатор памяти в libc фиговат для потоковых приложений известно давно.

    Да он и вообще до недавних пор (e.g. в glibc-2.5) был не сильно-то адекватен текущему положению дел в linux-2.6 :(

     

  • 1.4, BayaN (ok), 20:21, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >FreeBSD 7.0 does not support the MFS file system; the nearest alternative is the tmpfs filesystem which was used for this test.

    Понравилось сравнение тёплого с мягким, ближе просто некуда. Добавил бы тогда NetBSD с tmpfs для интереса.

     
     
  • 2.16, Аноним (-), 23:10, 10/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>FreeBSD 7.0 does not support the MFS file system; the nearest alternative is the tmpfs filesystem which was used for this test.
    >
    >Понравилось сравнение тёплого с мягким, ближе просто некуда. Добавил бы тогда NetBSD
    >с tmpfs для интереса.

    Согласен. И вообще, это когда MFS исключили из 7-ки? tmpfs же все еще экспериментальная (как и zfs)...

     

  • 1.5, Аноним (-), 20:23, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    SLAB ili SLUB bil v fedore ?
     
     
  • 2.32, Аноним (23), 12:16, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >SLAB ili SLUB bil v fedore ?

    SLUB

     

  • 1.6, terminus (ok), 20:32, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Диллон только обещает. Весь kerneltrap.org исписал, писатель... Посмотрим что он там со своим Hammer сделает.
     
  • 1.7, _Nick_ (ok), 21:25, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    нечесный тест.
    Берет Бздю в карренте - брал бы и 2.6.25-rc4/5 ядро.

    А так - очередной бойан

     
     
  • 2.9, PereresusNeVlezaetBuggy (ok), 21:32, 10/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Это на Опеннет ее очередная опечатка:

    "The following graph compares FreeBSD 7.0 and Linux 2.6.24+glibc 2.7"

     
     
  • 3.12, PereresusNeVlezaetBuggy (ok), 21:43, 10/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Это на Опеннет ее очередная опечатка:

    А это уже моя опечатка:))). Конечно, "на Опеннете очередная" :)

     
     
  • 4.14, _Nick_ (ok), 22:01, 10/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    да ты хоть по ссылке сходи.
    Первый де график - FBSD-8.0 и Fedora с 2.6.24

    бойан

     
     
  • 5.15, PereresusNeVlezaetBuggy (ok), 22:08, 10/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >да ты хоть по ссылке сходи.
    >Первый де график - FBSD-8.0 и Fedora с 2.6.24
    >
    >бойан

    Ыыы, просто само тестирование меня самой своей идеей не впечатлило, изучать не стал. :( Впрочем, если я не ошибаюсь, там действительно аллокаторы одинаковые...

     
  • 3.13, Аноним (-), 21:50, 10/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Это на Опеннет ее очередная опечатка:
    >
    >"The following graph compares FreeBSD 7.0 and Linux 2.6.24+glibc 2.7"

    Не опечатка, тестировали именно FreeBSD 8, читайте дальше пояснение к графикам:
    "This graph shows FreeBSD 8.0 but FreeBSD 7.0 does not perform substantially differently"

     

  • 1.8, Аноним (23), 21:29, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нравится тенденция тестирования DragonflyBSD вместе с другими системами. По всем тестам она сливает просто катастрофично. Надеюсь, Диллон одумается и закроет проект, а полезные наработки типа hammer и vkernel перенесет на FreeBSD CURRENT. Ибо DF чуть менее, чем полностью бесполезная трата времени разработчивов. PS. Еще умиляют местные защитники DFBSD, которые сами ее не используют :)
     
     
  • 2.11, PereresusNeVlezaetBuggy (ok), 21:41, 10/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Нравится тенденция тестирования DragonflyBSD вместе с другими системами. По всем тестам она
    >сливает просто катастрофично. Надеюсь, Диллон одумается и закроет проект, а полезные
    >наработки типа hammer и vkernel перенесет на FreeBSD CURRENT. Ибо DF
    >чуть менее, чем полностью бесполезная трата времени разработчивов. PS. Еще умиляют
    >местные защитники DFBSD, которые сами ее не используют :)

    Блин, ну вам-то лично чем эта ОС мешает?! Я её тоже не использовал напрямую, но при этом я пользуюсь мелкими и не очень наработками, которые приходят именно из этой ОС. И то, что они приходят именно из DragonFly BSD говорит о том, что именно организация разработки этой ОС лучше всего подходит для появления данных конструкций (драйверов, например).

    И не надо говорить, что разработчики DragonFly BSD лучше бы пригодились в других проектах. Во-первых, если бы им лучше работалось в других проектах, то они работали бы в других проектах, а там, где им лучше работается, там и результаты лучше (поскольку ОС открытая, то польза, опять же, всем - см. выше). А во-вторых, вы предпочитаете конкуренцию или моно-/олигополию?

    Если честно, я снимаю шляпу перед разработчиками DFBSD, что они взялись за этот проект, когда рынок, казалось, уже давно был поделен.

    Ну а насчёт того, что 4.x устарело - надоело, чесслово. Если для вас важнее то, что появилось только в 5.x/6.x/7.x - то пользуйтесь, пожалуйста, никто вам не мешает! Но, пардон, обсирать-то других зачем?! Глупо выглядит, а вовсе не понтово.

     

  • 1.17, Аноним (-), 23:36, 10/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    кста, кто-нить нашел его комментарии по тестам жабы:
    http://people.freebsd.org/~kris/scaling/specjava.png
    http://people.freebsd.org/~kris/scaling/specjbb2005.png

    а? или это недоделанный бенчмарк?

     
  • 1.21, Аноним (23), 08:16, 11/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    После тестов SMP нет доверия к этому товарищу.
     
     
  • 2.25, terminus (ok), 10:52, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >После тестов SMP нет доверия к этому товарищу.

    Nick Piggin гонял недавно на ванильном 2.6.25-rc4, а Kriss тогда еще гонял на 2.6.23. При чем тут доверие, просто те тесты MySQL устарели...

    А вообще прикольно наблюдать за этими товарищами. Ждем ответ от Nick Piggin =)

     
     
  • 3.30, Аноним (23), 12:13, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Да я это именно из-за 2.6.22. Результаты тут http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/ очень отличаются от результатов Криса.
     
  • 3.38, Аноним (-), 13:42, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > А вообще прикольно наблюдать за этими товарищами. Ждем ответ от Nick Piggin =)

    А бенчмарки без политики не бывают. ;)

     

  • 1.87, fsck (??), 10:34, 12/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    да уж линух
    помниться знакомым занимающимся железом притянули винт который толи начал сыпаться толи еще что то
    но линухоид с ним ничего сделать несмог
    я при этом присутсвовал(когда принесли и обясняли проблему)
    хардовики протестили и сказали проблемы с винтом нет
    эт где то на уровне операционки
    ну линуха под рукой небыло
    запустил bsd 4
    прочекал ее bsd шным fsck
    она там все пофиксила
    винт вернули линухоиду......
    он аж плакал - поскольку там был биллинг и вся статистика за несколько лет по клиентам
    вот
    а вы кричите линух линух....
     
     
  • 2.89, Анонимускун (?), 18:27, 12/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    кто ж знал, что ты такой идиот и будешь использовать fsck_ufs или fsck_ffs вместо fsck.ext2 или fsck.ext3 (из комплекта sysutils/e2fsprogs)

    ССЗБ!

     

  • 1.91, Аноним (91), 21:35, 12/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    если бы небыл идиотом то понял бы что так и было
    или мне каждому идиоту разжопывать и в рот пихать?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру