Mysqlk gebruikt binnen 10 min 210 vrije diskspace centos 7
Als ik mijn centos 7 systeem met mysql laat draaien, dan eet hij binnen 10 min 10 mijn vrije diskspace op van rond de 210GB.
Als ik mysql stop zet dan krijg ik alles weer terug.
Hoe kan dit goed gedebugged worden?
Ineens gebeurt dit vandaag terwijl er niets rigoreus veranderd is.
Hoe kan ik het beste dit debuggen?
Heb je al eens een analyze op je databasetabellen losgelaten?
Gewijzigd op 29/04/2022 14:26:58 door - Ariën -
Dan doe ik mysqld stop dan heb ik alle ruimte weer terug en begin het weer. Server opnieuw opgestart, zelfde.
Ik lees wel in directadmin een virtuele map, wat hier o.a. ook beschreven staat.
https://www.versio.nl/forum/7107-vreemde-virtuele-map
iets heel raars aan de hand
Toevoeging op 29/04/2022 16:17:18:
Ik heb bij 1 gebruiker via directadmin het volgende staat als ik naar total disk usage ga: Total Disk Usage (MB)
/etc/virtual/xxxxxxxx.nl/majordomo
Ik heb deze gebruiker op suspend gezet, en nu gebeurd het niet meer. Mar hoed los ik dit op?
Kan je niet met top achterhalen wat er gebeurt? Als het bij een bepaalde gebruiker is, dan kan het een zware query zijn, denk ik?
probeer dit eens in de MySQL-cli?
show processlist;
je kan ook de slow query log aanzetten.
Gewijzigd op 29/04/2022 16:34:47 door - Ariën -
Naar welke map moet ik zoeken?
Toevoeging op 29/04/2022 16:59:56:
Ik zie een bepaalde query in processlist :
"SELECT
*, v.id as wid
FROM vest.."
Deze word niet eens uitgevoerd, omdat niemand op die site sit. En dit word ruim 60 keer uitgevoerd. Het is alsof een bot ofzo dit uitvoert.
Toevoeging op 29/04/2022 17:10:52:
Ik denk dat ik het probleem gevonden heb. Ik denk ndat het een bot is die van een url met GET query parameters oneindig veel zoek opdrachten laad. Dit maakte de server overvol.
Een spider bot oid.
Ik heb van get een post gemaakt in de zoekquery en heb dit probleem nu niet meer.
De processes blijven dan ook lopen.
Maar als ze de bot aanpassen naar POST? via curl bijv of een click triggert via een browser dan komen ze er ook mee weg, . Is er een manier om dit goed te beveiliger?
Het kan ook een cronjob zijn.
Zo had ik ook eens een cronjob die wat bij een API vandaan haalde via cURL. Alleen zat er een bug in cURL die gzip niet goed kon verwerken, en juist die site ging gzip gebruiken. Resultaat, het geheugen werd volgepropt met data die niet verwerkt kon worden, en 's nachts lag mijn server op zijn gat.
Gewijzigd op 29/04/2022 21:15:55 door - Ariën -