Подскажите какую ФС использовать под нагруженный mysql сервер
собственно сабж.
Какая ФС лучше, для хранения информации(datadir).
сейчас использую ext3
размер базы 11гб
процессор: две штуки Intel(R) Xeon(TM) CPU 3.20GHz по 4 ядра каждый(с HT)
оперативы 12гб.
харды SATA2, в софтовом рейд1
qps в среднем ~500
70% select`ы
20 insert`ы
остальное между delete и update
вот и думаю, какая ФС лучше будет для хранение базы(разумеется в отдельном разделе)
kam ★★
08.04.12 13:04:36 MSK
blackst0ne ★★★★★
( 08.04.12 13:50:08 MSK )
менять фс смысла нет — мускуль все равно держит весь кеш в оперативке и сбрасывает на диск нечасто. впрочем, посмотри в iotop как сильно просаживается диск
вместо этого лучше поставить нормальный рейд с батарейкой
dreamer ★★★★★
( 08.04.12 14:06:57 MSK )
XFS. Для линукса наверное самый оптимальный вариант:
1) благодаря структуре метаданных, параллельные синхронные записи в лог на этой FS быстрее всего.
2) Здорово помогает то, что XFS выравнивает файлы на границу страйпа.
3) В линукс XFS лучше всех поддерживает параллельный I/O.
baka-kun ★★★★★
( 08.04.12 14:13:55 MSK )
Ответ на: комментарий от blackst0ne 08.04.12 13:50:08 MSK
Выкинь каку, и не тяни больше в рот всякое дерьмо.
baka-kun ★★★★★
( 08.04.12 14:15:06 MSK )
Ответ на: комментарий от baka-kun 08.04.12 14:15:06 MSK
King_Diamond
( 08.04.12 14:16:19 MSK )
Ответ на: комментарий от dreamer 08.04.12 14:06:57 MSK
мускуль все равно держит весь кеш в оперативке и сбрасывает на диск нечасто
MySQL постоянно пишет логи транзакций (у ТС 30% записей в базу), причем пишет синхронно.
Работа с диском у MySQL делится на три паттерна:
1) Синхронная запись/перезапись лога. 2) Синхронное чтение (page-in). 3) Асинхронная запись (page-out).
И всё это параллельно в несколько потоков. Вот и выбирай FS исходя из этого.
baka-kun ★★★★★
( 08.04.12 14:20:18 MSK )
Ответ на: комментарий от baka-kun 08.04.12 14:15:06 MSK
baka-kun
Выкинь каку, и не тяни больше в рот всякое дерьмо.
Может быть у Вас и benchmarks есть, применимые к условиям вышеуказанной задачи?
blackst0ne ★★★★★
( 08.04.12 14:24:23 MSK )
blackst0ne ★★★★★
( 08.04.12 14:31:34 MSK )
Ответ на: комментарий от blackst0ne 08.04.12 14:24:23 MSK
Может быть у Вас и benchmarks есть
Так ведь это ты советуешь отстойную ext4, поэтому с тебя и бенчмарки, доказывающие её применимость.
baka-kun ★★★★★
( 08.04.12 14:32:26 MSK )
Ответ на: комментарий от baka-kun 08.04.12 14:32:26 MSK
baka-kun
Так ведь это ты советуешь отстойную ext4, поэтому с тебя и бенчмарки, доказывающие её применимость.
Нет-нет, это Вы пришли и сказали, что ext4 — это «кака». Хотелось бы увидеть факты, позволяющие Вам так утверждать.
Здесь два варианта развития событий: или Вы голословны, или я, а может и некоторые другие личности, узнаем что-то новое.
blackst0ne ★★★★★
( 08.04.12 14:35:59 MSK )
Ответ на: комментарий от blackst0ne 08.04.12 14:35:59 MSK
Нет-нет, это Вы пришли и сказали, что ext4 — это «кака».
Я тоже так считаю. ext4 на параллельной записи-чтении практически кладёт систему, работать невозможно, отзывчивость сервисов неприемлемо низкая. С XFS всё работает очень быстро, гладко, без фризов. Ни один бенчмарк, к сожалению, этого не покажет.
King_Diamond
( 08.04.12 14:41:10 MSK )
Ответ на: комментарий от baka-kun 08.04.12 14:13:55 MSK
iotop как не странно больше просаживается над записью, ибо с кеш скуля настроен нормально, сервер выделенный под базу. и в iotop`е чаще всего вверху находится журналирование(kjournald), хоть сервер и в дц(оверсан), и с питанием все норм. но отключать журнал желание нету(хотя бекапы делаются каждую ночь).
XFS в данном случае поможет?
P.S. забыл добавить
mysql 5.5
типы таблиц разные (70% myisam — 30 innodb)
kam ★★
( 08.04.12 14:43:48 MSK ) автор топика
Ответ на: комментарий от blackst0ne 08.04.12 14:31:34 MSK
Вадим, вместо того, чтобы спросить у знающих людей, вылез со своей «новостью», теперь каждый ламер на планете будет на него ссылаться. 🙁
В течение короткого времени в XFS была регрессия в блокировках, вот её Вадим и измерил. Если повторить тест сейчас, то отрыв XFS с ростом потоков будет только увеличиваться. На 16 нитей ext4 выдаёт около 90к iops, а xfs — 300к iops на том же железе.
baka-kun ★★★★★
( 08.04.12 14:53:40 MSK )
Ответ на: комментарий от kam 08.04.12 14:43:48 MSK
baka-kun ★★★★★
( 08.04.12 14:54:27 MSK )
Ответ на: комментарий от blackst0ne 08.04.12 13:50:08 MSK
Использовать ext4, потому что это единственный баззворд-фс, про который вы слышали? Нет, спасибо.
anonymous
( 08.04.12 14:55:21 MSK )
Ответ на: комментарий от blackst0ne 08.04.12 14:35:59 MSK
Ты, судя по всему, не хочешь узнавать новое, иначе бы даже сомнений в превосходстве xfs не возникло.
baka-kun ★★★★★
( 08.04.12 14:57:30 MSK )
Ответ на: комментарий от baka-kun 08.04.12 14:53:40 MSK
baka-kun
В течение короткого времени в XFS была регрессия в блокировках, вот её Вадим и измерил. Если повторить тест сейчас, то отрыв XFS с ростом потоков будет только увеличиваться. На 16 нитей ext4 выдаёт около 90к iops, а xfs — 300к iops на том же железе.
Всё это просто слова, не подтверждённые ничем.
blackst0ne ★★★★★
( 08.04.12 15:29:29 MSK )
Ответ на: комментарий от baka-kun 08.04.12 14:57:30 MSK
baka-kun
Ты, судя по всему, не хочешь узнавать новое, иначе бы даже сомнений в превосходстве xfs не возникло.
Я посмотрел бенчмарки на известном ресурсе, на основании которых можно сделать определённые выводы в производительности файловых систем в рамках определённых задач.
От Вас же можно увидеть только голословные высказывания.
blackst0ne ★★★★★
( 08.04.12 15:32:39 MSK )
Ответ на: комментарий от blackst0ne 08.04.12 15:32:39 MSK
А самому попробовать, не?
King_Diamond
( 08.04.12 15:38:51 MSK )
Ответ на: комментарий от King_Diamond 08.04.12 15:38:51 MSK
blackst0ne ★★★★★
( 08.04.12 15:55:17 MSK )
Ответ на: комментарий от blackst0ne 08.04.12 15:29:29 MSK
Всё это просто слова, не подтверждённые ничем.
Только тестами, всем опытом использования xfs и её разработчиками.
Я посмотрел бенчмарки на известном ресурсе…
Ты посмотрел на известном ресурсе sysbench-бенчмарки xfs с известной на момент тестов регрессией. Автор намерял 20% лучшей пропускной способности у ext4. Круто. Но накатив на xfs исправляющий регрессию патч, ext4 начинает сливать в три раза.
Мне жаль того, кто по твоему совету воспользуется etx4 в продакшен, поскольку изменить fs под живой базой будет затруднительно. Вадим, не разобравшись в вопросе, раструбил на весь мир, и теперь с его именем бегают как с флагом. А ведь его предупреждали…
baka-kun ★★★★★
( 08.04.12 16:04:55 MSK )
Ответ на: комментарий от baka-kun 08.04.12 16:04:55 MSK
немножко оффтоп. Не подскажешь как правильно рассчитать количество allocation group на разделе при создании XFS? В старых источниках предлагают под каждый ag выделять 4Гб, в новых опровергают, но точных указаний не дают. По умолчанию mkfs.xfs всегда предлагает 4 ag, не зависимо от размера раздела (проверял на разделах 500Гб, 1Тб, 2Тб) , не маловато?
King_Diamond
( 08.04.12 16:11:00 MSK )
Ответ на: комментарий от baka-kun 08.04.12 16:04:55 MSK
baka-kun
Ты посмотрел на известном ресурсе sysbench-бенчмарки xfs с известной на момент тестов регрессией. Автор намерял 20% лучшей пропускной способности у ext4. Круто. Но накатив на xfs исправляющий регрессию патч, ext4 начинает сливать в три раза.
Мне жаль того, кто по твоему совету воспользуется etx4 в продакшен, поскольку изменить fs под живой базой будет затруднительно. Вадим, не разобравшись в вопросе, раструбил на весь мир, и теперь с его именем бегают как с флагом. А ведь его предупреждали…
Судя по всему, этот патч вышел только недавно. А про регрессию в XFS Вадим Ткаченко не знал, если верить его словам по той же ссылке.
blackst0ne ★★★★★
( 08.04.12 16:13:42 MSK )
Ответ на: комментарий от King_Diamond 08.04.12 16:11:00 MSK
как правильно рассчитать количество allocation group на разделе при создании XFS?
Ну, AG — это как бы отдельная ФС внутри ФС, что позволяет более эффективно распараллелить доступ: блокировки внутри одной АГ не влияют на другие. Максимальный размер каждой АГ, ЕМНИП 1Тб. То есть общей рекомендацией может быть создание минимум одной, а лучше двух–четырех АГ на каждый шпиндель в дисковом массиве. Где-то так.
baka-kun ★★★★★
( 08.04.12 16:29:24 MSK )
Ответ на: комментарий от blackst0ne 08.04.12 16:13:42 MSK
Судя по всему, этот патч вышел только недавно.
Регрессия была обнаружена в конце января. В ванильном ядре патч будет, думаю, в 3.4. Дистрибутивы могут накладывать раньше, команда xfs всегда открыта к общению.
А про регрессию в XFS Вадим Ткаченко не знал…
Вот кто ему мешал сперва уточнить, почему это xfs вдруг так резко сдала, а потом буковки строчить? То-то и оно.
baka-kun ★★★★★
( 08.04.12 16:33:48 MSK )
Ответ на: комментарий от baka-kun 08.04.12 16:29:24 MSK
а лучше двух–четырех АГ на каждый шпиндель в дисковом массиве. Где-то так.
Спасибо. Значит, по умолчанию, она предлагает вполне адекватное значение 4 ag на физ.диск.
King_Diamond
( 08.04.12 16:33:49 MSK )
Ответ на: комментарий от baka-kun 08.04.12 16:33:48 MSK
не поделишься ссылкой на патчик.
kam ★★
( 08.04.12 21:31:02 MSK ) автор топика
Ответ на: комментарий от baka-kun 08.04.12 16:29:24 MSK
Выделил на raid-5+lvm 700Гб, mkfs.xfs, без доп.опций, предложила agcount=32, типа интеллектуальная штука.
King_Diamond
( 08.04.12 23:29:37 MSK )
Ответ на: комментарий от kam 08.04.12 21:31:02 MSK
Честно говоря не очень в курсе о каком патче речь, но 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
( 08.04.12 23:35:14 MSK )
Ответ на: комментарий от King_Diamond 08.04.12 23:35:14 MSK
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, Системные требования для Farming Simulator 2019
Было много слухов, что разработчики игры Farming Simulator выпустят новую версию (FS 19) на новом движке. Но уже есть официальная информация, что движок останется старым, но будет существенно доработан и оптимизирован.
Если сравнивать системные требования к компьютеру для Farming Simulator 2019 с предыдущей версией игры, то можно заметить, что требования увеличились почти в два раза. То есть, для запуска FS 19 понадобится более мощный компьютер.
В Steam, где уже можно сделать предзаказ на Farming Simulator 19 указаны следующие системные требования:
- Операционная система Windows 7, Windows 8, Windows 10. Система должна быть 64-х битная.
- Процессор Intel Core i3-2100T с таковой частотой 2.5GHz, или AMD FX-4100 с частотой 3.6 GHz. Ну, или более мощный процессор.
- Для запуска FS 19 в вашем компьютере должно быть установлено минимум 4 GB оперативной памяти. Если меньше, то возможно игра не запуститься, или будет сильно тормозить.
- Видеокарта Nvidia Geforce GTX 650, или AMD Radeon HD 7770. Или же более мощная. Должно быть минимум 2 ГБ видеопамяти. И поддержка DX11.
- 20 ГБ свободного места на жестком диске.
- Подключение к интернету. Если вы планируете играть в Farming Simulator 2019 по сети.
Вот еще скриншот с системными требованиями из Steam:
Игра скорее всего будет работать и на компьютерах с более скромными характеристиками. Но как вы сами понимаете, скорость загрузки, плавность (количество FPS) и наслаждение от игрового процесса сильно пострадает.
Моды которые сделают вашу игру лучше Farming Simulator 19 | FS 19 | Fs 21 mods ТОП 5 модов
��������������������������������������������������������
✅НА ПІДТРИМКУ І РОЗВИТОК КАНАЛУ
✅ЗА КОЖЕН ДОНАТ БУДУ ЗГАДУВАТИ ВАС У СВОЇХ ВІДЕО.
На номер -380677657465
✅ТАКОЖ Я ВАМ БУДУ СИЛЬНО ВДЯЧНИЙ.
ТЕГИ:
farming simulator, giants software, let’s play, fs19, fs17, mods, fs19 mods, farming simulator 2019, simulator, lets play farming simulator timelapse, farming simulator 2019 timelapse, farming simulator 19, ls 19, fs timelapse, fs19 gameplay, farming, farming simulator 19 timelapse, farming simulator mods, fs mods timelapse, свапа, ls17, ls19, let’s play farming simulator timelapse, farming simulator 19 gameplay, видео-обзоры, моды, прохождение, стримы, симулятор, русский, мод, пак, техники, fs 19, симулятор фермы 2019, русский комбайн для fs 19, русские моды для фс 19, где скачать русскую технику для фс 19, российские моды для фарминг симулятор, фарминг симулятор 19 моды, моды для симулятора фермера 2019, моды русской техники для фс 19, фс 19 русская техника, все русские моды для фс 19, обзор русских модов для фарминг симулятора 2019, фс 19 моды, косилка для фс 19, farming simulator 19, mod, farm, farming simulator 19 new mods today, fs19 mod review, fs19 mods pc, fs19 new mods pc, fs19 new mods ps4, fs19 new mods today, fs19 new mods xbox one, gaming, mod review, new mods, new mods today, sim, man tge truck fs19, car mods fs19, best car mods fs19
Выбор ФС для файлового сервера
Появился у меня такой вопрос — какую файловую систему выбрать для файлового сервера?
Что есть сейчас:
Машинка Intel CoreQuad, 8Gb ram, 2×1.5tb HDD (2 набора RAID 1, каждый винт зеркалируется), Система CentOS 5.5 Файловая система на этих винтах ext3
Сам файловый сервер — хранилище пользовательского контента социальной сети (аналог csXXX.вконтакте) . А именно — множество мелких (до 80кб и меньше) jpg, png, далее mp3 (размером до 20mb) + flv (размером до 100 mb). Все находится под большой нагрузкой, огромное кол-во запросов, соответственно в основном чтение.
Стоит ли выбрать для этого какую-нибудь другую ФС для увеличения производительности, но не с большой потерей надежности? И что посоветуете.
З.Ы. знаю что вопрос уже везде изъезжен, но гугля так и не получилось найти свежих и достоверных данных.
Да, и еще, также буду благодарен за советы по оптимизации CentOS под файловый сервер. Смотрел доклад Игоря Сысоева, так он конечно чудеса с nginx+freebsd творит. Может есть какие-нить особенности для Linux?