Подскажите какую ФС использовать под нагруженный mysql сервер

ext4

менять фс смысла нет - мускуль все равно держит весь кеш в оперативке и сбрасывает на диск нечасто. впрочем, посмотри в iotop как сильно просаживается диск

вместо этого лучше поставить нормальный рейд с батарейкой

XFS. Для линукса наверное самый оптимальный вариант:

1) благодаря структуре метаданных, параллельные синхронные записи в лог на этой FS быстрее всего.
2) Здорово помогает то, что XFS выравнивает файлы на границу страйпа.
3) В линукс XFS лучше всех поддерживает параллельный I/O.

ext4

Выкинь каку, и не тяни больше в рот всякое дерьмо.

+1

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

MySQL постоянно пишет логи транзакций (у ТС 30% записей в базу), причем пишет синхронно.

Работа с диском у MySQL делится на три паттерна:

1) Синхронная запись/перезапись лога. 2) Синхронное чтение (page-in). 3) Асинхронная запись (page-out).

И всё это параллельно в несколько потоков. Вот и выбирай FS исходя из этого.

baka-kun

Выкинь каку, и не тяни больше в рот всякое дерьмо.

Может быть у Вас и benchmarks есть, применимые к условиям вышеуказанной задачи?

http://www.mysqlperformanceblog.com/2012/03/15/ext4-vs-xfs-on-ssd/

Может быть у Вас и benchmarks есть

Так ведь это ты советуешь отстойную ext4, поэтому с тебя и бенчмарки, доказывающие её применимость.

baka-kun

Так ведь это ты советуешь отстойную ext4, поэтому с тебя и бенчмарки, доказывающие её применимость.

Нет-нет, это Вы пришли и сказали, что ext4 - это «кака». Хотелось бы увидеть факты, позволяющие Вам так утверждать.

Здесь два варианта развития событий: или Вы голословны, или я, а может и некоторые другие личности, узнаем что-то новое.

Нет-нет, это Вы пришли и сказали, что ext4 - это «кака».

Я тоже так считаю. ext4 на параллельной записи-чтении практически кладёт систему, работать невозможно, отзывчивость сервисов неприемлемо низкая. С XFS всё работает очень быстро, гладко, без фризов. Ни один бенчмарк, к сожалению, этого не покажет.

iotop как не странно больше просаживается над записью, ибо с кеш скуля настроен нормально, сервер выделенный под базу. и в iotop`е чаще всего вверху находится журналирование(kjournald), хоть сервер и в дц(оверсан), и с питанием все норм. но отключать журнал желание нету(хотя бекапы делаются каждую ночь).

XFS в данном случае поможет?

P.S. забыл добавить
mysql 5.5
типы таблиц разные (70% myisam - 30 innodb)

mysqlperformanceblog.com/2012/03/…

Вадим, вместо того, чтобы спросить у знающих людей, вылез со своей «новостью», теперь каждый ламер на планете будет на него ссылаться. :(

В течение короткого времени в XFS была регрессия в блокировках, вот её Вадим и измерил. Если повторить тест сейчас, то отрыв XFS с ростом потоков будет только увеличиваться. На 16 нитей ext4 выдаёт около 90к iops, а xfs — 300к iops на том же железе.

XFS в данном случае поможет?

Да.

ext4

Использовать ext4, потому что это единственный баззворд-фс, про который вы слышали? Нет, спасибо.

узнаем что-то новое.

Ты, судя по всему, не хочешь узнавать новое, иначе бы даже сомнений в превосходстве xfs не возникло.

baka-kun

В течение короткого времени в XFS была регрессия в блокировках, вот её Вадим и измерил. Если повторить тест сейчас, то отрыв XFS с ростом потоков будет только увеличиваться. На 16 нитей ext4 выдаёт около 90к iops, а xfs — 300к iops на том же железе.

Всё это просто слова, не подтверждённые ничем.

baka-kun

Ты, судя по всему, не хочешь узнавать новое, иначе бы даже сомнений в превосходстве xfs не возникло.

Я посмотрел бенчмарки на известном ресурсе, на основании которых можно сделать определённые выводы в производительности файловых систем в рамках определённых задач.

От Вас же можно увидеть только голословные высказывания.

А самому попробовать, не?

King_Diamond

А самому попробовать, не?

Не сегодня. =)

Всё это просто слова, не подтверждённые ничем.

Только тестами, всем опытом использования xfs и её разработчиками.

Я посмотрел бенчмарки на известном ресурсе…

Ты посмотрел на известном ресурсе sysbench-бенчмарки xfs с известной на момент тестов регрессией. Автор намерял 20% лучшей пропускной способности у ext4. Круто. Но накатив на xfs исправляющий регрессию патч, ext4 начинает сливать в три раза.

Мне жаль того, кто по твоему совету воспользуется etx4 в продакшен, поскольку изменить fs под живой базой будет затруднительно. Вадим, не разобравшись в вопросе, раструбил на весь мир, и теперь с его именем бегают как с флагом. А ведь его предупреждали…

немножко оффтоп. Не подскажешь как правильно рассчитать количество allocation group на разделе при создании XFS? В старых источниках предлагают под каждый ag выделять 4Гб, в новых опровергают, но точных указаний не дают. По умолчанию mkfs.xfs всегда предлагает 4 ag, не зависимо от размера раздела (проверял на разделах 500Гб, 1Тб, 2Тб) , не маловато?

baka-kun

Ты посмотрел на известном ресурсе sysbench-бенчмарки xfs с известной на момент тестов регрессией. Автор намерял 20% лучшей пропускной способности у ext4. Круто. Но накатив на xfs исправляющий регрессию патч, ext4 начинает сливать в три раза.

Мне жаль того, кто по твоему совету воспользуется etx4 в продакшен, поскольку изменить fs под живой базой будет затруднительно. Вадим, не разобравшись в вопросе, раструбил на весь мир, и теперь с его именем бегают как с флагом. А ведь его предупреждали…

Судя по всему, этот патч вышел только недавно. А про регрессию в XFS Вадим Ткаченко не знал, если верить его словам по той же ссылке.

как правильно рассчитать количество allocation group на разделе при создании XFS?

Ну, AG — это как бы отдельная ФС внутри ФС, что позволяет более эффективно распараллелить доступ: блокировки внутри одной АГ не влияют на другие. Максимальный размер каждой АГ, ЕМНИП 1Тб. То есть общей рекомендацией может быть создание минимум одной, а лучше двух–четырех АГ на каждый шпиндель в дисковом массиве. Где-то так.

Судя по всему, этот патч вышел только недавно.

Регрессия была обнаружена в конце января. В ванильном ядре патч будет, думаю, в 3.4. Дистрибутивы могут накладывать раньше, команда xfs всегда открыта к общению.

А про регрессию в XFS Вадим Ткаченко не знал…

Вот кто ему мешал сперва уточнить, почему это xfs вдруг так резко сдала, а потом буковки строчить? То-то и оно.

а лучше двух–четырех АГ на каждый шпиндель в дисковом массиве. Где-то так.

Спасибо. Значит, по умолчанию, она предлагает вполне адекватное значение 4 ag на физ.диск.

не поделишься ссылкой на патчик.

Выделил на raid-5+lvm 700Гб, mkfs.xfs, без доп.опций, предложила agcount=32, типа интеллектуальная штука.

Честно говоря не очень в курсе о каком патче речь, но xfs на ubuntu-server 11.10 (ядро 3.0.0-17-server x86_64) радикально быстрее, чем на 10.04lts (ядро 2.6.32-server x86_64). Может речь об этом: The patch was included in the mainline kernel as an experimental feature in 2.6.35, is a stable feature of 2.6.37, and is the default journal logging method in Linux 2.6.39. Testing by the developer in 2010 showed performance to be similar to ext4 at low thread counts, and superior to ext4 at high thread counts.

King_Diamond

Честно говоря не очень в курсе о каком патче речь, но xfs на ubuntu-server 11.10 (ядро 3.0.0-17-server x86_64) радикально быстрее, чем на 10.04lts (ядро 2.6.32-server x86_64).
Может речь об этом:
The patch was included in the mainline kernel as an experimental feature in 2.6.35, is a stable feature of 2.6.37, and is the default journal logging method in Linux 2.6.39. Testing by the developer in 2010 showed performance to be similar to ext4 at low thread counts, and superior to ext4 at high thread counts.

Регрессия свежая, этого года. И ожидается, что патч появится в 3.4 версии ядра.

Я так понимаю, что речь идёт вот об этом:

fs/xfs/xfs_aops.c  |   22 ++++++++++++++++++++--
 fs/xfs/xfs_file.c  |   35 +++++++++++++++++++++--------------
 fs/xfs/xfs_iomap.c |   10 +++++++---
 fs/xfs/xfs_iomap.h |    2 +-
 4 files changed, 49 insertions(+), 20 deletions(-)

diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index 74b9baf..4c84508 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -138,6 +138,9 @@ xfs_setfilesize(
        xfs_inode_t             *ip = XFS_I(ioend->io_inode);
        xfs_fsize_t             isize;
 
+       if (!xfs_ioend_new_eof(ioend))
+               return 0;
+
        if (!xfs_ilock_nowait(ip, XFS_ILOCK_EXCL))
                return EAGAIN;
 
@@ -1121,7 +1124,22 @@ __xfs_get_blocks(
                return 0;
 
        if (create) {
-               lockmode = XFS_ILOCK_EXCL;
+               /*
+                * For direct IO, we lock in shared mode so that write
+                * operations that don't require allocation can occur
+                * concurrently. The ilock has to be dropped over the allocation
+                * transaction reservation, so the only thing the ilock is
+                * providing here is modification exclusion. i.e. there is no
+                * need to hold the lock exclusive.
+                *
+                * For buffered IO, if we need to do delayed allocation then
+                * hold the ilock exclusive so that the lookup and delalloc
+                * reservation is atomic.
+                */
+               if (direct)
+                       lockmode = XFS_ILOCK_SHARED;
+               else
+                       lockmode = XFS_ILOCK_EXCL;
                xfs_ilock(ip, lockmode);
        } else {
                lockmode = xfs_ilock_map_shared(ip);
@@ -1144,7 +1162,7 @@ __xfs_get_blocks(
              imap.br_startblock == DELAYSTARTBLOCK))) {
                if (direct) {
                        error = xfs_iomap_write_direct(ip, offset, size,
-                                                      &imap, nimaps);
+                                                      &imap, nimaps, 
&lockmode);
                } else {
                        error = xfs_iomap_write_delay(ip, offset, size, &imap);
                }
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 10ec272..c74e28c 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -650,41 +650,48 @@ xfs_file_aio_write_checks(
        struct inode            *inode = file->f_mapping->host;
        struct xfs_inode        *ip = XFS_I(inode);
        int                     error = 0;
+       int                     ilock = XFS_ILOCK_SHARED;
 
-       xfs_rw_ilock(ip, XFS_ILOCK_EXCL);
+       xfs_rw_ilock(ip, ilock);
 restart:
        error = generic_write_checks(file, pos, count, S_ISBLK(inode->i_mode));
        if (error) {
-               xfs_rw_iunlock(ip, XFS_ILOCK_EXCL);
+               xfs_rw_iunlock(ip, ilock);
                return error;
        }
 
-       if (likely(!(file->f_mode & FMODE_NOCMTIME)))
-               file_update_time(file);
-
        /*
         * If the offset is beyond the size of the file, we need to zero any
         * blocks that fall between the existing EOF and the start of this
-        * write.  If zeroing is needed and we are currently holding the
-        * iolock shared, we need to update it to exclusive which involves
-        * dropping all locks and relocking to maintain correct locking order.
-        * If we do this, restart the function to ensure all checks and values
-        * are still valid.
+        * write.  If zeroing is needed and we are currently holding shared
+        * locks, we need to update it to exclusive which involves dropping all
+        * locks and relocking to maintain correct locking order.  If we do
+        * this, restart the function to ensure all checks and values are still
+        * valid.
         */
        if (*pos > i_size_read(inode)) {
-               if (*iolock == XFS_IOLOCK_SHARED) {
-                       xfs_rw_iunlock(ip, XFS_ILOCK_EXCL | *iolock);
+               if (*iolock == XFS_IOLOCK_SHARED || ilock == XFS_ILOCK_SHARED) {
+                       xfs_rw_iunlock(ip, ilock | *iolock);
                        *iolock = XFS_IOLOCK_EXCL;
-                       xfs_rw_ilock(ip, XFS_ILOCK_EXCL | *iolock);
+                       ilock = XFS_ILOCK_EXCL;
+                       xfs_rw_ilock(ip, ilock | *iolock);
                        goto restart;
                }
                error = -xfs_zero_eof(ip, *pos, i_size_read(inode));
        }
-       xfs_rw_iunlock(ip, XFS_ILOCK_EXCL);
+       xfs_rw_iunlock(ip, ilock);
        if (error)
                return error;
 
        /*
+        * we can't do any operation that might call .dirty_inode under the
+        * ilock when we move to completely transactional updates. Hence this
+        * timestamp must sit outside the ilock.
+        */
+       if (likely(!(file->f_mode & FMODE_NOCMTIME)))
+               file_update_time(file);
+
+       /*
         * If we're writing the file then make sure to clear the setuid and
         * setgid bits if the process is not being run by root.  This keeps
         * people from modifying setuid and setgid binaries.
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 246c7d5..792c81d 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -123,7 +123,8 @@ xfs_iomap_write_direct(
        xfs_off_t       offset,
        size_t          count,
        xfs_bmbt_irec_t *imap,
-       int             nmaps)
+       int             nmaps,
+       int             *lockmode)
 {
        xfs_mount_t     *mp = ip->i_mount;
        xfs_fileoff_t   offset_fsb;
@@ -189,7 +190,8 @@ xfs_iomap_write_direct(
        /*
         * Allocate and setup the transaction
         */
-       xfs_iunlock(ip, XFS_ILOCK_EXCL);
+       xfs_iunlock(ip, *lockmode);
+
        tp = xfs_trans_alloc(mp, XFS_TRANS_DIOSTRAT);
        error = xfs_trans_reserve(tp, resblks,
                        XFS_WRITE_LOG_RES(mp), resrtextents,
@@ -200,7 +202,9 @@ xfs_iomap_write_direct(
         */
        if (error)
                xfs_trans_cancel(tp, 0);
-       xfs_ilock(ip, XFS_ILOCK_EXCL);
+
+       *lockmode = XFS_ILOCK_EXCL;
+       xfs_ilock(ip, *lockmode);
        if (error)
                goto error_out;
 
diff --git a/fs/xfs/xfs_iomap.h b/fs/xfs/xfs_iomap.h
index 8061576..21e3398 100644
--- a/fs/xfs/xfs_iomap.h
+++ b/fs/xfs/xfs_iomap.h
@@ -22,7 +22,7 @@ struct xfs_inode;
 struct xfs_bmbt_irec;
 
 extern int xfs_iomap_write_direct(struct xfs_inode *, xfs_off_t, size_t,
-                       struct xfs_bmbt_irec *, int);
+                       struct xfs_bmbt_irec *, int, int *);
 extern int xfs_iomap_write_delay(struct xfs_inode *, xfs_off_t, size_t,
                        struct xfs_bmbt_irec *);
 extern int xfs_iomap_write_allocate(struct xfs_inode *, xfs_off_t, size_t,

не поделишься ссылкой на патчик.

Свежее всего в http://xfs.org/index.php/XFS_git_howto , но на свой страх и риск, естественно.

без доп.опций, предложила agcount=32, типа интеллектуальная штука.

Типа да. :) А были сомнения?

Спасибо.
на выходных перекину базу на новый раздел. отпишусь о результате.

лучше вообще запихать все в InnoDB(заодно и транзакции будут, ога) и на RAW-раздел положить

размер базы 11гб
оперативы 12гб.
70% select`ы

Параметры кеширования подрихтую - база со временем почти вся в оперативу уйдет - PROFIT!

s/подрихтую/подрихтуй/

если есть паралельное чтение/запись то XFS

Жесть какая :D

Наслушавшись разговоров о том, какой классной стала XFS, сегодня ночью сделал lvcreate на раздельчик, тормознул mysql, скопировал туда БД с нынешнего раздела, перезапустил.

Вроде, работает.

Утром просыпаюсь — mysql лежит. В логе ошибок — тонна ругани на повреждённые innodb. Пытаюсь чинить — фигвам. С виду всё нормально, как живые, но mysql падает на innodb-ошибках. На форумах за ночь написали мало, начинаю упавшие таблицы копировать со старой БД. Понемногу чинится. Дальше — веселее. Дело доходит до таблицы topics, достаточно плотно модифицируемой (число просмотров). Стоп mysql, копирую таблицу, старт mysql, недолго работает нормально, БАЦ — ошибка. mysql падает.

Помучился немного, завёл для теста ещё один раздел, уже снова на ext4, скопировал туда опять старую базу, перемонтировал /var/lib/mysql уже на ext4, перезапустил mysql — работает!

Вот такой нынче xfs на 3.2.12-gentoo :)

В общем, я пока по-прежнему на ext4 посижу, за последние 2+ года ни одного сбоя.

А еще все забывают, что при внезапном отключении питания xfs любит забивать нулями открытые файлы.

Забывают, видимо, потому что уже несколько лет с этим не сталкивались :)

Лет 5 назад это у меня было обычное дело. Но уже несколько лет, как ни одной потери. Видимо, что-то подрихтовали.

Возможно починили, но при копировании больших файлов на 2х разных машинах вся система умирала и это до сих пор актуально.

А зачем FS, собственно ?

Мускуль умеет работать на сырых разделах и вроде еще не разучился.

а если таблици myisam ?)

а если таблици myisam ?)

Тады ой :-) Да и InnoDB надо делать бечмарки и сравнивать, возможно прирост по сравнению с ФС будет не таким уж впечатляющим, а неудобств такое решение доставляет все же побольше.

вообще, использование хранение данных не в файлах а целиком в разделе - должно быть шутрее, хотяб процентов на 5-10
но вот беда, у меня сейчас общий объем данных по таблицам:

Data in MyISAM tables: 8G (Tables: 940)
Data in InnoDB tables: 3G (Tables: 268)
Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
Data in MEMORY tables: 1M (Tables: 2)

не сильно оправданно будет юзать отдельный раздел для таблиц innodb
да и к тому же - mysql 5.5 + innodb_file_per_table

руки к сожалению еще не дошли перетащить для теста на xfs раздел, но в ближайшее время это произайдет, вот и посмотрим как он себя покажет.

О, да я не один такой. Абсолютно аналогичное поведение, за которое меня чуть не уволили. Еще один аргумент в защиту, спасибо

RAID1 на 3.2.0-3-amd64 #1 SMP