Comments 29
прим. Ком. На последнем абзаце сломал мозг :)
Если речь идёт просто FS+MySQL, то UFS вроде не самая быстрая FS, тут надо бы сравнивать ещё с EXT4, XFS.
В другом случае ответ многих — ZFS :)
В другом случае ответ многих — ZFS :)
речь идет о ZFS+MySQL :) В сравнении с первой попавшейся традиционной FS. Ну и главная ценность статьи, на мой взгляд в достаточно популярном изложении граблей.
И с UFS2 из FreeBSD тоже неплохо было бы сравнить (habrahabr на FreeBSD).
планирую погонять на FreeBSD 8 ZFS и UFS2. Правда пока не знаю чем тестировать. sql-bench точно прогоню.
Если возьметесь, то было б интересно сравнить и зависимость от битности: x86 vs x86_64
Вот, к сожалению это сильно гиморно, сравнивать их между собой.
Но amd64 я потестировал
habrahabr.ru/blogs/mysql/78895/
Но amd64 я потестировал
habrahabr.ru/blogs/mysql/78895/
попробовал:
habrahabr.ru/blogs/mysql/78895/
habrahabr.ru/blogs/mysql/78895/
Вообще говоря, на производительность и сравнение очень сильно влияет физика накопителей и шины.
UFO just landed and posted this here
The real reason for the good performance on this benchmark is not clear — indeed, every workload will be different — but the ZFS I/O scheduler, the Sun engineers paying attention to database performance, and the ZFS bug fixes contributed in recent (late 2007) releases of Open Solaris seem to be adding up to something good.
Более менее дословно:
Что улучшает производительность не очень понятно — естестенно, каждый случай уникальный — но ZFS I/O scheduler, при разработке которого инженеры SUN учитывали его влияние на базы данных, и ZFS багфиксы, которые добавлены в недавний (конец 2007) релиз Open Solaris похоже добавляют что-то хорошее [к производительности].
Более менее дословно:
Что улучшает производительность не очень понятно — естестенно, каждый случай уникальный — но ZFS I/O scheduler, при разработке которого инженеры SUN учитывали его влияние на базы данных, и ZFS багфиксы, которые добавлены в недавний (конец 2007) релиз Open Solaris похоже добавляют что-то хорошее [к производительности].
ZFS I/O scheduler has been shown to make a big difference in performance.
Я так понял:
ZFS I/O scheduler продемонстрирован как сильно влияющий на производительность.
Я так понял:
ZFS I/O scheduler продемонстрирован как сильно влияющий на производительность.
Эх… Мне zfs по этому ролику запомнилось
www.youtube.com/watch?v=CN6iDzesEs0
www.youtube.com/watch?v=CN6iDzesEs0
> С благодарность приму поправки.
[…]
> транзакционной семантикой «копирование по записи»
«по записи» звучит как минимум странно. Устоявшийся перевод термина COW — «копирование при записи». Можно было глянуть хотя бы в ru.wiki/Copy-on-write
[…]
> транзакционной семантикой «копирование по записи»
«по записи» звучит как минимум странно. Устоявшийся перевод термина COW — «копирование при записи». Можно было глянуть хотя бы в ru.wiki/Copy-on-write
[…]
> усовершенствование эффективности
По-русски так тоже не говорят.
> усовершенствование эффективности
По-русски так тоже не говорят.
> Еще один блоггер из SUN, имеет по крайне мере один тест, в котором ZFS
> I/O планироващик (прим.пер. тут мой мозг сломался)
Чтобы упомянуть ещё одного блогера из Sun — есть по меньшей мере один бенчмарк, который позволил планировщику ввода-вывода ZFS продемонстрировать значительную разницу в производительности.
> I/O планироващик (прим.пер. тут мой мозг сломался)
Чтобы упомянуть ещё одного блогера из Sun — есть по меньшей мере один бенчмарк, который позволил планировщику ввода-вывода ZFS продемонстрировать значительную разницу в производительности.
Что касается уже не перевода, а сути статьи, то как по мне — маркетинг. У ZFS есть, разумеется, свои преимущества, но проблема double buffering не встречается там, где есть поддержка O_DIRECTIO, а это практически все современные FS, в том числе и Solaris' UFS, которая это тоже давно умеет. Read-ahead можно управлять, по кр. мере в Linux. Из того, с чем действительно сложно не согласиться, это, может быть, чуть более удобное администрирование, но это, скорее, плюс для новичков, поскольку для человека, который проработал с *NIX несколько лет, добавить в /etc/fstab новую запись не проблема вовсе, а если вспомнить о том, что в Linux есть замечательный Software RAID + не менее замечательный менеджер логических дисков (LVM-2), то можно понять, что остаётся не так уж много моментов, в которых действительно возникает желание использовать ZFS (но их есть, да).
С замечаниями по переводу согласен. Спасибо. А вот насчет маркетинга — почти все ваши замечания прямо присутствуют в тексте материала.
> почти все ваши замечания прямо присутствуют
Во-1-х, «почти», да, а во-2-х, насчёт «прямо» я бы поспорил. Весьма невнятно они там присутствуют, в отличие от дифирамбов ZFS. И именно потому, что по факту ничего революционного в итоге не обнаруживается, а текста немало, возникает «маркетинговое» ощущение. :-)
Во-1-х, «почти», да, а во-2-х, насчёт «прямо» я бы поспорил. Весьма невнятно они там присутствуют, в отличие от дифирамбов ZFS. И именно потому, что по факту ничего революционного в итоге не обнаруживается, а текста немало, возникает «маркетинговое» ощущение. :-)
Apple отказалась от ZFS в 10.6
Ну что вы я не отказался от MacOS X, мак-мини уже давно подключен телевизору и показывет мне кино.
(это была ирония)
Я написал, что как раз НЕ собирался делать ничего подобного (устанавливать MySQL) с MacOS X, так что факт отказа Apple от ZFS мне безразличен.
Возможно мой кругозор несколько ограничен, но я не вижу никаких причин использовать MySQL на MacOS X.
Если вы знаете о плюсах связки MySQL и MacOS X — поделитесь
(это была ирония)
Я написал, что как раз НЕ собирался делать ничего подобного (устанавливать MySQL) с MacOS X, так что факт отказа Apple от ZFS мне безразличен.
Возможно мой кругозор несколько ограничен, но я не вижу никаких причин использовать MySQL на MacOS X.
Если вы знаете о плюсах связки MySQL и MacOS X — поделитесь
«Еще один блоггер из SUN, имеет по крайне мере один тест, в котором ZFS I/O планироващик»
Оригинал: To bring in yet another Sun blogger, there is at least one benchmark where the ZFS I/O scheduler has been shown to make a big difference in performance.
Перевод: Приведем еще одного блоггера Sun, имеется по крайней мере один тест, в котором показано (из которого видно), что планировщик ввода/вывода в ZFS дает большую разницу в производительности.
Оригинал: To bring in yet another Sun blogger, there is at least one benchmark where the ZFS I/O scheduler has been shown to make a big difference in performance.
Перевод: Приведем еще одного блоггера Sun, имеется по крайней мере один тест, в котором показано (из которого видно), что планировщик ввода/вывода в ZFS дает большую разницу в производительности.
The real reason for the good performance on this benchmark is not clear — indeed, every workload will be different — but the ZFS I/O scheduler, the Sun engineers paying attention to database performance, and the ZFS bug fixes contributed in recent (late 2007) releases of Open Solaris seem to be adding up to something good.
Настоящая причина хорошей производительности на этом тесте не ясна — на самом деле каждая нагрузка будет разная — но шедулер в/в ZFS (инженеры Sun уделяют внимание производительности базы данных) и исправленные ошибки ZFS в последнее время (конец 2007) в релизе Open Solaris, кажется, дают что-то хорошее.
Настоящая причина хорошей производительности на этом тесте не ясна — на самом деле каждая нагрузка будет разная — но шедулер в/в ZFS (инженеры Sun уделяют внимание производительности базы данных) и исправленные ошибки ZFS в последнее время (конец 2007) в релизе Open Solaris, кажется, дают что-то хорошее.
UFO just landed and posted this here
Sign up to leave a comment.
A look at MySQL on ZFS