форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"OpenNews: Тестирование производительности аллокаторов памяти..."

Сообщение от opennews (??) on 10-Мрт-08, 19:10

Kris Kennaway провел (http://people.freebsd.org/~kris/scaling/ebizzy.html) серию сравнений производительности аллокаторов памяти FreeBSD (тестировалась ветка 8.0) и Fedora 8 Linux (ядро 2.6.24, glibc 2.7). Сравнивалась производительность на тесте ebizzy (http://sourceforge.net/projects/ebizzy/), симулирующем работу с памятью характерную для баз данных. В качестве аппаратной платформы был использован 8-ядерный сервер на базе Intel Xeon. Кроме того Kris провел исследование (http://people.freebsd.org/~kris/scaling/dfly.html) производительности DragonFlyBSD 1.12 в сравнении с FreeBSD 4.11/7.0 и повторил тестирование (http://people.freebsd.org/~kris/scaling/mysql.html) производительности СУБД, при помощи утилиты sysbench (график тестирования mysql (http://people.freebsd.org/~kris/scaling/os-mysql.png), график тестирования PostgreSQL (http://people.freebsd.org/~kris/scaling/os-pgsql.png)). Общие выводы отражены в документе "Notes on SMP performance on FreeBSD (http://people.freebsd.org/~kris/scaling/smp.html)". URL: http://people.freebsd.org/~kris/scaling/ebizzy.html Новость: http://www.opennet.ru/opennews/art.shtml?num=14649

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

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

Сообщение от exn (??) on 10-Мрт-08, 19:10

тоесть freebsd 8 круче всех?, так и запишем

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от odmin (ok) on 11-Мрт-08, 07:48
	Есть хоть какие-то шансы, что во фре появится быстрая FS? Без этого пусть хоть в 2 раза быстрее аллокатор будет, в реальной жизни FreeBSD будет в аутсайдерах. ZFS ещё совсем сырое и по дизайну мегатормозное. GJOURNAL ещё сырое. Что остается? UFS2+SU? Ugh..... Вчера вычитал в рассылке freebsd-stable@. Просто офигел... Для проверки террабайтной UFS2 fsck надо гиг ОЗУ, причём в kernelspace, соответственно, надо /boot/loader.conf править и перегружаться. При этом FS проверяется больше часа. Дальше вылез Мэтт Диллон и добавил, что при количестве inode-ов в 40млн, на архитектуре i386 даже теоретически не хватит памяти проверить такую FS. А Oliver Fromme (тоже матерый бздун) предложил вытащить из соседнего сервака памяти и воткнуть в тот, что всё никак не может проfsckаться.... Короче, enterprise просто мощный... Я читал и плакал... Хотя совсем не так давно я фанател по этой ОС... %-[~~~
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от odmin (ok) on 11-Мрт-08, 07:58
	Кстати, используется 32-битный режим почему-то. Просто тупо молча. Наверное чтобы не говорить лишний раз, что у FreeBSD с её одной единственной веткой портов на ВСЕ семейства с 64-битами всё очень грустно. Короче, напрягают меня такие "честные сравнения" со стороны Кенни. Тем более, что у Ника Пиггина даже в предложенных Кеннавеем условиях линукс получается быстрее... С чего бы вдруг....
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 08:47
	Что за бред про 32-битный режим? Все на 64бит, никаких проблем. Что за бред про одну ветку? А сколько вы хотели? По ветке на архитектуру? Сможете объяснить зачем? Broken на amd64 вообще-то всего 32 порта. Про тормозной и сырой ZFS - тоже посмеялся. 2 месяца в продакшне (пока на HA кластере, разумеется) - ни одной проблемы. Такой стабильной ФС я, пожалуй, еще не видел. Со скоростью тоже все ok - с большими файлами и raidz - 90% от теоретического максимума (пропускная способность дисков). На мелких файлах особо не мерял, но по крайней мере операции с деревом портов раз в 5 быстрее UFS. fsck мне никогда не был нужен. Хотя с ним потенциальная проблема есть, согласен. Только не поверю что ему нужна ядерная память. В общем, все как всегда. Руки.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от odmin (ok) on 11-Мрт-08, 09:16
	>Что за бред про 32-битный режим? Все на 64бит, никаких проблем. Что "всё"? Почему тестирование Кенни провёл в заскорузлых 32 битах? >Что за бред про одну ветку? А сколько вы хотели? По ветке на архитектуру? Сможете объяснить зачем? Broken на amd64 вообще-то всего 32 порта. Откуда дрова? Ни в жисть не поверю, после всего прочитанного в разных листах, что из 18 тысяч портов только 32 штуки в 64битах не работают. ФАНТАСТИКА! Во фре намного больше просто BROKEN портов, не говоря о специфике. Ещё скажите, что на других архитектурах тоже все 18 тыщ портов отлично работают... :) >Про тормозной и сырой ZFS - тоже посмеялся. 2 месяца в продакшне >(пока на HA кластере, разумеется) - ни одной проблемы. Такой стабильной >ФС я, пожалуй, еще не видел. Со скоростью тоже все ok >- с большими файлами и raidz - 90% от теоретического максимума >(пропускная способность дисков). На мелких файлах особо не мерял, но по >крайней мере операции с деревом портов раз в 5 быстрее UFS. Да, все баги, которые постоянно вылазят у подписчиков freebsd-stable@ твоих прямых рук испугались и спрятались... >fsck мне никогда не был нужен. Хотя с ним потенциальная проблема есть, >согласен. Только не поверю что ему нужна ядерная память. >В общем, все как всегда. Руки. Не верь дальше. Как всегда - фанаты упёрты.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Кирилл (??) on 11-Мрт-08, 11:53
	>Да, все баги, которые постоянно вылазят у подписчиков freebsd-stable@ твоих прямых рук >испугались и спрятались... Возможно это касается ветки Карент, но в Стабл никаких проблем в пределах означеной функциональности в обычной эксплуатации не замечал.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от portsman on 11-Мрт-08, 12:14
	>[оверквотинг удален] > >Что "всё"? Почему тестирование Кенни провёл в заскорузлых 32 битах? > >>Что за бред про одну ветку? А сколько вы хотели? По ветке на архитектуру? Сможете >>объяснить зачем? Broken на amd64 вообще-то всего 32 порта. > >Откуда дрова? Ни в жисть не поверю, после всего прочитанного в разных >листах, что из 18 тысяч портов только 32 штуки в 64битах >не работают. ФАНТАСТИКА! Во фре намного больше просто BROKEN портов, не >говоря о специфике. Ещё скажите, что на других архитектурах тоже все >18 тыщ портов отлично работают... :) Зачем верить ну есть же сухая стистика: http://portsmon.freebsd.org/portserrcounts.py?buildenv=amd64 http://pointyhat.freebsd.org/errorlogs/packagestats.html
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	61. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 18:13
	>>Что за бред про 32-битный режим? Все на 64бит, никаких проблем. >Что "всё"? Почему тестирование Кенни провёл в заскорузлых 32 битах? Это не в курсе, у него спросите. >>Что за бред про одну ветку? А сколько вы хотели? По ветке на архитектуру? Сможете объяснить зачем? Broken на amd64 вообще-то всего 32 порта. >Откуда дрова? Ни в жисть не поверю, после всего прочитанного в разных >листах, что из 18 тысяч портов только 32 штуки в 64битах >не работают. ФАНТАСТИКА! Во фре намного больше просто BROKEN портов, не >говоря о специфике. Ещё скажите, что на других архитектурах тоже все >18 тыщ портов отлично работают... :) У меня ни на десктопе, ни на ноуте, ни на серверах каких-то 64bit-specific проблем не было. Дрова из grep BROKEN по Makefiles | grep amd64. 36. Минус четыре штуки, где amd4 в другом контексте. Это официально BROKEN. Неофициально сломанные вылезли бы при сборке на кластере, ссылки вам дали. Лишних сломанных там, как видите, нет. Там была еще красивая статистика в виде гистограмм, сами ищите. >Да, все баги, которые постоянно вылазят у подписчиков freebsd-stable@ твоих прямых рук >испугались и спрятались... Подписаться что-ли. Видимо, веселое чтиво. >Не верь дальше. Как всегда - фанаты упёрты. Если появится что-то более подходящее под мои нужды, чем фря, я буду использовать именно это. Меня больше беспокоят неадекватные личности, которые не просто любят поорать, как у них ничего не работает, но и подоказывать, что у остальных оказывается тоже все сломано. Порты не собираются, ZFS сырой и тормозной, ага. Не люблю троллей.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от i (??) on 11-Мрт-08, 08:47
	гг суровая реальность :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Кирилл (??) on 11-Мрт-08, 11:44
	Если у вас есть разделы по Терабайту, то строго рекомендуется использовать журнализированную ФС. И кто вам сказал, что она "сырая"? Надо было хотя бы ознакомиться с возможностями и ограничениями различных ф/с перед тем, как терабайтный разделы пилить, а не рассуждать тут о том, что вот система какая плохая, я о неё нихрена не знаю, делаю абы чего, а она ещё работать отказывается, как я себе напридумывал. П.С: Господа пионеры, бросай привычку вякнуть абы чего, лишь бы голос подать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от odmin (ok) on 11-Мрт-08, 12:56
	Если у вас разделы по терабайту, то строго рекомендуется использовать нормальную ОС. Я правильно понял? :-D Потому как UFS2 якобы и больше поддерживает, но КАК? И в документации, кстати, ни слова про то, что оно будет fsck-аться 3 часа и что сам fsck будет валиться и жрать память как свинья помои. GJOURNAL только вышло из статуса беты, zfs ещё не вышло. Тот кто СЕЙЧАС использует FreeBSD по всем признакам пионер. А вовсе не те, кто ругает бзду...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от _Nick_ (??) on 11-Мрт-08, 13:09
	зачет :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Кирилл (??) on 11-Мрт-08, 14:31
	>зачет :) Нет, _Nick_, не зачёт. Пионер лепит херню. Так что слюни пускать не советую.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	46. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от _Nick_ (??) on 11-Мрт-08, 15:18
	>Нет, _Nick_, не зачёт. Пионер лепит херню. Так что слюни пускать не >советую. ну, слюна уже пущена :)) PS с сеня сам переползаю с JFS на ext4. Во де красота. И online resize (как в JFS), но и offline shrinking (чего ТАК не хватало в JFS), вагон рулей тюнинга, обратная совместимость с ext3 (пока на включишь новые фичи).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	55. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Михрютка on 11-Мрт-08, 16:31
	>PS с сеня сам переползаю с JFS на ext4. Во де красота. > >И online resize (как в JFS), но и offline shrinking (чего ТАК >не хватало >в JFS), вагон рулей тюнинга, обратная совместимость с ext3 (пока на включишь > >новые фичи). offline shrinking - это де опечатка? если online shrinking, то в jfs2 вполне себе есть
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	57. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от _Nick_ (ok) on 11-Мрт-08, 16:46
	>offline shrinking - это де опечатка? никаких опечаток. Хоть какой shrinking. Потому как в JFS Линуховом его нету ваще. >если online shrinking, то в jfs2 вполне себе есть хотя я и сам нагуглил, что в AIX в JFS2 есть shrinking. Но пасиба, я лучше пешком постою :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 13:21
	> будет 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.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от BayaN (ok) on 11-Мрт-08, 14:32
	>Тот кто СЕЙЧАС использует FreeBSD по всем признакам пионер. А вовсе не те, кто ругает бзду... Так, а зачем тогда ты её используешь? Используй Linux, лично меня в нём всё устраивает.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	45. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Кирилл (??) on 11-Мрт-08, 14:46
	>Так, а зачем тогда ты её используешь? Используй Linux, лично меня в >нём всё устраивает. А какие в линуксе есть встроенные механизмы защиты данных при нештатной перезагрузке? Я без иронии, просто не в курсе многих решений. И как Линукс обрабатывает терабайтные разделы с десятками миллионов файлов?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	48. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от _Nick_ (??) on 11-Мрт-08, 15:25
	>А какие в линуксе есть встроенные механизмы защиты данных при нештатной перезагрузке? >Я без иронии, просто не в курсе многих решений. журнал. если какой коммит не закончится полностью (что большая редкость, как ты понимаешь), то fsck пойдет полную проверку делать. Иначе (считай 99% сбоев) - просто откатит журнал. Секунды. >И как Линукс обрабатывает терабайтные разделы с десятками миллионов файлов? Да вот так же и обрабатывает :) Есть пара толстых стораджей с 4Тб рейдами. Ну, пара лет уже как, но ни разу полный чек не потребовалсо. Обычная ext3.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	53. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от andr.mobi (ok) on 11-Мрт-08, 15:55
	А почему журнал по-умолчанию отключен? Не потому ли, что он так тормозит работу ФС, что это можно терпеть только на столе? А файлы размером больше 4Гб ext поддерживает? Как давно? А лепить по 50 патчей в сутки, исправляющих кривизну "стабильных" релизов - это нормально? кернел.орг  - это кунсткамера анекдотов. Это моё IMHO, разумеется, IMHO человека, который юзает BSD с 1987 года (Demos из курчатовсксого - это клон БЗДи), и почитывал код из всех существующих клонов юникса. Я называю кернел.орг детским садом, клубом юных техников, а ребятишки вроде тебя переехали на африканскую убунту с маздая совсем недавно, а то, что ты пищешь, вычитали на своих ребяческих форумах. Завязывай блестеть памперсами, повзрослеешь - будет стыдно. Хотя БЗДя меня уже давно не устраивает во многих местах, это пока лучшее, что есть на стол и в стойку. Ещё бы вернулись бы к корням и подчерпнули бы побольше от План9 - цены бы им не было. Ну и с микроядерностью тоже хорошо бы подружится, меня USB-девайсы раз в неделю стабильно перезагружают.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	56. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от _Nick_ (ok) on 11-Мрт-08, 16:42
	>А почему журнал по-умолчанию отключен? >Не потому ли, что он так тормозит работу ФС, что это можно >терпеть только на столе? >А файлы размером больше 4Гб ext поддерживает? Как давно? # ls -l my_file -rw-r--r--  1 root root 1048577048576 Mar 11 05:40 my_file >А лепить по 50 патчей в сутки, исправляющих кривизну "стабильных" релизов - >это нормально? конечно ж нет. Поэтому этого и не просиходит :) >Хотя БЗДя меня уже давно не устраивает во многих местах, это пока >лучшее, что есть на стол и в стойку >.... >меня USB-девайсы раз в неделю стабильно перезагружают. no comments
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	68. "(offtopic) насчёт \m/"
	Сообщение от Michael Shigorin (ok) on 11-Мрт-08, 20:33
	>А почему журнал по-умолчанию отключен? Не потому ли, что он так тормозит работу ФС, >что это можно терпеть только на столе? Долго думали такую несусветную глупость сообразить?  Нешто будете мерять UFS2 против ext3, не говорю про xfs? >А файлы размером больше 4Гб ext поддерживает? Как давно? Проснитесь, Андрей, всячески предлагаю -- проснитесь. ext я вот десять лет тому уже не застал, а сейчас за окном -- ext3 и приближается ext4.  И то с xfs просто не помню, что такое "лимит на размер файла".  У меня таких стораджей-то нет. >А лепить по 50 патчей в сутки, исправляющих кривизну "стабильных" релизов - >это нормально? Да, это нормально: если кривизна обнаружена, то чем выше доступность исправлений, тем больше выбора у тех, кого она потенциально затрагивает. Вы хотите сказать, что нормально -- это сидеть на багах? >Это моё IMHO, разумеется, IMHO человека, который юзает BSD с 1987 года >(Demos из курчатовсксого - это клон БЗДи), и почитывал код из всех существующих >клонов юникса. Что, и Coherent зацепили?  Сколько раз объяснять -- старость порой приходит одна, не тем мерить стоит. >Я называю кернел.орг детским садом, клубом юных техников *sigh* Припоминая Ваше резюме -- боюсь, с ним и в такой детсад бы не приняли... >Завязывай блестеть памперсами, повзрослеешь - будет стыдно. Давайте на брудершафт это стикером к монитору? :) >Хотя БЗДя меня уже давно не устраивает во многих местах, это пока >лучшее, что есть на стол и в стойку. Ещё бы вернулись >бы к корням и подчерпнули бы побольше от План9 - цены >бы им не было. Ну и с микроядерностью тоже хорошо бы >подружится, меня USB-девайсы раз в неделю стабильно перезагружают. Офигеть. Ну что ж, пусть продолжает устраивать.  Другим-то работать надо.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	52. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от BayaN (ok) on 11-Мрт-08, 15:39
	Ну для начала в большинстве Linux'овых ФС есть журналирование. Во-вторых часть данных ты потеряешь в любом случае, и важно не это, а важно то, чтобы была согласованость между метаданными и непотеряными данными в ФС (тафталогия блин). Лично я знаю всего лишь три модели, позволяющие добиться этого, опробованые в промышленых масштабах: журналирование (ext3-4, xfs и т. д.), мягкие обновления (UFS2), COW (ZFS). У SoftUpdates есть два больших преимущества: простота реализации и высокая производительность, в идеале как при ассинхронной записи, но как выяснилось очень сложно реализовать fsck, т.к. надо прошуршать почти всю ФС. А fsck при журналировании пробегает лишь по относительно небольшому журналу и откатывает незавершённые действия, зато более сложная реализация и при каждой операции меняющей содержимое стабильного хранилища приходится синхронно писать лог в журнал. COW просто копирует данные при записи в другое место, а затем атомарно обновляет метаданные - отсюда сложность быстрой реализации, но ФС находится всегда в согласованом состоянии. Есть и ещё один метод - синхронная запись, но это жутко медленно. Короче, я не программист и не разработчик ФС, поэтому мои познания поверхностны и возможно неправильны. Если есть желание узнать об этих механизмах больше смотри книгу "Маршалл Кирк МакКузик FreBSD архитетура и реализация" и FreeBSD handbook - здесь достаточно доступно описано про SoftUpdates и причины использования именно этой технологии. Google поможет найти про журналирование и COW (смотри документацию по ZFS). Также, если интересно погляди про BLUFFS - реализация журналирования для UFS на уровне ФС, на одном из прошедших BSDCan была презентация этого проекта, вроде как обещают включить в FreeBSD 8. Для себя я решил, что если мне надо работать с большим хранилищем >2TB, то остаётся только два варианта, либо журналирование - Linux, либо COW - ZFS + Solaris. FreeBSD пока можно не рассматривать, т.к. у Soft Updates проблема с fsck, а ZFS+FreeBSD или FreeBSD + gjournal пока экспериментальные, хотя возможно к 7.1 или к 7.2 их уже можно будет считать достаточно стабильными. Собственно я выбрал Linux, т.к имею с ним опыт работы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	54. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 15:59
	> COW просто копирует данные при записи в другое место, а затем атомарно обновляет метаданные - отсюда сложность быстрой реализации, но ФС находится всегда в согласованом состоянии. COW в ZFS не копирует неизмененные блоки, а только меняет метаданные на измененные блоки. И производительность у ZFS страдает еще от подсчитывания checksum'ов на данные и метаданные, но все это только при записи, т.к. при чтении эта ФС быстрее чем UFS. > ZFS+FreeBSD или FreeBSD + gjournal пока экспериментальные, хотя возможно к 7.1 или к 7.2 ZFS скорее всего еще будет долго экспериментальной. По крайней мере пока не отладят проблемы  с памятью до автотюнинга (а не ручного) и не включат поддержку ACL. Но даже сейчас эту ФС уже можно использовать в продакшне (и используют), если руки не совсем кривые или задачи не слишком специфичные.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	58. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от BayaN (ok) on 11-Мрт-08, 17:41
	>COW в ZFS не копирует неизмененные блоки, а только меняет метаданные на >измененные блоки. И производительность у ZFS страдает еще от подсчитывания checksum'ов >на данные и метаданные, но все это только при записи, т.к. >при чтении эта ФС быстрее чем UFS. > Ну ещё бы она копировала то, что уже и так на диске. Чтение не составляет проблемы для сохранения данных, а скорость ZFS на чтении как мне видится больше обусловлена грамотным кэшированием.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	67. "(offtopic) storage"
	Сообщение от Michael Shigorin (ok) on 11-Мрт-08, 20:22
	>А какие в линуксе есть встроенные механизмы защиты данных при нештатной перезагрузке? Журнал, как обычно. >И как Линукс обрабатывает терабайтные разделы с десятками миллионов файлов? Нормально себе отрабатывает.  И многотерабайтные с непомнюсколькофайлов -- тоже.  Причём очень давно: в 2003 вовсю стораджи со специализированным дистрибутивом на базе ALT Linux с XFS и управлением томами разбирали :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Кирилл (??) on 11-Мрт-08, 14:34
	>Я правильно понял? :-D Не знаю. Видно, что с пониманием у тебя по жизни не лады.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 13:36
	>Есть хоть какие-то шансы, что во фре появится быстрая FS? Без этого >пусть хоть в 2 раза быстрее аллокатор будет, в реальной жизни >FreeBSD будет в аутсайдерах. реальная жизнь это не только PC-серверы, а еще и embedded хотя бы. Не везде нужна такая FS как zfs. >ZFS ещё совсем сырое и по дизайну мегатормозное. сравни версию во фре и в солярке. Но тормозит скорее всего у тебя интерфейс между стулом и компьютером. > UFS2+SU? нет, просто ufs2 на gmirror или gstripe. softupdates - это вообще отдельная "веселая" песня. > при количестве inode-ов в 40млн а зачем тебе столько inode'ов? язык чесать?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Юзеръ (ok) on 11-Мрт-08, 14:17
	>реальная жизнь это не только PC-серверы, а еще и embedded хотя бы. >Не везде нужна такая FS как zfs. Во-во.На этот случай нужна простая и легкая FS и желательно быстрая.UFS тут топор, EXT2\3 тоже топор, но хотя-бы с поплавком (для лучшего плавания по бурным рекам).Зато есть еще всякие JFS и XFS которые местами интересны.Для embedded есть всякие SquashFS, JFFS и т.п. файловые системы. >сравни версию во фре и в солярке. Но тормозит скорее всего у >тебя интерфейс между стулом и компьютером. Хороший ответ, ага.От этого у вопрошавшего все заработало лучше, добавилась поддержка новых ФС, и вообще солнышко стало ярче, травка зеленее ну и все такое... =) >> при количестве inode-ов в 40млн >а зачем тебе столько inode'ов? язык чесать? А вы давно на емкость современных HDD смотрели?Далеко не любой файл весит по 600 мегабайт, а?Ну в общем стандартные ответы из рубрики "свое ... не пахнет" :\
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 14:32
	>А вы давно на емкость современных HDD смотрели?Далеко не любой файл весит >по 600 мегабайт, а?Ну в общем стандартные ответы из рубрики "свое >... не пахнет" :\ Что ты будешь делать, если накроется журнал? Молиться на btrfs (ака vapourware от orcale'а)? для больших объемов есть FS с checksum'ами типа ZFS, HAMMER, NILFS, GPFS и тп. А вот JFS и XFS в пролете. Журналирование можно сделать и в VM, т.е. заюзать GJournal, и не использовать fsck. Но полагаться на журнал - это, конечно, плевать на все, кроме ребутов/зависаний. Если начнет глючить контроллер или драйвер, то как тебя твой журнал спасет?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	44. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 14:36
	>Журналирование можно сделать и в 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.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	47. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от _Nick_ (??) on 11-Мрт-08, 15:21
	>Если начнет глючить контроллер или драйвер, то как тебя >твой журнал спасет? када глючит железо - надо его менять, а не выбирать ФС "понадежнее". Винт может глюкнуть так, что больше не определится даже в биосе. Так что, нужно на журналирование забивать из-за этого?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	49. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 15:30
	>када глючит железо - надо его менять, а не выбирать ФС "понадежнее". железо не вечно и backup никто не отменял, однако добавить к этому еще и надежную фс как ZFS не помешает >Винт может глюкнуть так, что больше не определится даже в биосе. >Так что, нужно на журналирование забивать из-за этого? это наоборот, повезло, т.к. ты узнаешь, что данные испорчены и может заюзать backup. А что ты будешь делать с silent error? Как от этого тя спасет журнал? checksum'ы помогут восстановить копиую из резерва или пометить файл как содержащий ошибку.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	50. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от _Nick_ (??) on 11-Мрт-08, 15:32
	нет предела наворотам :) За сим и смотрю на ext4
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	51. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 15:33
	>железо не вечно и backup никто не отменял, однако добавить к этому >еще и надежную фс как ZFS не помешает речь о комплексной политике обеспечения надежности. Полагаться на один журнал, на один raid-контроллер или на одни checksum'ы - портить себе нервы. К тому же в ZFS _есть_ журнал, помимо checksum'ов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	59. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от odmin (ok) on 11-Мрт-08, 17:47
	Бред. А ОЗУ заглючит или винт начнет вылетать, никакое ZFS не спасёт. Тогда смысл?! Кстати, GJOURNAL, по инфе с freebsd-stable@ - полная лажа, т.к. работает на уровне блочных устройств. Соответственно, оно даже не знает с чем в данный момент работает, с метаданными или с данными. Скорость соответствует... Короче, тупой и уродливый хак. Чисто чтобы можно было сказать - "оу, май ниггаз, у нас тоже есть журналируемая ФС".... Её, кстати, в качестве проекта summer of code наклепал наш соотечественник. Молодец, конечно, но, блин, сравнивать эту кривоту с вылизанной годами ext3..... клиника!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	62. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от ZANSWER (??) on 11-Мрт-08, 18:18
	> А ОЗУ заглючит или винт начнет вылетать, никакое ZFS не спасёт. Тогда смысл?! В ZFS есть IO checksum, кроме block checksum, так что глюки памяти и винта таки в ней не страшны для данных...;) > Молодец, конечно, но, блин, сравнивать эту кривоту с вылизанной годами ext3..... клиника! Это та в которой месяцев 5-6 назад нашли такую ошибку, при которой терялись данные, просто на ровном месте, что аж сам Линус с горящим красным взором лично ошибку искал и исправлял, да, мега стабильность, вылизанная годами...*THUMBS UP*
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	63. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от _Nick_ (ok) on 11-Мрт-08, 18:26
	>Это та в которой месяцев 5-6 назад нашли такую ошибку, при которой >терялись данные, просто на ровном месте, что аж сам Линус с >горящим красным взором лично ошибку искал и исправлял, да, мега стабильность, >вылизанная годами...*THUMBS UP* что ты запоешь, когда в ZFS начнут находить проблемы?? съежжать на наличие ошибок так же тупо как утверждать что в чем-то достаточно большом и сложном их нет
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	64. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от ZANSWER (??) on 11-Мрт-08, 18:33
	> что ты запоешь, когда в ZFS начнут находить проблемы?? Думаю, что убью себя...:-D > съежжать на наличие ошибок так же тупо как утверждать что в чем-то достаточно большом и сложном их нет Nick, дык разве я протестую, конечно они есть и в ZFS, просто тут один Одмин расказывал про мега стабильность, и безглючность ext3, как спасения всех, и всего, вот и вспомнилось, ну чтобы всё по чесно было, вот мы с Тобой поняли друг-друга, и не будем расказывать сказки, про то, что ext3 или ZFS, rock solid, а все остальные говно...;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	65. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от _Nick_ (ok) on 11-Мрт-08, 18:39
	>Nick, дык разве я протестую, конечно они есть и в ZFS, просто >тут один Одмин расказывал про мега стабильность, и безглючность ext3, как >спасения всех, и всего, вот и вспомнилось, ну чтобы всё по >чесно было, вот мы с Тобой поняли друг-друга, и не будем >расказывать сказки, про то, что ext3 или ZFS, rock solid, а >все остальные говно...;) ну вот :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	71. "(offtopic) ZFS"
	Сообщение от Michael Shigorin (ok) on 11-Мрт-08, 20:42
	>> что ты запоешь, когда в ZFS начнут находить проблемы?? >Думаю, что убью себя...:-D Не делайте этого, пожалуйста :] http://www.datacenterknowledge.com/archives/2008/Jan/16/joye... (это в ZFS, но не на фре, а в предельно родном окружении -- opensolaris/sparc)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	81. "(offtopic) ZFS"
	Сообщение от ZANSWER (??) on 12-Мрт-08, 07:52
	> Не делайте этого, пожалуйста :] http://www.datacenterknowledge.com/archives/2008/Jan/16/joye... (это в ZFS, но не на фре, а в предельно родном окружении -- opensolaris/sparc) Michael Shigorin, баги есть везде и всегда, я во второй части поста с этим согласился, а так, спасибо за ссылку, прочёл, правда инфы очень мало, что конкретно случилось, не ясно толком, но в любом случае это лишь доказало в очередной раз, что везде есть ощибки...:)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	86. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Кирилл (??) on 12-Мрт-08, 10:16
	>что ты запоешь, когда в ZFS начнут находить проблемы?? _Nick_, вряд ли в ZFS найдут критические ошибки. Всё таки это основная продакшэн ф/с для самых различных по масштабу систем от Sun.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	88. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от _Nick_ (??) on 12-Мрт-08, 18:22
	>_Nick_, вряд ли в ZFS найдут критические ошибки. Всё таки это основная >продакшэн ф/с для самых различных по масштабу систем от Sun. вряд ли в ext3 будут проблемы, это же, все-таки, основная система для всех Линух систем во всем мире. Но проблемы то нашлись... ;) делай выводы и не говори ерунды.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	90. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от ZANSWER (??) on 12-Мрт-08, 20:25
	> _Nick_, вряд ли в ZFS найдут критические ошибки. Всё таки это основная продакшэн ф/с для самых различных по масштабу систем от Sun. Что-то Вы Кирилл не туда совсем, нет я понимаю, я вот жертва SUN-овских маркетологов, но Вы то чего, ошибки есть везде, даже в ZFS, хоть так этого не хотелось бы, но всё же, Михаил Шигорин давал ссылку, я даже всё прочёл, хотя ситуация была не настолько страшная, так как там использовалась OpenSolaris Nevada build 49, согласитесь это несколько устаревшая _не продакшен_ версия, ну енто не суть важно, баг в ZFS таки там был ими найден, а значит она тоже не безгрешна, хотя такой баг проявился только в SUN Fire X4500 на громадном массиве, который имеет не каждый, но то что баг исправили это хорошо, а ещё лучьше то, что он проявился на OpenSolaris, а не на продакшен левел системе Solaris 10...:)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	79. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от odmin (ok) on 12-Мрт-08, 05:59
	И как поможет IO checksum?! ОЗУ или винт начали мусор гнать, zfs увидело ошибку, возможно исправило (с битой-то памятью, ну ну). Дальше что? Куда это всё денется? Запишется на умирающий винт? И что получится? По-моему, такие фичи должны быть намного более интеллектуальными. Начал модуль ОЗУ ошибки выдавать, ОС его отключила (в linux, емнип, есть возможность на лету отключать участки памяти), начал винт умирать, ОС его из RAID САМА выдернула, живую инфу слила. В такой системе ZFS бы пригодился... А просто тупо checksum-ы считать - бесполезная ерунда...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	80. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от ZANSWER (??) on 12-Мрт-08, 07:49
	> И как поможет IO checksum?! ОЗУ или винт начали мусор гнать, zfs увидело ошибку, возможно исправило (с битой-то памятью, ну ну). Дальше что? Куда это всё денется? Запишется на умирающий винт? И что получится? Запись не будет продолжаться, сюрприз??;) > По-моему, такие фичи должны быть намного более интеллектуальными. Начал модуль ОЗУ ошибки выдавать, ОС его отключила (в linux, емнип, есть возможность на лету отключать участки памяти), начал винт умирать, ОС его из RAID САМА выдернула, живую инфу слила. В такой системе ZFS бы пригодился... А просто тупо checksum-ы считать - бесполезная ерунда... Так вот в Solaris 10 так и происходит, есно на их серверах, ZFS тесно связана с FMA, что такое FMA в Solaris 10 сам найдёшь, и как оно всё взаимодействует, соотвественно падающий винт будет отключен от массива, а пулл будет переведён в состояние DEGRADED, а Администратор будет уведамлён о таком не приятном событии, есно, что можно будет продолжать работать с отставшейся частью пула, либо, если есть диски в hot spare режиме, то система заменит битый винт, винтом который отдан для hot spare, на автомате, посему ZFS и разработана для того, чтобы быть комплексным решением, по защите от повреждения данных и тесно взаимосвязана с остальной частью системы в Solaris 10...:)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	74. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от nuclight (ok) on 11-Мрт-08, 22:21
	>Бред. А ОЗУ заглючит или винт начнет вылетать, никакое ZFS не спасёт. >Тогда смысл?! > >Кстати, GJOURNAL, по инфе с freebsd-stable@ - полная лажа, т.к. работает на >уровне блочных устройств. Соответственно, оно даже не знает с чем в >данный момент работает, с метаданными или с данными. Скорость соответствует... Короче, >тупой и уродливый хак. Чисто чтобы можно было сказать - "оу, >май ниггаз, у нас тоже есть журналируемая ФС".... Её, кстати, в >качестве проекта summer of code наклепал наш соотечественник. Молодец, конечно, но, >блин, сравнивать эту кривоту с вылизанной годами ext3..... клиника! Точно тролль. И дезинформатор, хоть бы почитать что потрудился. Gjournal использует хуки в коде FS, чтоб знать, когда сохраняются метаданные. Скорость по тестам у него иногда даже опережала SoftUpdates. И не тупой хак, а изящное решение, позволяющее добавить полное журналирование данных к любой FS c неслишком сильными изменениями. И я бы не стал называть поляка соотечественником. Да и что касается вылизанной годами ext3 - расскажите это сотрудникам датацентров, у которых она после нескольких месяцев работы при проверке fsck находила ошибки, несмотря на хваленый журнал (тут впору вспомнить о счетчике монтирований и дней без проверки - видимо, эти хаки вставлены не зря)...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	78. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от odmin (ok) on 12-Мрт-08, 05:52
	Я больше доверяю инфе с freebsd-stable@, чем анонимным аналитикам с опеннета. В рассылке было сказано, возможно даже самим Voras-ом, что оно поэтому и может быть добавлено к любой FS, что НИЧЕГО ПРО ФС НЕ ЗНАЕТ, т.к. работает на уровне блочных устройств. Но об эффективности с таким подходом можно забыть! И что она быстрее UFS+SU только очень хитрых условиях! Сам разработчик написал что-то навроде "interesting feature". Сам подумай, если оно ВСЁ ЖУРНАЛИРУЕТ, как оно может быть быстрым?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	83. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от nuclight (ok) on 12-Мрт-08, 09:12
	>Я больше доверяю инфе с freebsd-stable@, чем анонимным аналитикам с опеннета. В >рассылке было сказано, возможно даже самим Voras-ом, что оно поэтому и >может быть добавлено к любой FS, что НИЧЕГО ПРО ФС НЕ >ЗНАЕТ, т.к. работает на уровне блочных устройств. Но об эффективности с >таким подходом можно забыть! > >И что она быстрее UFS+SU только очень хитрых условиях! Сам разработчик написал >что-то навроде "interesting feature". Сам подумай, если оно ВСЁ ЖУРНАЛИРУЕТ, как >оно может быть быстрым? Вот ты и есть анонимный аналитик, а я не только рассылки читаю, но и код пишу. Так что ты мне не свои досужие вымыслы давай, а ССЫЛКУ, где Voras именно такое и заявил.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	85. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Кирилл (??) on 12-Мрт-08, 10:13
	>> када глючит железо - надо его менять, а не выбирать ФС "понадежнее". Знать бы когда оно решит глючить. ZFS в этом плане очень удобное решение.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	69. "(offtopic) 'если начнёт глючить'"
	Сообщение от Michael Shigorin (ok) on 11-Мрт-08, 20:39
	>Если начнет глючить контроллер или драйвер, то как тебя твой журнал спасет? Так, для справки: замечено, что при битой (разогнанной, перегретой...) памяти у людей xfs отваливало систему в ro с внятной руганью в лог. Про развал журнала пока только слышал, но "не фонтан".  Самому сталкиваться не доводилось. Кажется, там рейд с батарейкой суппорт радостно дёргал по питанию (то ли на агаве, то ли на мастерхосте).
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	73. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от nuclight (ok) on 11-Мрт-08, 22:11
	>>> при количестве inode-ов в 40млн >>а зачем тебе столько inode'ов? язык чесать? > >А вы давно на емкость современных HDD смотрели?Далеко не любой файл весит >по 600 мегабайт, а?Ну в общем стандартные ответы из рубрики "свое >... не пахнет" :\ А причем тут емкость HDD, а? покажите мне df -i хоть с одной промышленной системы, где есть разделы с более чем миллионом файлов.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	75. "df -i"
	Сообщение от Michael Shigorin (ok) on 11-Мрт-08, 23:14
	>покажите мне df -i хоть с одной промышленной системы, >где есть разделы с более чем миллионом файлов. До кластера отсюда не дотянуться :), а из того, что поближе -- /dev/mdN       xfs      890M    986K    889M    1% ~ftp /dev/mdK       xfs      110M    324K    109M    1% ~ftp/pub/Linux/ALT
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	82. "df -i"
	Сообщение от nuclight (ok) on 12-Мрт-08, 09:06
	>>покажите мне df -i хоть с одной промышленной системы, >>где есть разделы с более чем миллионом файлов. > >До кластера отсюда не дотянуться :), а из того, что поближе -- > > >/dev/mdN       xfs      890M    986K    889M    1% ~ftp >/dev/mdK       xfs     110M    324K    109M   1% ~ftp/pub/Linux/ALT Ну и? Оба раздела не превышают даже ОДНОГО миллиона. Тогда как в исходном посте говорилось про 40.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	76. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от fedya (??) on 12-Мрт-08, 02:20
	> А причем тут емкость 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
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	84. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от nuclight (ok) on 12-Мрт-08, 09:13
	>[оверквотинг удален] > > [root@lxwdc1 ~]# df -ih > Filesystem           > Inodes   IUsed   IFree IUse% Mounted on > > [...] > /dev/mapper/VolGroup01-LogVol00 >             >           > 2.5G    129M    2.4G  6% /mnt/aoe1 Хм. А что у вас там лежит, на такое количество файлов? И какая вложенность каталогов?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	92. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от fedya (??) on 12-Мрт-08, 22:08
	>> 2.5G    129M    2.4G  6% /mnt/aoe1 >Хм. А что у вас там лежит, на такое количество файлов? И какая вложенность каталогов? Это e-discovery NAS. http://en.wikipedia.org/wiki/Data_processing_architecture_fo...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	93. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от nuclight (ok) on 13-Мрт-08, 09:25
	>>> 2.5G    129M    2.4G  6% /mnt/aoe1 >>Хм. А что у вас там лежит, на такое количество файлов? И какая вложенность каталогов? > >Это e-discovery NAS. > >http://en.wikipedia.org/wiki/Data_processing_architecture_fo... А, ну так NAS/SAN нередко имеют собственную FS, железка может даже не иметь на себе опенсорсную ось.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	60. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от fedya (??) on 11-Мрт-08, 17:59
	> Вчера вычитал в рассылке freebsd-stable@ Дайте, пожалуйста, ссылку... > Для проверки террабайтной UFS2 fsck надо гиг ОЗУ, причём в kernelspace, соответственно, > надо /boot/loader.conf править и перегружаться. Это странно, fsck работает в userspace и использует своп если ей надо.  fsck *может* потребоватся гиг виртуальной памяти на терабайт диска, но это не обязательно, зависит от параметров файловой системы.  См. http://groups.google.com/group/lucky.freebsd.fs/browse_threa... Для сравнения, полная проверка 15T xfs c дефолтными настройками на CentOS 4.5 у меня заняла 26 часов и 18 гиг памяти. XFS, кстати, не поддерживает бэкграунд чекинг.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	77. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Wulf (ok) on 12-Мрт-08, 02:29
	>> Вчера вычитал в рассылке freebsd-stable@ >Дайте, пожалуйста, ссылку... Вероятне всего, имеется ввиду следующий тред: http://groups.google.com/group/lucky.freebsd.stable/browse_t... Кстати, "матерый бздун 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 не особо влияют. Как резюме, можно посоветовать гражданину Одмину учить английский вместо олбанского, может тогда хоть смысл текста начнет понимать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	66. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от nuclight (ok) on 11-Мрт-08, 19:50
	Не, а кто чуваку виноват, что он отформатировал такой большой раздел с дефолтными параметрами. У людей вон есть UFS2 на 6 терабайт нормально отформатированная есть, и ничего, fsck работает. Что предложили вытащить - а что еще советовать чуваку, если он уже в ситуацию попал? Убиться об стену? Неконструктивно. >ZFS ещё совсем сырое и по дизайну мегатормозное. GJOURNAL ещё сырое. Ага, все умрем. Не все так печально. ZFS считается экспериментальной, и кстати довольно быстрой. И для экспериментальной FS у нее весьма высокая надежность. Плюс - класс задач - терабайты не везде нужны пока. У меня вот 300-гиговый раздел на UFS2+SU проверяется за считанные секунды.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от sauron (??) on 10-Мрт-08, 20:10

О том что аллокатор памяти в libc фиговат для потоковых приложений известно давно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	72. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Michael Shigorin (ok) on 11-Мрт-08, 20:50
	>О том что аллокатор памяти в libc фиговат для потоковых приложений известно давно. Да он и вообще до недавних пор (e.g. в glibc-2.5) был не сильно-то адекватен текущему положению дел в linux-2.6 :(
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от BayaN (ok) on 10-Мрт-08, 20:21

>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 для интереса.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 10-Мрт-08, 23:10
	>>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)...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 10-Мрт-08, 20:23

SLAB ili SLUB bil v fedore ?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 12:16
	>SLAB ili SLUB bil v fedore ? SLUB
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от terminus (ok) on 10-Мрт-08, 20:32

Диллон только обещает. Весь kerneltrap.org исписал, писатель... Посмотрим что он там со своим Hammer сделает.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "OpenNews: Тестирование производительности аллокаторов памяти..."

Сообщение от _Nick_ (ok) on 10-Мрт-08, 21:25

нечесный тест. Берет Бздю в карренте - брал бы и 2.6.25-rc4/5 ядро. А так - очередной бойан

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "OpenNews: Тестирование производительности аллокаторов памяти..."
	Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Мрт-08, 21:32
	Это на Опеннет ее очередная опечатка: "The following graph compares FreeBSD 7.0 and Linux 2.6.24+glibc 2.7"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "OpenNews: Тестирование производительности аллокаторов памяти..."
	Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Мрт-08, 21:43
	>Это на Опеннет ее очередная опечатка: А это уже моя опечатка:))). Конечно, "на Опеннете очередная" :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "OpenNews: Тестирование производительности аллокаторов памяти..."
	Сообщение от _Nick_ (ok) on 10-Мрт-08, 22:01
	да ты хоть по ссылке сходи. Первый де график - FBSD-8.0 и Fedora с 2.6.24 бойан
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "OpenNews: Тестирование производительности аллокаторов памяти..."
	Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Мрт-08, 22:08
	>да ты хоть по ссылке сходи. >Первый де график - FBSD-8.0 и Fedora с 2.6.24 > >бойан Ыыы, просто само тестирование меня самой своей идеей не впечатлило, изучать не стал. :( Впрочем, если я не ошибаюсь, там действительно аллокаторы одинаковые...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "OpenNews: Тестирование производительности аллокаторов памяти..."
	Сообщение от Аноним (??) on 10-Мрт-08, 21:50
	>Это на Опеннет ее очередная опечатка: > >"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"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 10-Мрт-08, 21:29

Нравится тенденция тестирования DragonflyBSD вместе с другими системами. По всем тестам она сливает просто катастрофично. Надеюсь, Диллон одумается и закроет проект, а полезные наработки типа hammer и vkernel перенесет на FreeBSD CURRENT. Ибо DF чуть менее, чем полностью бесполезная трата времени разработчивов. PS. Еще умиляют местные защитники DFBSD, которые сами ее не используют :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от PereresusNeVlezaetBuggy (ok) on 10-Мрт-08, 21:41
	>Нравится тенденция тестирования DragonflyBSD вместе с другими системами. По всем тестам она >сливает просто катастрофично. Надеюсь, Диллон одумается и закроет проект, а полезные >наработки типа hammer и vkernel перенесет на FreeBSD CURRENT. Ибо DF >чуть менее, чем полностью бесполезная трата времени разработчивов. PS. Еще умиляют >местные защитники DFBSD, которые сами ее не используют :) Блин, ну вам-то лично чем эта ОС мешает?! Я её тоже не использовал напрямую, но при этом я пользуюсь мелкими и не очень наработками, которые приходят именно из этой ОС. И то, что они приходят именно из DragonFly BSD говорит о том, что именно организация разработки этой ОС лучше всего подходит для появления данных конструкций (драйверов, например). И не надо говорить, что разработчики DragonFly BSD лучше бы пригодились в других проектах. Во-первых, если бы им лучше работалось в других проектах, то они работали бы в других проектах, а там, где им лучше работается, там и результаты лучше (поскольку ОС открытая, то польза, опять же, всем - см. выше). А во-вторых, вы предпочитаете конкуренцию или моно-/олигополию? Если честно, я снимаю шляпу перед разработчиками DFBSD, что они взялись за этот проект, когда рынок, казалось, уже давно был поделен. Ну а насчёт того, что 4.x устарело - надоело, чесслово. Если для вас важнее то, что появилось только в 5.x/6.x/7.x - то пользуйтесь, пожалуйста, никто вам не мешает! Но, пардон, обсирать-то других зачем?! Глупо выглядит, а вовсе не понтово.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 10-Мрт-08, 23:36

кста, кто-нить нашел его комментарии по тестам жабы: http://people.freebsd.org/~kris/scaling/specjava.png http://people.freebsd.org/~kris/scaling/specjbb2005.png а? или это недоделанный бенчмарк?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 11-Мрт-08, 08:16

После тестов SMP нет доверия к этому товарищу.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от terminus (ok) on 11-Мрт-08, 10:52
	>После тестов SMP нет доверия к этому товарищу. Nick Piggin гонял недавно на ванильном 2.6.25-rc4, а Kriss тогда еще гонял на 2.6.23. При чем тут доверие, просто те тесты MySQL устарели... А вообще прикольно наблюдать за этими товарищами. Ждем ответ от Nick Piggin =)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 12:13
	Да я это именно из-за 2.6.22. Результаты тут http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/ очень отличаются от результатов Криса.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Аноним (??) on 11-Мрт-08, 13:42
	> А вообще прикольно наблюдать за этими товарищами. Ждем ответ от Nick Piggin =) А бенчмарки без политики не бывают. ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от fsck (??) on 12-Мрт-08, 10:34

да уж линух помниться знакомым занимающимся железом притянули винт который толи начал сыпаться толи еще что то но линухоид с ним ничего сделать несмог я при этом присутсвовал(когда принесли и обясняли проблему) хардовики протестили и сказали проблемы с винтом нет эт где то на уровне операционки ну линуха под рукой небыло запустил bsd 4 прочекал ее bsd шным fsck она там все пофиксила винт вернули линухоиду...... он аж плакал - поскольку там был биллинг и вся статистика за несколько лет по клиентам вот а вы кричите линух линух....

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	89. "Тестирование производительности аллокаторов памяти FreeBSD и..."
	Сообщение от Анонимускун on 12-Мрт-08, 18:27
	кто ж знал, что ты такой идиот и будешь использовать fsck_ufs или fsck_ffs вместо fsck.ext2 или fsck.ext3 (из комплекта sysutils/e2fsprogs) ССЗБ!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Сообщение от Аноним (??) on 12-Мрт-08, 21:35

если бы небыл идиотом то понял бы что так и было или мне каждому идиоту разжопывать и в рот пихать?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]