ik maak gebruik van een cronjob on elke 2 uur een bestand te downloaden (csv, of zip)
dit bestand wordt uitgepakt indien nodig, en dan het csv bestand in stukken gehakt (indien nodig)
vervolgens importeer ik de csv op basis van mijn eigen database.
de import bevat voor elke regel een SELECT en indien er een resultaat is, enkele simpele berekeningen en een UPDATE achteraan.
Nou heb ik het probleem dat elke 2 uur m'n CPU omhoog vliegt en ook ALLE geheugen waardoor er op dat moment t/m 5 minuten ofzo vrijwel geen verkeer mogelijk is.
Op dat moment kan ik nieteens met ssh inloggen.
Als ik wel ingelogt ben kan ik op dat moment nieteens 'top' uitvoeren (linux server) dat er geen geheugen beschikbaar is.
Dus mijn vraag is eigenlijk:
-hoe weet ik hoeveel geheugen die cronjobs gebruiken
-hoe kan ik een memory limit geven
ik heb een simpele VPS 2x duo core cpu's en 4GB geheugen
Ik ben bang dat het niet veel uitmaak dat ik upgrade naar 4 CPU en 8GB geheugen?
Dat levert je in result.csv die nieuw toegevoegde regels
en de regels met verschillen.
NB: dit werkt niet per se als de volgorde van de regels kan verschillen. Maar dat is op zich niet erg, want dan krijg je er hooguit wat meer te verwerken.
Hi Ward en Ivo,
Inderdaad zou een diff check functie ook al een hoop schelen, hoewel de csv opmaak nogal verschilt per 'aanbieder'.
Vooral de laatste comment van Ivo moet ik eens naar kijken ! Enorm bedankt daarvoor!
Deze moet ik eens goed testen
De prijzen zijn dynamisch op basis van marges,percentages en 'gemonitorde' concurrentie en als basis de inkoop prijs per hoeveelheid uit de csv welke vaak veranderd.
Ik kijk de logs later ook nog even na, heb even wat anders te doen (werk) dus geen tijd voor prive ;-)
Ik ga een pvp maken voor het verbeteren van de 'prepare import' scripts en importscript
- diff csv file => previous == NEW csv file containing only changes
-- run import if needed at all
- only run update query for import, as only changes are being
Zou ik hierbij alsnog gebruik moeten maken van een 'tijdelijke' tabel ?
Ik denk dat dit al een hele verbetering is qua performance, enorm bedankt voor jullie reacties en tips, ik neem ze zeker allemaal in overweging.
De performance van de gehele server is laatste dagen al aan het verbeteren door ssh en ftp connecties alleen vanuit NL toe te staan, en daarnaast nog fail2ban geïnstalleerd en geconfigureerd. (vanwege vele 'hack-attampts')
ik zou graag nog ietwat hulp willen over de diff command :)
door --new-line-format='%L' raken sommige 'records' uit elkaar getrokken.
1 regel dat vele extra enters ontvangt.
met %l krijg ik alles maar op 1 regel... heb je hier meer ervaring mee ?
Ow die heb ik al opgelost met diff -w -B ......
Is het ook mogelijk om nog 'alleen' de verwijderde regels te vinden?
Vergeet niet wat @Ben zei. Log voor de gein eens alle queries van zo'n job en kijk, naast de hoeveelheid queries, ook eens met EXPLAIN <de query> hoe (in)efficiënt deze zijn en/of hoe lang deze duren.
Heb je echt alle informatie nodig die je ophaalt? Heb je ook middelen die ervoor zorgen dat er geen informatie gewijzigd kan worden tijdens het uitvoeren van deze batch (denk bijvoorbeeld aan een transactie)?
Queries in een loop zijn meestal ook een "red flag".
ik moet idd ook even onderzoeken hoe ik de mysql server beter kan configureren, ben er wel achter dat de mysql service de boel laat hangen... wellicht dat ik toch wel een memory upgrade moet doen.
Voor de update-import haal ik nu geen info meer op, maar het enige wat ik voorheen ophaalde was: id,item_id,price,stock
Deze script(s) zijn de enige die de data kan/mag 'updaten' eindgebruikers kunnen dit niet.
Van alle velden in de csv files gebruik ik ook eigenlijk maar 3 velden.
En ik update er 5
Wat bedoel je met "red flag", ik begrijp dat op moment dat ik een record aanpas, iemand anders niet precies op datzelfde moment dezelfde record zou mogen/kunnen aanpassen, maar in dit geval is dit ook niet mogelijk.
ik moet idd ook even onderzoeken hoe ik de mysql server beter kan configureren, ben er wel achter dat de mysql service de boel laat hangen... wellicht dat ik toch wel een memory upgrade moet doen.
Doorgaans zal de oorzaak niet bij de MySQL service liggen en is er weinig winst te halen met beter configureren. Probeer toch te analyseren, uit te zoeken, waar het probleem ontstaat. Ik lees dat je met nohup werkt en hoeveel processsen onstaan er dan met nohup? Honderden? Het inlezen van een csv of txt is peanuts voor MySQL zeker als je het met LOAD INFILE doet. Er is met deze tooling enorm veel mogelijk qua logica, zie ook de tips an Ivo. Ik vrees toch dat je programmatuur de oorzaak is van de hangup. Hoeveel records moet je inlezen per file?
Ook wanneer de gegevens verspreid of verrijkt moeten worden is het zinvol om eerst in te lezen in een platte tabel en aan de hand daarvan door te werken met updates en/of inserts om te verspreiden of te verrijken. Misschien kan je dan zelfs de php stap eruit werken. Misschien gaan er massa's onnodige gegevens (Selects) van MySQL naar php en wordt de MySQL server daar een beetje moe van ;)
Zorg voor logging in je proces, met timestamps zodat je kan meten. Schrijf de logging naar een /var/log/xxx.log file zodat MySQL daar niet voor belast wordt. Zet eens een tail -f op die logfile om te checken.
