Пользователи жалуются на то, что система работает медленно во время работы 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?

Спасибо

— 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 тоже хорошая рекомендация.

— дбачача