Userbase server onderhoud

[Sub Zero]

Het is weer de tijd van 't jaar. De userbase server zal op 2009-12-11 (morgen dus) een upgrade krijgen. De werkzaamheden zouden starten rond 10u en zouden niet langer dan 1u mogen duren. De server wordt geupgrade van Debian Etch naar Lenny met daarbij behorende updates van de web- en databaseserver.

[Sub Zero]

De update is voltooid!

Voor:

Code: Selecteer alles

walhalla:~# uptime
 11:05:12 up 450 days, 21:10,  2 users,  load average: 0.75, 0.51, 0.59

Na:

Code: Selecteer alles

walhalla:~# uptime
 11:21:31 up 12 min,  1 user,  load average: 0.58, 0.76, 0.52

Happy userbasing

[devilkin]

Wat een service..

[meon]

Op een kwartier geupdate of wat. Wow.

[gr4vity]

Nice work Sub!

[Patje]

Ik merk vandaag dat het soms nogal traag gaat om een topic te openen/bekijken, was vroeger nooit zo ....
Dus blijft soms hangen voor een tiental seconden en soms gaat het wel binnen de seconde open.

[TomG]

Da's omdat ge te snel zijt.

[Sub Zero]

Ik merk vandaag dat het soms nogal traag gaat om een topic te openen/bekijken, was vroeger nooit zo ....
Dus blijft soms hangen voor een tiental seconden en soms gaat het wel binnen de seconde open.

Had ik ook gemerkt net na het herstarten van de server. Dus ik dacht dat het aan het feit lag dat de caches leeg waren enzo. Komt het nog altijd voor en zijn er nog mensen die hier last van hebben?

[driesve]

Mij is het in ieder geval nog niet opgevallen.
Alles lijkt even snel te gaan als vroeger.

[VOiD]

Ik wil hier nu ni de pessimist uithangen maar wanneer verdwijnt de 'Beta' uit het logo ? Dat staat er nu toch al wel even...

[Goztow]

Als de speedtest terug is?

[Patje]

Die is allang weg (al meer dan een jaar?) de meesten hebben die hoop al opgegeven denk ik.
genoeg alternatieven.

[Goztow]

Kheb het probleem ook al opgemerkt.

[ Post made via mobile device ]

[meon]

Ik wil hier nu ni de pessimist uithangen maar wanneer verdwijnt de 'Beta' uit het logo ? Dat staat er nu toch al wel even...

Hmz

I know, ik heb die beta nooit durven weghalen omdat we nooit alle aanmeldproblemen opgelost hebben gekregen. Andere oplossingen (Rokbridge, nieuwere versie van JFusion, ...) leken niet te helpen, dus zijn we nu aan het kijken naar optie 4: laten we eens opnieuw beginnen

Speedtest zitten we beetje met 2 problemen in de huidige situatie:
a) De speedtest an sich: De oude was/is java-gebaseerd en is niet meer onderhouden. Zijnde: oude code, oude libraries en ik ken niks van java. Suggestie was om dan net zoals Ookla en speed.io een flash/flex-gebaseerde speedtest te maken, maar het ontbreekt aan de concrete uitwerkingen hiervan.
b) Integreren met Joomla (de front-end-site). Ik doe vast iets heel erg fout, maar development in Joomla is niet zo eenvoudig als ik dacht. 't Is me gelukt om iets te maken als m'n 'River of News', maar van zodra ik iets met interactiviteit wil maken wordt het zodanig complex omdat de omgeving niet helemaal bekend is. Hadden we nu voor Drupal gekozen bestond dat probleem evenzeer.

Dusjah, 'beta' omdat bijlange niet alle functionaliteit er in zit die we ooit hadden (hey, niemand die iets zegt van de providertabel? ) en we nog degelijk enkele technische problemen hebben.

Goeie nieuws is dat er terug beweging in de trein zit en we met 'Userbase wave 3', de voorbereidingen zijn grotendeels gebeurd, de uitwerking is in gang gezet

[meon]

Oké, ik heb net een moment van 'traagte' van Userbase kunnen vastleggen ('t is akelig hoor, 't is een phpBB-query die 1,5 min lang heel veel tabellen gelocked houdt en bijgevolg een lange wachtrij oplevert). Het gekke is dat deze niet in de 'slow query'-log voorkomt, dus ik weet niet zeker wat er aan de hand is...

[Goztow]

Open deur intrappen: het ligt zeker niet aan het forum, want dat werkte perfect voorheen. Tenzij je mss tegelijkertijd hebt geupdate naar 3.0.6?

[meon]

All signs point to the RSS-feed... Hmz...

[flt]

Ben ik nu de enige die daar geen last van heeft? Of is het vooral in de piekuren 'savonds?

Pageload zit hier tussen de 0.4s - 1.5s

[meon]

De feed wordt 4x per uur gegenereerd, dus als ge toevallig op de site zijt tussen die momenten in hebt ge er geen last van...

De vertraging bij de query ligt bij "copying to temporary table", wat 99% van de tijd van de query inhoudt... Eens zien hoe de query kan geoptimaliseerd worden...
Momenteel duurt ie 22 seconden, maar aangezien het bereik van de query een halve dag inneemt loopt de data in de query op in de loop van de dag (als er meer gepost is).

[meon]

Query aangepast, de temporary table is van bijna 22000 items tot 53 teruggebracht. Flinke verbetering, maar 't kan nog beter .
Geen idee wat dit aan het gevoel van traagheid gaat doen, maar 't zou al veeeeel beter moeten zijn.

[Limburg]

Had net weer een wachttijd van 40 seconden.

[Uzzi]

Om even terug te komen op de speedtest, is er echt nood aan nog een speedtest ? Ik denk dat er wel ruim voldoende online zijn : speedtest.net, speedtest.telenet.be, ...

Persoonlijk vind ik dat de beheerders/ontwikkelaars van userbase hun schaarse tijd niet moeten steken in een tool waar er al verschillende goede van beschikbaar zijn. Ik denk dat ze heus nog wel andere katten te geselen hebben. Links naar een paar deftige speedtesten is voor mij ruimschoots voldoende.

My 2 cents

[cloink]

Het enige voordeel aan een "eigen" speedtest is dat het meer nieuwe bezoekers trekt. Als er iemand op een ander forum zijn resultaten kan posten en het Userbase-logo en/of link is duidelijk "in beeld", dan zorgt dat voor extra traffic uiteraard. Idem voor de eventuele statistieken en "top"-lijstjes die hier uit zouden kunnen voortvloeien. Misschien toch wel de moeite waard?

[gr4vity]

Inderdaad, zoals cloink aangeeft heeft een eigen speedtest als voordeel dat we statestieken per provider etc kunnen opbouwen.

[Goztow]

Speedtesten kunnen ook gelinkt zijn aan de forum users en dan bouw je toch wel leuke statistieken op die een meerwaarde kunnen betekenen.

[Sensei Zeon]

Had net weer een wachttijd van 40 seconden.

We hebben zo goed als zeker de snoodaard te pakken die voor de latency zorgt, nu nog zo oplossen dat alles blijft werken

[Sub Zero]

Door het gefoeffel met de MySQL server is blijkbaar de SMTP server (postfix) ook onderuit gegaan gisterenavond. De reden hiervoor is dat postfix de authenticatiegegevens uit MySQL haalt (virtual users). Normaal zou deze vanzelf moeten recoveren zodra MySQL terug beschikbaar is, maar het was blijkbaar niet het geval. Als jullie nu plots veel userbase email binnen krijgen: Skoezie!

[meon]

Niemand hier met (veel) MySQL-kennis?
De query die voor het probleem zorgt verliest heel z'n tijd bij "Copying to tmp table". 99,7% van de execution time gaat daar naartoe.
't Lijkt me geen indexen of sortering of join-probleem...

[Astralon]

Doe eens explain myquery waar myquery de query is die je verdenkt.
Ergens verwijzing naar "Using temporary" ?

[Sasuke]

Niemand hier met (veel) MySQL-kennis?
De query die voor het probleem zorgt verliest heel z'n tijd bij "Copying to tmp table". 99,7% van de execution time gaat daar naartoe.
't Lijkt me geen indexen of sortering of join-probleem...

Meon, de tmp Table is volgens mij in het geheugen geladen by een default MySQL config. Is er een memorylimiet op mysql ingesteld of zit de servers soms wat te veel te swappen ?

grtz,
Sasuke

[meon]

Ik heb 't idee dat 'm diskbased wordt, maar dat zou toch pas vanaf 2 MB mogen zijn?
In bijlage wat statistieken ivm de query.

[Astralon]

Mag ik de query zelf eens zien?
En welke versie van MySQL gebruiken jullie?
Wat is er veranderd (m.b.t. MySQL) tijdens de upgrade?

[meon]

MySQL is van 5.0.32 naar 5.0.51a of zo gegaan
De query:

Code: Selecteer alles

SELECT t.topic_id, t.topic_title, t.topic_last_post_id, t.forum_id, p.post_id, p.poster_id, p.post_time, u.user_id, u.username, p.post_text, p.post_id, f.forum_id, f.forum_name, p.forum_id
FROM
  phpbb_topics AS t
  Inner Join phpbb_posts AS p ON p.topic_id = t.topic_id
  Inner Join phpbb_users AS u ON u.user_id = p.poster_id
  Inner Join phpbb_forums AS f ON f.forum_id = t.forum_id
WHERE
  t.forum_id NOT IN ( 1,2,3,4 )
  AND p.post_time > (SELECT unix_timestamp(CURRENT_TIMESTAMP ) -43200 )
  AND t.topic_status <>2
ORDER BY p.post_id DESC
LIMIT 25

[Astralon]

Zonder de details te kennen is het moeilijk om de query verder te optimalizeren.
Copying to tmp table is per definitie een moeilijk probleem.
Ik hoop/verwacht dat de nodige indexen aanwezig zijn.

Dus misschien is de hoeveelheid geheugen die er beschikbaar is voor tijdelijke tabellen te klein.
Geef eens de waarden van tmp_table_size en max_heap_table_size.
De maximale grootte van de tijdelijk tabel is het minimum van deze twee waarden.

[meon]

tmp table size 33,554,432
max heap table size 16,777,216

Aangezien alle selecties op ID's (dus keys) gebeuren zou dat allemaal geïndexeerd moeten zijn...

De query eens herschreven met een subselect:

Code: Selecteer alles

select t.topic_id, t.topic_title, t.topic_last_post_id, t.forum_id, p.post_id, p.poster_id, p.post_time, u.user_id, u.username, p.post_text, p.post_id, f.forum_id, f.forum_name, p.forum_id
FROM 
	phpbb_topics  AS t , 
	phpbb_posts AS p , 
	phpbb_users AS u ,
	phpbb_forums AS f 
WHERE 
	p.topic_id in	(SELECT topic_id 
		FROM phpbb_topics
		where forum_id NOT
		IN ( 1, 2, 3, 4 )
		AND post_time > (
		SELECT unix_timestamp(
		CURRENT_TIMESTAMP ) -43200 )
		AND t.topic_status <>2
		)
	AND p.topic_id = t.topic_id
	AND u.user_id = p.poster_id
	AND f.forum_id = t.forum_id
ORDER BY p.post_id DESC
LIMIT 25

De execution time verhuist dan naar 'preparing'...

[Astralon]

tmp table size 33,554,432
max heap table size 16,777,216

Ik ken de specs van de machine niet maar is 16 en 32 MB niet een beetje weinig?
Dit betekent dat tijdelijke tabellen maximaal 16 MB groot mogen zijn alvorens ze naar disk worden geswapt.
Als de hoeveelheid beschikbaar geheugen het toelaat zou ik eens proberen dit te verhogen tot 128 en 256 MB of zelfs 256 en 512 MB.

[meon]

Nu ge het zegt.
Die waarden waren vroeger volgens mij verhoogd en waarschijnlijk is de config dankzij die upgrade terug naar een standaard gezet?
Ik laat het systeembeheer aanpassen
Thx!

[Astralon]

Het zijn inderdaad de default waarden en die zijn op zich al belachelijk zijn want de grootte van tmp_table_size wordt alsnog beperkt door max_heap_table_size.
Dus voor alle duidelijkheid: max_heap_table_size > tmp_table_size en niet omgekeerd !

[Sub Zero]

'k Heb voorlopig volgende waarden in de config file gezwierd:

Code: Selecteer alles

max_heap_table_size 128M
tmp_table_size 64M

Bedankt Astralon! 'k Denk dat ik u ondertussen al vrij veel pinten moet

[Astralon]

Bedankt Astralon! 'k Denk dat ik u ondertussen al vrij veel pinten moet

Laat ons eerst maar eens kijken of het werkt.
Kan ik die pinten omwisselen tegen een glaasje MACALLEN ? En doe anders maar een Cola Zero .