| 1.1, pavlinux (ok), 02:50, 19/06/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Я има паражаюся... системный вызов iowait ещё не доделан, а они болтают о какой-то HA и Carrier Grade
dd if=/dev/zero of=BIGFAILO count=1024k bs=8192 - и курит ваша HA 2 минуты...
| | |
| |
| 2.2, aurved (?), 09:59, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
Да, ядра 2.6 в отличии от 2.4 тупят не по-детски при интенсивных обращениях к диску. И читал об этом и сам заметил как пересел на линукс. Причем разработчики ядра так еще и не разобрались в чем там дело, насколько я понял.
| | |
| |
| 3.3, DeadMustdie (??), 11:07, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
 >Да, ядра 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
| | |
| |
| 4.5, aurved (?), 12:00, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– | |
а я вот очень замечал, когда переливал инфу с одного винта на другой или когда что-то делаешь, что сильно грузит винт. Попробуй сделать то,что предложил 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
| | |
| 4.9, pavlinux (ok), 13:06, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>Да, ядра 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
...
| | |
| |
| 5.10, aurved (?), 15:42, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
у меня еще так ниче, у некоторых читал еле в консоли команды набираются, интерсно от чего это зависит?
| | |
| |
| 6.14, aurved (?), 23:44, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
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%, жрет процессор не по-детски...
| | |
| |
| 7.15, DeadMustdie (??), 00:53, 20/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>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.
Это вполне нормально.
| | |
| |
| 8.16, aurved (?), 12:20, 20/06/2009 [^] [^^] [^^^] [ответить] | +/– | да, но тормоза все-таки присутствуют и у достаточно многих людей и ошибку эту пы... текст свёрнут, показать | | |
| 8.17, aurved (?), 12:28, 20/06/2009 [^] [^^] [^^^] [ответить] | +/– | и кроме 80 wait и загрузка проца очень приличная и система в некоторые моменты ... текст свёрнут, показать | | |
|
|
|
| 5.11, DeadMustdie (??), 16:59, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>>Что-то ни разу не заметил.
>
>А ты попробуй,
># 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
$
| | |
| |
| 6.12, pavlinux (ok), 23:07, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Вот такое без особых тормозов:
Не верю! (с)
Вся планета в глубокой деспресии, а тут, опеннете оказывается не тормозит....
А можете скомпилять вот эту утиль, (там внизу код) - http://lkml.org/lkml/2009/3/24/227
и запустить
# dd if=/dev/zero of=BIGFILE bs=1M count=50000 & ./fsync-tester
| | |
| 6.13, aurved (?), 23:38, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– |
Интересно от чего же зависят эти тормоза?
Насколько я понимаю, наблюдают эти тормоза далеко не все.
| | |
|
|
|
| |
| 4.8, pavlinux (ok), 12:56, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>винты P-ATA или S-ATA?
А пофигу, даже SAS и UltraSCSI 320 на 15000 rpm тормозит....
| | |
|
|
| 2.6, uZver (??), 12:16, 19/06/2009 [^] [^^] [^^^] [ответить]
| +/– | |
так вызовы записи данных идут из СУБД, а HA для СУБД реализуется именно самой СУБД, а не другими уровнями.
HA & CG - делают приложения отказоустойчивыми. Хотя для java есть JavaEE (апп-сервера). интересно сравнить что предлагает HA и Carrier Grade против JavaEE.
:) запасаемся попкорном.
| | |
|
|
