Majordomo heeft niks te maken met MySQL, en is onderdeel van een prehistorische mailing-list manager.
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;
in de processlist krijg ik 40 mysql queries van die gebruiker als ik hem op unsuspend zet, en dat word de ruimte opgevreten. Heel snel. Snap er niks van omdat dit jaren goed gewerkt heeft.
Naar welke map moet ik zoeken?
[size=xsmall]Toevoeging op 29/04/2022 16:59:56:[/size]
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.
[size=xsmall]Toevoeging op 29/04/2022 17:10:52:[/size]
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.
Nou de processes bleven erin staan , ik denk dat die bot zo 10 requests per seconde laat draaien. In de processlist stonden er elke seconde weer een prcess erbij totdat hij op 90 zit en dat is mijn server vol.
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?
Ga eerst eens na welk script dit is. Als het die van een klant is zou ik niet zomaar aan dingen van hem rommelen.
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.
