Хочу поделится радостью: удалось оптимизировать работу MySQL.
В БУС монитор производительности на мощном сервере показывал следуюшее:
База данных MySQL (запись) 72 5 600 количество запросов на запись в секунду
База данных MySQL (чтение) 5 869 7 800 количество запросов на чтение в секунду
База данных MySQL (изменение) 4 251 5 800 количество запросов на изменение в секунду
Но нашлась все-таки одна настроечка, которая ну очень сильно меня обрадовала: innodb_flush_log_at_trx_commit=2
После того как я ее прописал, получил следующие циферки:
База данных MySQL (запись) 4 395 5 600 количество запросов на запись в секунду
База данных MySQL (чтение) 6 220 7 800 количество запросов на чтение в секунду
База данных MySQL (изменение) 4 643 5 800 количество запросов на изменение в секунду
Увелечение скорости записи в 60 раз меня ну очень обрадовало.
innodb_flush_log_at_trx_commit — Вам кажется, что InnoDB в сто раз медленнее MyISAM? Вероятно, вы забыли изменить значение этого параметра. Значение по умолчанию 1 означает, что после каждой завершенной транзакции (или после изменения состояния транзакции) лог должен быть сброшен на диск. Это достаточно дорогая операция, особенно если у вас нет Battery backed up cache. Многие приложения, особенно те, в которых раньше использовался MyISAM будут хорошо работать при значении 2, который означает, что не надо сбрасывать буфер на диск, а следует отправить его в кэш операционной системы. Лог по-прежнему будет сбрасываться на диск каждую секунду и максимум, что вы можете потерять — это 1-2 секунды записей. Значение 0 обеспечивает более высокую скорость, но и более низкую надежность. Есть вероятность потерять транзакции даже при падении mysql-сервера. При значении равном 2 единственная возможность потерять данные — это фатальный сбой операционной системы.
MDADM, поставляемый вместе с дистрибутивом Debian, содержит задание CRON, которое раз в месяц запускает проверку целостности массива. На больших массивах, размер которых превышает несколько терабайт, такая проверка может занять слишком много времени. Прогресс выполнения проверки можно узнать в /proc/mdstat
# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdb2[0] sda2[1]
1911569360 blocks super 1.2 [2/2] [UU]
[>....................] check = 0.0% (8832/1911569360) finish=7201.4min speed=4416K/sec
md0 : active raid1 sdb1[0] sda1[1]
41941944 blocks super 1.2 [2/2] [UU]
unused devices:
Прервать такую проверку можно так:
# echo idle > /sys/block/md1/md/sync_action
После чего можно проверить, что массив действительно перестал проверяться:
# cat /proc/mdadm
Personalities : [raid1]
md1 : active raid1 sdb2[0] sda2[1]
1911569360 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sdb1[0] sda1[1]
41941944 blocks super 1.2 [2/2] [UU]
unused devices:
Чтобы отменить такую проверку в будущем, нужно установить параметр AUTOCHECK=false в /etc/default/mdadm
Оригинал статьи:
https://blog.tataranovich.com/2012/04/mdadm.html
вторник, 22 мая 2018 г.
Заметка для рейд1 xen 7.x и XCP-NG
по мотивам копипаста и исправления ошибок в мануалах.
базовая таблица диска поле установки xen 7.x, без созданного на стадии установки локального хранилища
Меняем конфигурацию GRUB, чтобы загрузиться с RAID:
sed -i 's/quiet/rd.auto rd.auto=1 rhgb quiet/' /boot/grub/grub.cfg
sed -i 's/LABEL=root-[a-zA-Z\-]*/\/dev\/md0/' /boot/grub/grub.cfg
sed -i '/search/ i\ insmod gzio' /boot/grub/grub.cfg
sed -i '/search/ i\ insmod part_msdos' /boot/grub/grub.cfg
sed -i '/search/ i\ insmod diskfilter mdraid09' /boot/grub/grub.cfg
sed -i '/search/ c\ set root=(hd0,gpt1)' /boot/grub/grub.cfg
Выходим из chroot:
exit
////////Запрашиваем КВМ
Перезагружаемся. В качестве загрузочного диска ставим второй, на котом мы создали RAID. Если что-то пойдет не так — будет шанс загрузиться со «старой» системы и попробовать еще раз.
Если всё прошло удачно, то переписываем таблицу с /dev/sdb на /dev/sda:
sgdisk -R /dev/sda /dev/sdb
И добавляем разделы в RAID:
mdadm -a /dev/md0 /dev/sda1
mdadm -a /dev/md1 /dev/sda2
mdadm -a /dev/md2 /dev/sda3
mdadm -a /dev/md3 /dev/sda5
mdadm -a /dev/md4 /dev/sda6
На всякий случай, и переустанавливаем загрузчик на /dev/sda:
grub-install /dev/sda
Перезагружаемся еще раз, дабы проверить, что все установилось корректно. Ну вот, собственно, и всё. Теперь осталось подключить (или создать) разделы с данными, добавить (если нужно) их в RAID и создать/подключить хранилища: сначала создаем разделы на sda и sdb, потом рейд, и потом дальше по тексту
Когда на компьютере достаточно процессорного времени на исполнение всех процессов, нет необходимости в выставлении приоритетов. Но когда необходимо параллельно запустить несколько процессов, каждый из которых использует всё доступное процессорное время, может очень пригодиться утилита nice.
Команда nice запускает программу с изменённым приоритетом для планировщика задач.
Наибольший приоритет (и наименьшее значение nice) — −20. 19, либо 20 — наименьший приоритет, но это, с другой стороны, самые вежливые процессы. Чтобы посмотреть идентификатор и значение nice нужного процесса в системе, можно воспользоваться командой ps axl.
Пример использования команды nice — запуск ресурсоёмкой задачи в фоновом режиме, так, чтобы она выполнялась, но освобождала часть процессорного времени для других процессов, как только оно становятся им нужно.
Чтобы запустить команду с определённым приоритетом, слева нужно добавить «nice -n значение_nice», либо «nice --adjustment значение_nice» (adjustment — настройка, регулировка).
nice -n значение_nice команда.
Если нужно изменить приоритет уже запущенного процесса, можно воспользоваться командой renice.
renice -n значение_nice id_процесса
Команда renice выводит старый и новый приоритет процесса.
Теперь, зная эти команды, можно управлять процессами так, чтобы определённые задачи выполнялись быстрее в случае, когда сразу много процессов используют всё доступное процессорное время.
Эта заметка поможет при работе с кривыми скриптами криво работающими с БД MySQL
( был образец модуля для джумлы который с базой весом в 30 Мб умудрялся наглухо уложить linux-сервер по IOPS дисковой подсистемы)
Ускоряем MySQL с помощью tmpfs
Tmpfs — временное файловое хранилище во многих Unix подобных операционных системах. Tmpfs пердназначена для монтирования файловой системы, а сама размещается в оперативной памяти вместо физического диска. Использование tmpfs в вашей системе можно увидеть с помощью вывода команды df -h
В tmpfs могут размещатся любые директории, хранящие временные данные и которые можно удалить при перезагрузке системы: /var/lock, /var/run, /tmp и др. Tmpfs используют для уменьшения количества дисковых операций io c целью повышения производительности системы или экономии ресурса твердотельных накопителей.
В процессе работы базы данных MySQL создаются временные таблицы. Место расположения временных таблиц определяется переменной tmpdir в файле /etc/mysql/my.cnf. Если для таких временных таблиц (файлов) не хватает памяти, то начинается активный i/o, создающий нагрузку на дисковую подсистему сервера. А смонтировав папку временных файлов mysql на tmpfs, мы решим проблему проблему производительности базы данных и системы в целом.
На достаточно новых ядрах к директории /dev/shm по умолчанию подмонтирована файловая система tmpfs размером 0,5 объёма физической памяти, которую можно использовать для своих нужд. Если на вашем сервере дело с tmpfs обстоит именно так, нам остается внести правки файл конфигурации MySQL:
$ nano /etc/mysql/my.cnf
Закомментировав предыдущее значение параметра tmpdir, добавляем:
tmpdir = /dev/shm
Перезапускаем базу данных mysql:
$ service mysql restart
Проверяем полученный результат:
$ mysql
mysql> SHOW VARIABLES LIKE 'tmpdir';
+---------------+----------+
| Variable_name | Value |
+---------------+----------+
| tmpdir | /dev/shm |
+---------------+----------+
1 row in set (0.00 sec)
Что я читаю:
