Назад | Перейти на главную страницу

использование памяти во время резервного копирования MySQL gzip

Привет, на сервере EC2 я использую следующее для gzip SQL с другого сервера:

mysqldump -h $HOST -u $UNAME -p$PWORD --single-transaction $1 | gzip -5 > $2_`date +%d`.sql.gz

На данный момент объем данных SQL составляет 560 Мб, а вот информация из "бесплатного":

             total       used       free     shared    buffers     cached
Mem:       2049568    1731356     318212        360     144328     529472
-/+ buffers/cache:    1057556     992012
Swap:            0          0          0

Мне было интересно, как это будет работать, если у меня будет 1 или 2 ГБ данных SQL? Делает ли он gzip во время получения данных, чтобы минимизировать использование ОЗУ? Или он сначала получает все данные SQL, а затем сжимает их?

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

mysqldump -h $HOST -u $UNAME -p$PWORD --single-transaction $1 

На платформах Linux / Unix канал будет использовать достаточно памяти только для блокировки буферизации данных для gzip. gzip буферизует некоторые данные для оптимизации сжатия. Более высокие значения сжатия могут буферизовать больше данных и потребуют больше ресурсов ЦП. Данные из mysqldump очень сжимаемы, так как на выходе есть длинные повторяющиеся строки.

| gzip -5

Перенаправление снова заблокирует данные буфера перед их записью на диск. Большая часть этого будет использовать память, записанную как буферы. Современные файловые системы могут хранить данные в памяти за несколько секунд до их записи на диск.

> $2_`date +%d`.sql.gz

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

Если все это происходило на одном сервере, это могло привести к блокировке файлов mysql из пула буферов. При запросе чтения они обслуживались из памяти, а не с диска. Это может замедлить производительность mysql, пока блоки не будут заменены. Однако в удаленной системе активно читаемые блоки могут быть принудительно вытеснены по мере считывания данных в память.