A
A
Alexander2021-06-06 01:16:14
MySQL
Alexander, 2021-06-06 01:16:14

DB dump is slowly uploading - what to do?

Subject. The dump size is ~4GB. Filled up for about 3 hours. consuming all the memory (16GB).
I interrupted the process, restarted the muscle. the same story. The hour is already up. Gobbled up 6 GB of memory.

At the same time, I took a vpsk with 2GB of RAM on debian and tried it there - 18 minutes and the database was flooded.

True, on the server where the HDD is flooded, but I installed iostat and see in% util 8 - it seems that it's not about slow disks.
Where to dig?

UPD:
In the muscle logs I see something like this:

2021-06-05T23:26:05.896772Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4935ms. The settings might not be optimal. (flushed=932 and evicted=0, during the time.)
2021-06-05T23:36:02.805369Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4061ms. The settings might not be optimal. (flushed=1305 and evicted=0, during the time.)
2021-06-05T23:38:05.597404Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4544ms. The settings might not be optimal. (flushed=1013 and evicted=0, during the time.)
2021-06-05T23:38:18.492979Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4835ms. The settings might not be optimal. (flushed=1313 and evicted=0, during the time.)

Answer the question

In order to leave comments, you need to log in

1 answer(s)
I
Ivan Shumov, 2021-06-06
@inoise

The fact that disk utilization is low does not reflect its performance in any way. HDDs are sequential write only and cannot deliver any reasonable performance today. SDDs allow you to perform parallel write operations across the entire disk, and HDDs are limited by many parameters, so neither the absence of indexes nor zero traffic to the database will save here. The maximum that can be compared is the configurator of two databases for a buffer, but no more

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question