Проект OpenSAF (http://www.opensaf.org) анонсировал (http://www.opensaf.org/news/AnnounceShow.asp?announcement_id...) новую версию открытой системы высокой готовности для сетевой подсистемы дистрибутивов, отвечающих требованиям спецификаций Carrier Grade Linux (http://www.linuxfoundation.org/en/Carrier_Grade_Linux) (CGL). В OpenSAF 3.0 добавлено множество инструментов управления платформой, улучшены ее пользовательские качества, а также включена поддержка программных интерфейсов языка Java.Наиболее важные нововведения OpenSAF 3.0:
- Более полная поддержка текущей спецификации SAF для систем высокой готовности, включающая специальную программную среду управления доступностью (Availability Management Framework, AMF).
- Новый сервис управления информационными моделями (Information Model Management, IMM) позволяет стандартизировать как работу с приложениями, так и саму OpenSAF.
- Новая система оповещения (NTF) стандартизирует процесс обработки системных сообще...URL: http://www.linuxdevices.com/news/NS9476492780.html?kc=rss
Новость: http://www.opennet.me/opennews/art.shtml?num=22196
Я има паражаюся... системный вызов iowait ещё не доделан, а они болтают о какой-то HA и Carrier Gradedd if=/dev/zero of=BIGFAILO count=1024k bs=8192 - и курит ваша HA 2 минуты...
Да, ядра 2.6 в отличии от 2.4 тупят не по-детски при интенсивных обращениях к диску. И читал об этом и сам заметил как пересел на линукс. Причем разработчики ядра так еще и не разобрались в чем там дело, насколько я понял.
>Да, ядра 2.6 в отличии от 2.4 тупят не по-детски при интенсивных обращениях к диску.
>И читал об этом и сам заметил как пересел на линукс. Причем разработчики ядра так еще
>и не разобрались в чем там дело, насколько я понял.Что-то ни разу не заметил. Ни на серверных системах, с которыми работал,
ни даже на домашнем компе.Недавний живой опыт - менял в домашнем компе два диска по 80 и 160 Гбайт
на собранную в софтверный RAID1 пару дисков по 640 Гбайт. Подключил к новой
пустой системе старый диск на 160 Гбайт, переливал с него данные обычным
копированием. Параллельно лазал в интернете и работал с клиентом Lotus
Domino 8.5 (корпоративная почта).Средняя скорость копирования была порядка 50 Мбайт/сек, каких-то заметных
"тормозов" заметно не было.ОС Debian/GNU Linux 5.0 (Lenny), 32-битная сборка
CPU AMD Athlon X2
RAM 4GB
HDD, как выше писал, 2 x 640 GB SATA + Linux MD RAID
а я вот очень замечал, когда переливал инфу с одного винта на другой или когда что-то делаешь, что сильно грузит винт. Попробуй сделать то,что предложил pavlinux в первом коменте.В инете кстати полно инфы на эту тему:
http://bugzilla.kernel.org/show_bug.cgi?id=12309#c360
Bug 12309 - Large I/O operations result in slow performance and high iowait times
>>Да, ядра 2.6 в отличии от 2.4 тупят не по-детски при интенсивных обращениях к диску.
>Что-то ни разу не заметил.А ты попробуй,
# dd if=/dev/zero of=BIGFILE bs=1M count=50000после 4 Gb иль примерно 20...25 сек. подвигай мышом, окошки по открывай-закрывай, сворачивай-разворачивай, в консольке что-то типа
# cat /var/log/messages | sort -r | sort -u | tr [:lower:] [:upper:] | sort -n
...
у меня еще так ниче, у некоторых читал еле в консоли команды набираются, интерсно от чего это зависит?
dd if=/dev/zero of=BIGFILE bs=1M count=50000
^C3276+0 записей считано
3276+0 записей написано
скопировано 3435134976 байт (3,4 GB), 63,3317 c, 54,2 MB/cто есть скорость записи достаточно и у меня достаточно большая, только вот wait в top достигает 70-85%, жрет процессор не по-детски...
>dd if=/dev/zero of=BIGFILE bs=1M count=50000
>^C3276+0 записей считано
>3276+0 записей написано
>скопировано 3435134976 байт (3,4 GB), 63,3317 c, 54,2 MB/c
>
>то есть скорость записи достаточно и у меня достаточно большая, только вот
>wait в top достигает 70-85%, жрет процессор не по-детски...IOWAIT - время ожидания ввода-вывода. Если система реально выполняет ввод-вывод
и одновременно нет существенной процессорной нагрузки, будет виден большой IOWAIT.
Это вполне нормально.
да, но тормоза все-таки присутствуют и у достаточно многих людей и ошибку эту пытаются найти и исправить и пока еще безуспешно...
и кроме 80% wait и загрузка проца очень приличная и система в некоторые моменты притормаживает. Ни в FreeBSD, ни даже в винде такого не видел. И до определенной версии ядра в ветке 2.6 тоже как пишут все было нормально.
>[оверквотинг удален]
>>Что-то ни разу не заметил.
>
>А ты попробуй,
># dd if=/dev/zero of=BIGFILE bs=1M count=50000
>
>после 4 Gb иль примерно 20...25 сек. подвигай мышом, окошки по открывай-закрывай,
>сворачивай-разворачивай, в консольке что-то типа
># cat /var/log/messages | sort -r | sort -u | tr [:lower:]
>[:upper:] | sort -n
>...Вот такое без особых тормозов:
$ dd if=/dev/zero of=BIGFILE bs=1M count=50000
^C7733+0 записей считано
7733+0 записей написано
скопировано 8108638208 байт (8,1 GB), 133,564 c, 60,7 MB/c$ ls -lh BIGFILE
-rw-r--r-- 1 zinal zinal 7,6G Июн 19 16:58 BIGFILE
$
>Вот такое без особых тормозов:Не верю! (с)
Вся планета в глубокой деспресии, а тут, опеннете оказывается не тормозит....А можете скомпилять вот эту утиль, (там внизу код) - http://lkml.org/lkml/2009/3/24/227
и запустить# dd if=/dev/zero of=BIGFILE bs=1M count=50000 & ./fsync-tester
Интересно от чего же зависят эти тормоза?
Насколько я понимаю, наблюдают эти тормоза далеко не все.
винты P-ATA или S-ATA?
>винты P-ATA или S-ATA?А пофигу, даже SAS и UltraSCSI 320 на 15000 rpm тормозит....
так вызовы записи данных идут из СУБД, а HA для СУБД реализуется именно самой СУБД, а не другими уровнями.HA & CG - делают приложения отказоустойчивыми. Хотя для java есть JavaEE (апп-сервера). интересно сравнить что предлагает HA и Carrier Grade против JavaEE.
:) запасаемся попкорном.