Merge vizibil mai rapid.. dar vorba Dacului..sa vedem in afternoon
Faza e ca mie imi mergea greu si cand erau cativa

Merge muuult mai bine. 13 utilizatori logaţi.

Daniel Forga - 17 Octombrie 2009 10:33 PM

psergiu - 13 Octombrie 2009 08:53 PM

mysqld-ul este criminalul - dă în disc și în cpu rău de tot - scrie într-una.

FSurile sunt montate cu “noatime” sau macar “relatime”?

e o setare banala, dar eficienta (si nimeni nu prea tine cont de ea - old habits die hard…)

http://kerneltrap.org/node/14148

firește.

MySQL este acum mutat pe alt server. (mulțumim încă odată lui jeffe).

Merge mai bine, dar cate odata sacadeaza la afisare.

M-am uitat peste grafice si arata imprsionant. A scazut incarcarea CPU, hardul misca doar la backup, e bine, e foarte bine.

Se incarca si forumul mai bine, se simte diferenta. Bravo Sergiu si sigxcpu! Dau o bere fiecaruia. Daca aveti preferinte pentru ales sau casks, pot trimite.

bautura dupa ce trecem de saptamana viitoare. eu nu pun pret pe datele de week-end, unless compari graficele de week-end intre ele.
astept cu maxim interes sa vad ce comportament avem in timpul saptamanii, deoarece am 2 locuri unde au ramas optimizari de query plan, dincolo de mutarea platformei.
- unul este in zona de afisare generala topicuri (nu imi e clar unde in site, sunt 3 tipuri de query-uri care fac asta si la toate le-am modificat planul de executie.
- al doilea este in “view new posts”, care se executa de fiecare data aproape instantaneu. pe asta cred ca nu-l mai schimb inapoi nici batut

zilele de weekend au un trafic/hituri cu doar 10-15% mai mic decat a weekday. cred ca suntem safe.

Oare ce s-ar întâmpla dacă ar fi flux continuu cu cel puțin 100 de utilizatori , să nu zic 1000 ?

Eu zic ca in acest caz ar fi flux continuu cu cel putin 100 de utilizatori, sa nu zic 1000.

Am ghicit?

Ce ești rău? Normal că nu. Nu, nu ai ghicit domnule. Mai încercăm odată.
Ar afecta cu ceva Xserverul? L-ar încetini, l-ar pune pe butuci, CPU-ul ar fi rău afectat etc…?

ei, acuma se simte ca e mai vioi
si sunt 80 de oameni logati

Atunci le puteti transmite celor de la EE ca, desi forum_id pare un index firesc pe topics, distruge orice plan de executie si ca trebuie scos cu agentii de paza din sistem
Totodata, le puteti spune ca pot intra oricand pe macuser.ro, ca sa mai invete una, alta.

Glumesc, dar realitatea este ca baietii nu prea au habar ce inseamna o baza de date si la ce foloseste ea pe lumea asta (si, sunt sigur, nici pe ailalta).

@sigxcpu: Poți da, te rog, mai multe detalii despre problemele pe care le-ai găsit tu în legătură cu forum_id și baza de date? E de la modul în care au scris ăștia modulul de forum, de la templateurile forumului… care-i vina?

Spun aici, ca poate foloseste si altora:

Generic, indecsii intr-o baza de date trebuie facuti pe coloane ce asigura o distributie cat mai mare a datelor.
Tot generic, daca vezi ca planul de executie nu e cel dorit, fortezi indecsii utilizati din query (asta nu am avut cum sa optimizez).

1. In cazul tabelei de topice, exista un index pe forum_id. Asta duce la un spread de 33 de valori, lucru inutil la cele 20144 de rows (vin cam 610 topics/forum_id ce intra in scan).
Aici am sters indexul pe forum_id si am create urmatorii indecsi: topic_date, last_post_date/topic_date (compus) si sticky/last_post_date/topic_date (compus. sticky are spread prost, dar e ok).
In acest caz, query-urile ce citesc topics “lovesc” in acesti indecsi pe data la order by, unde distributia este foarte buna (pana in ziua in care vor posta mii de oameni in aceeasi secunda ).
Query-ul de aici alege topicele din (aproape) toate valorile lui forum_id (cu WHERE IN), deci un index pe forum_id nu face decat sa strice. Dupa aia, selecta cele mai recente 10 entry-uri.
Mai exact, miscam 20k rows prin procesor si apoi ordonam astia 20k rows dupa data (fara index). Acum se misca 20k rows si se ordoneaza prin indexul de data, ce atrage o distributie foarte buna (aproape 1:1).

2. Search-ul pe “view new posts” alegea tot un index cu distributie proasta, ce ducea la cele n secunde de procesare binecunoscute.
Aici am fortat un index pe “date” (ce apare in WHERE), ce are o distributie excelenta si timpul de executie este de sub 10ms (Mysql arata 0.00).

Renuntarea la indexul forum_id afecteaza in felul urmator:
- toate query-urile simple gen select from topics where forum_id=? duc la un full scan. Nu e o problema deoarece tabela e cached si la distributia lui de 1:610 e posibil ca full scan sa fie mai rapid.
- daca vor fi foarte multe topics, atunci performanta va scadea simtitor si, probabil, optimul va fi atins reconstruind acest index.

Se mai pot face optimizari, cu urmatoarele conditii:
- activarea conditiei de slow query la un timp mai jos de 2 secunde (deja nu mai exista niciun query ce dureaza >=2 secunde si nu mai apare in log).
- modificarea codului EE pentru a putea selecta in varii locuri manual indecsii utilizati pentru query (migalos si infect in cazul unui upgrade ). In acest caz putem reveni la forum_id si forta unde avem nevoie indecsii noi, mentionati mai sus.

Ca o sugestie pe viitor, eu as preindexa cuvintele din post-uri si as folosi acest index la search, pentru a renunta la LIKE ‘%cuvant%’. Asta este absolut ucigator.

Varianta scurta de raspuns este “modul in care au scris astia modulul de forum”

...tu-le indecșii mamii lor…