Hallo,
Na enkele gesprekjes met wat DPC crew blijkt dat ik in mijn vorige thread een beetje hard van leer trok over MFs. Dit was meer een toevaligge samenloop van subteamsflushes als ik het goed begrepen heb. Bij deze dus daarover mijn excuses!
Maar sparen is gewoon niet de bedoeling van de dailystats. Onze master-server is geoptimaliseerd voor het snel verwerken van blokjes uit 1 of 2 spaces, maar in een flush van 2 mnd in 1 keer zitten wel 20 spaces. En die zijn op de master allemaal 32Mb (2^28) groot en dus moet de master praktisch random bitjes vullen in 20*32Mb in-core memorymapped bitmaps. Da's best veel geheugen. Daarbij moet er gelogd worden en normale connecties met de fullservers opengehouden worden. Daarom komt er dus een backlog.
Een backlog die trouwens helemaal niet zo erg is, want de blocks komen uiteindelijk wel aan, hoor. alleen niet vandaag. En dat garanderen wij ook niet. Mijn reactie van gisteravond was dan ook heftiger omdat wij wel uitgemaakt worden voor 'wat kunnen ze wel'. Er is echt meer load op die server dan je je kunt voorstellen en dit soort beledigingen trek ik slecht. Maar ik zag dat de betreffende persoon (Burat) al zijn excuses daarvoor had aangeboden dus ook dat probleem is opgelost.
Ik hoop dat ik zo het probleem van het in 1 keer flushen van veel (oude) blokjes heb uitgelegd. De master kan, als er alleen blocks uit ca. 4 spaces geflushed worden, een load van ver over de 1000 Gkeys/s aan, bleek uit recente testen, dus de hardware is afdoende.
Daarbij maken ook veel mensen onterecht geen scheiding tussen master server en stats server.
De master is een K6-350 met 512Mb intern en veel disk, en da's genoeg hardware. (tot we aan de 1000 Gkeys zitten dan)
De stats server wordt een Quad Xeon450, 1Gb intern, 100Gb harddisk RAID5 en 20Gb mirror raid. Die is al up en sybase draait al. Het is dat de stats mensen (dB, Nugget) net een nieuwe baan hebben en het erg druk hebben, dus daarom duurt het wat langer. Maar de huidige statsserver (tally) doet het dan ook nog redelijk goed. In ieder geval hebben megaflushes geen invloed op de snelheid van de statsserver, alleen invloed op de performance van de master server.
Ik hoop hiermee enige onduidelijkheid te hebben weggenomen, en dat ook niet DPC-crew members, die mij misschien niet kennen, heb kunnen overtuigen van het feit dat niemand kwaad in de zin heeft. En als laatste nog een verontschuldiging over de .plan update die jullie beschuldigde. Ik kan niet spreken voor anderen, maar ik vond het persoonlijk geen goede actie, die .plan.
Groetjes,
Ivo
Na enkele gesprekjes met wat DPC crew blijkt dat ik in mijn vorige thread een beetje hard van leer trok over MFs. Dit was meer een toevaligge samenloop van subteamsflushes als ik het goed begrepen heb. Bij deze dus daarover mijn excuses!
Maar sparen is gewoon niet de bedoeling van de dailystats. Onze master-server is geoptimaliseerd voor het snel verwerken van blokjes uit 1 of 2 spaces, maar in een flush van 2 mnd in 1 keer zitten wel 20 spaces. En die zijn op de master allemaal 32Mb (2^28) groot en dus moet de master praktisch random bitjes vullen in 20*32Mb in-core memorymapped bitmaps. Da's best veel geheugen. Daarbij moet er gelogd worden en normale connecties met de fullservers opengehouden worden. Daarom komt er dus een backlog.
Een backlog die trouwens helemaal niet zo erg is, want de blocks komen uiteindelijk wel aan, hoor. alleen niet vandaag. En dat garanderen wij ook niet. Mijn reactie van gisteravond was dan ook heftiger omdat wij wel uitgemaakt worden voor 'wat kunnen ze wel'. Er is echt meer load op die server dan je je kunt voorstellen en dit soort beledigingen trek ik slecht. Maar ik zag dat de betreffende persoon (Burat) al zijn excuses daarvoor had aangeboden dus ook dat probleem is opgelost.
Ik hoop dat ik zo het probleem van het in 1 keer flushen van veel (oude) blokjes heb uitgelegd. De master kan, als er alleen blocks uit ca. 4 spaces geflushed worden, een load van ver over de 1000 Gkeys/s aan, bleek uit recente testen, dus de hardware is afdoende.
Daarbij maken ook veel mensen onterecht geen scheiding tussen master server en stats server.
De master is een K6-350 met 512Mb intern en veel disk, en da's genoeg hardware. (tot we aan de 1000 Gkeys zitten dan)
De stats server wordt een Quad Xeon450, 1Gb intern, 100Gb harddisk RAID5 en 20Gb mirror raid. Die is al up en sybase draait al. Het is dat de stats mensen (dB, Nugget) net een nieuwe baan hebben en het erg druk hebben, dus daarom duurt het wat langer. Maar de huidige statsserver (tally) doet het dan ook nog redelijk goed. In ieder geval hebben megaflushes geen invloed op de snelheid van de statsserver, alleen invloed op de performance van de master server.
Ik hoop hiermee enige onduidelijkheid te hebben weggenomen, en dat ook niet DPC-crew members, die mij misschien niet kennen, heb kunnen overtuigen van het feit dat niemand kwaad in de zin heeft. En als laatste nog een verontschuldiging over de .plan update die jullie beschuldigde. Ik kan niet spreken voor anderen, maar ik vond het persoonlijk geen goede actie, die .plan.
Groetjes,
Ivo
/u/858/logo_rgb60.png?f=community){kind=logo}
/u/20018/wessie.JPG?f=community)
Wij zijn momenteel de grootste, maar ze zijn niet echt blij met ons. 
Het liefste zouden ze AT op #1 hebben. Dus laten we er mooi mee kappen en ze hun zin geven !:strip_icc():strip_exif()/u/4622/crop665491830651c_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/12582/me_50x502.jpg?f=community)
op :strip_icc():strip_exif()/u/6685/crop61330c2db3693_cropped.jpg?f=community)
:strip_exif()/u/6310/pic1.gif?f=community)
:strip_icc():strip_exif()/u/5326/crop5ff8e3fc691c6_cropped.jpeg?f=community)
:strip_exif()/u/3319/GoT-Logo%2520-%2520Webicon.gif?f=community)
. /u/1083/icon.png?f=community){kind=icon}
:strip_icc():strip_exif()/u/10029/avatar.jpg?f=community){kind=avatar}
:strip_exif()/u/851/pb_logo.gif?f=community){kind=logo}
:strip_icc():strip_exif()/u/12674/dscn2951_s2.jpg?f=community)
:strip_icc():strip_exif()/u/1892/gotlogo1.jpg?f=community)
maar beetje zinloos gezien het doel dat je voor ogen hebt
:strip_icc():strip_exif()/u/1229/crop5f993f51c8e2d_cropped.jpeg?f=community)
)
