Пользователи жалуются на то, что система работает медленно во время работы mysqldump

База данных MYSQL (ibdata1) имеет размер 73 ГБ и настроена для работы в качестве выделенного сервера базы данных в операционной системе Windows 2008 для таблиц INNODB. Мы выполняем резервное копирование с помощью mysqldump mysqldump --skip-opt --quick - одиночная транзакция --create-options --extended-insert --disable-keys --add-drop-table --complete-insert - set-charset - сжатие --log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

Файл резервной копии Proddb0635.sql хранится на отдельном сервере от сервера базы данных. Объем оперативной памяти составляет 12 ГБ. Размер буфера INNODB составляет 6 ГБ. Дополнительный mem.pool составляет 32 МБ. Размер Query Cache составляет 2 ГБ. Чистая длина буфера составляет 16 M Макс. размер пакета 1 ГБ.

Версия MySQL 5.0.67.

Когда резервное копирование не запущено, пользователи довольны производительностью.

Когда выполняется резервное копирование, частота попаданий в пул буферов INNODB высока и близка к 100% Нет ожидающих чтения или ожидающих записей. innodb без ожидания равно 0. Загрузка процессора невысока мин. 9% до макс. 15%. Частота обращений в кеше запросов низкая, около 40%, с запущенным или без запуска mysqlbackup. В настоящее время диспетчер задач Windows отображает, что используется 10 ГБ ОЗУ. Стоит ли увеличивать Query Cache, имея только 2 ГБ оперативной памяти? mysqlld-nt занимает 9,2 ГБ ОЗУ, а mysqldump - 5 МБ. Алос, отметил, что размер файла дампа одинаков при наличии или отсутствии опции --compress.

Должен ли я уменьшить размер пула буферов iNNODB?

Спасибо

mysql backup mysqldump mysql-5 dbachacha
источник

Ответы:

В Windows существует известная проблема, заключающаяся в том, что при отправке большого файла на другой сервер вся память выделяется для системного кэша, а не для пользовательских процессов. Вы можете заглянуть в раздел «Физическая память» (МБ) диспетчера задач, чтобы узнать, сколько памяти выделено для системного кэша.

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

mrdenny
источник

Спасибо, Мрденни. Наши диски хранятся в SAN. Это тоже имеет значение?

дбачача

Это проблема, независимо от того, как представлено хранилище. Поскольку хранилище является хранилищем SAN, нет необходимости копировать файлы по сети на другой компьютер. Представьте новый LUN для MySQL Server, а затем сделайте резервную копию на этом компьютере. Если вам нужно передать файлы на другой компьютер для резервного копирования на ленту, используйте SAN. Сделайте привязку к LUN, представьте снимок на сервер резервного копирования, сделайте резервную копию файлов, а затем удалите снимок. Повторите на следующий день. Вероятно, все это можно записать в сценарии

Мрденни

Ваше первое предложение: # не изменились в системном кеше. Что касается LUN, я передам его своим коллегам, которые работают в System & Network Team.

дбачача

Я переместил скрипт резервного копирования для запуска на другом сервере, и это значительно улучшило ситуацию. Кроме того, мы обнаружили, что код приложения не использует одноразовое соединение, а открывает / закрывает несколько функций, сгруппированных в один запрос к серверу базы данных. Кроме того, я обнаружил, что одна карта NIC используется совместно для данных резервного копирования и данных транзакций онлайн. Итак, мы планируем иметь выделенный сетевой адаптер только для резервного копирования. Спасибо.

дбачача

Вот некоторые соображения по поводу улучшения производительности mysqldump, учитывая ваши обстоятельства. Вот ваша команда:

mysqldump --skip-opt --quick - одиночная транзакция --create-options - расширенная вставка --disable-keys --add-drop-таблица --complete-insert --set-charset --compress - -log-error = Proddb0635.err -u root -pjohndoe Proddb> \ devNas \ devNas \ sqlbackup \ LIVE \ db \ Proddb0635.sql

Первое, что я заметил, это то, что вы перенаправили вывод в файловую систему. Там написано «devNas», поэтому я предполагаю, что это сетевое хранилище . Я фанат NAS для резервного копирования, но он должен быть подключен к отдельной физической сетевой карте от рабочего трафика . Возможно, вы не насыщаете пропускную способность, но они все еще конкурируют. Это будет больше проблем из-за флага --quick, так как он сбрасывает каждую строку вместо того, чтобы держать ее в памяти.

Следующее, что я вижу, это то, что вы вызвали --compress. Похоже, что вы используете mysql локально, так как вы не использовали ключ -h. Это может использовать локальный процессор, который не нужен в этом контексте. Нужен ли --compress? Он сжимает только данные между клиентом mysqldump и сервером mysql, а не содержимое файла.

Затем я вижу, что вы используете флаг --single -action. Это вызовет дополнительный процессор, так как он тестирует каждый выбор как часть mysqldump.

Это не имеет ничего общего с производительностью, но вы используете --disable-keys, который работает только на MyISAM ( руководство ).

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

randomx
источник

Да, я проверил у администратора сети и системы. Это сетевое хранилище. Я могу попробовать перенести mysqldump на другой сервер. Кроме того, теперь для меня стало понятным использование --compress. В руководстве сказано, что --compress работает с клиентом и сервером, но я поставил его, чтобы посмотреть, будет ли это иметь значение. Какого рода данные передаются между клиентом, который запускает mysqldump, и сервером базы данных mysql. Данные передаются между сервером базы данных mysql и devNas. В документации и книге MySQl «Проектирование и настройка базы данных» предпочитается использование одной транзакции для таблиц INNODB.

дбачача

Я рад, что это помогает. С наилучшими пожеланиями.

randomx

Здесь мне нужна помощь, чтобы понять следующий сценарий: База данных mysql находится на сервере A. mysqldump работает на сервере B, который создает дамп данных на сервере C. У нас есть выделенный сетевой адаптер с сервера A на сервер C. Это правильно? Я не был уверен, что вчера вечером mysqldump работал на сервере A. Я хотел бы запустить его на другом сервере, чтобы уменьшить нагрузку на процессор.

дбачача

mysqldump - это «клиентская утилита», означающая, что вы можете запустить ее с любого хоста, у которого есть права доступа к таблицам в базе данных. Стратегия для вас будет запускать mysqldump из оболочки сервера C для таблиц сервера A. Конечно, вам придется предоставить доступ с сервера C к схеме, которую вы хотите сбросить.

randomx

НАБЛЮДЕНИЕ № 1

Вот что следует иметь в виду при выполнении mysqldump против InnoDB.

Независимо от того, какие грязные страницы существуют в пуле буферов InnoDB, они должны быть сначала записаны на диск. Mysqldump вызовет сброс таблицы InnoDB, в которой все еще есть грязные страницы.

Существует опция сервера, которая называется innodb_max_dirty_pages_pct . Значение по умолчанию 75 - MySQL 5.5 и 90 в версиях MySQL до 5.5. В производственной среде можно оставить это число равным значению по умолчанию.

Чтобы увидеть, есть ли у вас много грязных страниц в пуле буферов InnoDB, запустите:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty';

Кстати, страница 16K, как показывают из этого:

SHOW GLOBAL STATUS LIKE 'Innodb_page_size';

Когда дело доходит до InnoDB и mysqldump, вы можете уменьшить это число при двух обстоятельствах.

ОБСТОЯТЕЛЬСТВО 1: Установите постоянно 0

Просто добавьте это в my.ini:

[mysqld]
innodb_max_dirty_pages_pct=0

Это сделает буферный пул InnoDB обедненным и средним. Шаг очистки сбрасываемой таблицы InnoDB будет быстрым, потому что несколько грязных страниц, насколько это возможно (возможно, 0), должны быть очищены, прежде чем mysqldump сработает с ним.

Единственный недостаток - если вы используете mysqldump из базы данных с интенсивным трафиком, может быть меньшее увеличение операций ввода-вывода при записи из-за более частой очистки грязной страницы. Вы можете определить, так ли это без перезапуска MySQL, запустив это:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

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

SET GLOBAL innodb_max_dirty_pages_pct = 90;

ОБСТОЯТЕЛЬСТВО 2: Установите его в 0 примерно за 1 час до mysqldump

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Запустите mysqldump

SET GLOBAL innodb_max_dirty_pages_pct = 90;

НАБЛЮДЕНИЕ № 2

У вас есть --complete-insert как опция mysqldump. Это будет включать имена столбцов в каждое описание INSERT перед предложением VALUES. Даже с параметром --extended-insert в каждом пакете вставляемых строк имена столбцов отправляются в mysqldump. Вы можете уменьшить количество байтов, отправляемых mysqldump, удалив --complete-insert.

РЕКОМЕНДАЦИЯ

Если у вас есть другой Windows Server, который можно настроить в качестве ведомого, делайте mysqldumps от этого ведомого, а не от рабочей машины.

RolandoMySQLDBA
источник

Спасибо. Я забыл упомянуть, что пользователи жалуются, что «сохранить» занимает больше времени, чем читать. Я немедленно осуществлю ваше замечание № 2. Мне определенно нравится ваша рекомендация иметь раба и затем брать mysqldump от раба.

дбачача

innodb_buffer_pool_dirty_pages не был слишком высоким перед началом резервного копирования. Это около 9 до макс. 196. Master-Slave тоже хорошая рекомендация.

дбачача