Het probleem is typerend voor een MySQL-instantie waar u veel wijzigingen in de database hebt. Door uw 5GB-import uit te voeren, maakt u snel vuile pagina's. Terwijl vuile pagina's worden gemaakt, is de thread voor het opschonen van pagina's verantwoordelijk voor het kopiëren van vuile pagina's van het geheugen naar de schijf.
In jouw geval neem ik aan dat je niet altijd 5GB importeert. Dit is dus een uitzonderlijk hoge snelheid van gegevensbelasting, en het is tijdelijk. U kunt de waarschuwingen waarschijnlijk negeren, omdat InnoDB geleidelijk aan de achterstand inhaalt.
Hier is een gedetailleerde uitleg van de interne elementen die tot deze waarschuwing hebben geleid.
Eenmaal per seconde scant de paginaopruimer de bufferpool op vuile pagina's die van de bufferpool naar de schijf moeten worden gespoeld. De waarschuwing die u zag, laat zien dat er veel vuile pagina's moeten worden gewist, en het duurt meer dan 4 seconden om een batch ervan naar de schijf te spoelen, terwijl het dat werk in minder dan 1 seconde zou moeten voltooien. Met andere woorden, het bijt meer af dan het kan kauwen.
Je hebt dit aangepast door innodb_lru_scan_depth . te verkleinen van 1024 naar 256. Dit vermindert hoe ver in de bufferpool de thread voor het opschonen van pagina's naar vuile pagina's zoekt tijdens de cyclus van één keer per seconde. Je vraagt hem om kleinere happen te nemen.
Houd er rekening mee dat als u veel instanties van de bufferpool hebt, het doorspoelen meer werk zal doen. Het bijt innodb_lru_scan_depth . af hoeveelheid werk voor elke instantie van de bufferpool. Het is dus mogelijk dat u per ongeluk dit knelpunt hebt veroorzaakt door het aantal bufferpools te vergroten zonder de scandiepte te verkleinen.
De documentatie voor innodb_lru_scan_depth zegt:"Een instelling die kleiner is dan de standaardinstelling is over het algemeen geschikt voor de meeste werkbelastingen." Het klinkt alsof ze deze optie standaard een te hoge waarde hebben gegeven.
U kunt een limiet stellen aan de IOPS die wordt gebruikt door achtergrondspoeling, met de innodb_io_capacity en innodb_io_capacity_max opties. De eerste optie is een zachte limiet op de I/O-doorvoer die InnoDB zal vragen. Maar deze limiet is flexibel; als het doorspoelen achterblijft bij de snelheid waarmee nieuwe vuile pagina's worden gemaakt, zal InnoDB de doorspoelsnelheid dynamisch boven deze limiet verhogen. De tweede optie definieert een striktere limiet voor hoe ver InnoDB de spoelsnelheid zou kunnen verhogen.
Als de snelheid van het doorspoelen de gemiddelde snelheid van het maken van nieuwe vuile pagina's kan bijhouden, dan komt het goed. Maar als u consequent vuile pagina's sneller maakt dan ze kunnen worden leeggemaakt, zal uw bufferpool zich uiteindelijk vullen met vuile pagina's, totdat het aantal vuile pagina's groter is dan innodb_max_dirty_page_pct van de bufferpool. Op dit punt zal de spoelsnelheid automatisch toenemen en kan de page_cleaner opnieuw waarschuwingen sturen.
Een andere oplossing zou zijn om MySQL op een server met snellere schijven te zetten. U hebt een I/O-systeem nodig dat de doorvoer aankan die vereist is voor het opschonen van uw pagina's.
Als u deze waarschuwing de hele tijd ziet bij gemiddeld verkeer, probeert u mogelijk te veel schrijfquery's uit te voeren op deze MySQL-server. Het is misschien tijd om uit te schalen en de schrijfbewerkingen te verdelen over meerdere MySQL-instanties, elk met hun eigen schijfsysteem.
Lees meer over de pagina opschoning:
- Introductie van page_cleaner-thread in InnoDB (gearchiveerde kopie)
- MySQL-5.7 verbetert DML-georiënteerde workloads