hangende datasqk

[snaaps]

Al enige tijd hebben wij te kampen met een hangende datasqk.
Dit gebeurd een paar keer per dag en de aplicatie bijft soms wel een half uur hangen.
Dit resulteerd dan direct in een hoge serverload 3+

Nu killen wij wel elke keer de aplicatie echter blijft het toch raar dat dit maar blijft gebeuren. Het zijn geen vaste tijden, de ene keer om 5 uur dan weer om 6 uur (bijvoorbeeld)

Op het forum van da wordt je ook niks wijzer en de suppport afdeling van DA kan mij helaas niet verder helpen.

Nu vraag ik me af of meerdere gebruikers hier last van hebben en of er mischien een oorzaak bekend is zodat we het probleem kunnen aanpakken.

Ik heb er zelfs al aan zitten denken om de aplicatie gewoon uit te zetten, maar ja dat is natuurlijk wel erg extreem.

[Icheb]

dataskq uitzetten?

Niet doen... Het is de DA cron manager (althans, zo kan je het zien).
Het probleem ken ik niet, maar probeer eens, als het gebeurd een dumpje te maken van de tasklist.
Uit mijn hoofd: /usr/local/directadmin/data/task.<nogwat>

De filenaam ervan veranderd als hij ermee bezig is, maar omdat ik op dit moment even haast heb, kan ik even geen simulatie voor je maken.

Check daarnaast even het taskq log, om te zien wat hij aan het doen is/was.

[snaaps]

Ok inmiddels zijn we iets verder:

wanneer ik de volgende commando uitvoer blijft dataskq hangen en loopt de servload behoorlijk op:
# echo "action=tally&value=all" >> /usr/local/directadmin/data/task.queue

Vervolgens kill ik dataskq:
# killall -USR1 dataskq

Serverload is nu back to normal.

dan kijken we in:
/var/log/directadmin/errortaskq.log

en lezen elke keer na de hangende dataskq de volgende error:

2006:04:16-12:32:01: Error renaming Q file to tmp Q file: Unable to move /usr/local/directadmin/data/task.queue to /usr/local/directadmin/data/task.queue.tmp: <br>
A directory component in oldpath or newpath does not exist or is a dangling symbolic link.<br>

Tot op heden heb ik hier nog geen verklaring voor en/of een oplossing.

[Icheb]

Bij een tally wordt er behoorlijk wat gedaan;
Ten eerste worden alle logs gerotate, daarnaast worden diezelfde logs gebruikt om het dataverkeer te tellen en webalizer te laten draaien.
Daarnaast zal ook even de quota's opnieuw bepaald worden.

De foutmelding zegt mij niets, al lijkt het me wel logisch, want je killt het dataskq proces, deze laat de task.queue.tmp achter als hij er nog mee bezig is (zodat er niet nog een instance van dataskq tegelijk kan draaien).

De serverload hoort hierbij trouwens ook behoorlijk op te lopen, zeker op servers met veel sites. Misschien eens kijken wat er gebeurd op een rustig moment, als je het aanzet, en het systeem de tijd geeft om alles te laten doen.
Dit hoort namelijk dagelijks te gebeuren (aldus /etc/cron.d/directadmin (als ik me niet vergis)).

Loop anders de crontab van DA even langs, dataskq hoort enkel om 10 minuten over 12 's nachts te gaan tally'en.

[snaaps]

Ok, heb even de cron nagezocht.
de tally wordt nu om de 4 uur uit gevoerd.
Nu ik er zo aan denk kan ik me herrineren dat ik dit een half jaar gelden heb aangepast zodat de stats vaker worden geupdate.
Deze heb ik nu op 10 over 12 gezet.

Tevens heb ik een klant gedisabled die voor 3GB aan bestanden had staan in submap.submap/submap/etc/etc.... in het totaal telde deze mappen miljoenen bestanden. Deze bestanden hebben de gebruiker apache en worden dus niet in mee gerekend in de gebruikte data van de gebruiker.
omdat het hier dus gaat om miljoenen bestanden is het niet zo gek dat tally er zo lang over doet.
(rm -rf deed er al 40 minuten over om het te verwijderen, backup is wel beschikbaar hoor)

De bestanden zijn afkomstig van een soort zoekmachine, je weet wel al zoek je op google naar bijvoorbeeld nokia 9500 dan kom je weer tercht op zo,n *** zoekmachine met *** resultaten.
waaneer gaat google deze pagina's een disablen in hun zoek resultaten?

[Icheb]

Tevens heb ik een klant gedisabled die voor 3GB aan bestanden had staan in submap.submap/submap/etc/etc....

Die heeft iedereen wel .

Ben het op systemen waar wij op gewerkt hebben voor collega providers al een aantal maal tegen gekomen.

Zeker als ze door een script gemaakt worden is het erg fijn omdat het dan inderdaad allemaal ge-owned wordt door de apache user. Al staat me iets bij dat er een soort van 'du' uitgevoerd wordt op html dir's ipv quota's, maar pin me er niet op vast.

De laatste vraag kan ik niet echt beantwoorden, maar goed. Als het bij google wordt aangegeven, zullen ze het wel blokkeren. Maar de vraag blijft dan open of je als provider het recht hebt om dat te doen (of als klant, aangezien er wel een AV aan vast zal zitten).

[snaaps]

deze klant had al een paar sterretjes achter zijn naam staan.
Zojuist is de klant op de hoogte gebracht, en zullen we op zoek gaan naar een oplossing.