> From: "Alexey Markov" <alex@asdg.ru> > Date: Tue, 15 Apr 2014 06:24:52 +0000 (UTC) > >Собственно, сабж. Hу, кроме как "не использовать БД на ZFS"? > >Есть несколько серверов под 8-кой, на которых стоит "ZFS на весь диск", >постепенно остальные сервера планируется переводить на такую же схему. >Беда в том, что кое-где используется MySQL (не очень нагруженный, для >веб-сайтов и GlassFish), а в паре мест - Постгрес, и вот там нагрузка >ОЧЕHЬ серьёзная. > >Тестирование показало, что для Постгреса провал производительности >по сравнению с UFS не очень большой (но есть). Для Мускуля с InnoDB >всё оказалось заметно хуже. Поэтому буду благодарен за любые советы >по грамотному использованию MySQL и/или PostgreSQL на ZFS.
По моему опыту, общие советы не для всякой задачи подходят. То есть надо в любом случае тестировать под конкретной нагрузкой. Хотя я бы отдал под InnoDB специально выделенные volumы, поигравшись с размерами блоков и там и тут. Ибо на опыте сталкивался с заметным падением производительности при несоответствии размеров дискового блока и базаданной страницы.
>И, чтобы два раза не вставать - ещё один вопрос. Планирую установить >на сервер с Постгресом два SSD Intel S3700 в зеркале, под базу данных. >Имеет ли смысл выделить часть этих SSD под ZIL для обычных дисков?
Скорее имеет смысл выделить отдельные (не зеркалируемые) SSD под кэш чтения, а с ZIL сначала померять производительность (по крайней мере, на моих задачах проблемы с чтением наступают гораздо раньше, чем с записью).
>Просто где-то мне попадалась статья, в которой не рекомендовалось >разбивать SSD под несколько задач: типа, либо только ZIL, либо данные. >Поэтому хотелось бы услышать аргументы за и против такого решения.
Есть целая статья про ZFS и SSD, основная её мысль - сделать так, чтобы данные уцелели, когда SSD навернётся. А про производительность там вскользь.
