On 2016-10-28 23:04:54 , Mircea MITU wrote: >> On 28 Oct 2016, at 15:28, Catalin Muresan <[email protected]> wrote: >> >> 2016-10-28 12:56 GMT+01:00 Mircea MITU <[email protected]>: >> >>> Salut >>> >>> am un mysql (percona 5.5 pe un ubuntu 14 lts) ce deserveste mai multe >>> webservere cu o anumita aplicatie web si cateva teste de >>> performanta/fiabiliate/etc care fac GET/POST/etc pe pe anumite URL-uri >>> >>> La URL-urile ce acceseaza mysql-ul, in momentul in care numarul de clienti >>> simultani (pe secunda) atinge ~6000, webserverul intoarce 50x. La cele ce >>> nu acceseaza mysql, ajunge la 10,000 fara probleme (nu am testat peste >>> 10,000 simultani). >>> >>> Cum pot identifica cine are aceasta limita? >>> >>> mysql max_connections este 90000, alte variabile mysql cu max in nume si >>> valori in jurul lui 6000 nu am gasit >>> >> >> Cum a spus deja si Alex, eroarea nenicule, eroarea. Ce eroare apare? 503 pe >> webserver inseamna service unavailable (stiu ca ai zis 50x), daca ai nginx >> asta e doar faptul ca nginx nu a putut comunica cu celalalt capat (cu ce >> generezi tu pagini dinamice). >> >> Cit de complicat e sa dai niste detalii ? webserver ? limbaj ? o >> configuratie de mysql ? o eroare ? Tu personal asa faci debugging ? grep -r >> 6000 / ? > > >Eroarea este 503 si din pacate nu pot face debugging pe webservere (diferite >de linux) si sa obtin mai multe detalii. Evident ca am verificat inainte >logurile pe mysql/linux si nu am gasit nimic relevant (adica niciun warning >sau eroare) si din cauza asta m-am gandit sa nu fie ceva in genul sendmailului >ce nu trimite pe o raza mai mare de 500km. > >Numarul de ~6000 (nu este fix 6000 ci ~aprox) a rezultat in urma unor teste >sintetice cu clienti generati automati, nu este vorba de marketing wishfull >thinking. > >Deoarece webserverele comunica si cu alte servicii externe fara probleme si >doar la request-urile ce deschid conexiuni catre mysql se reproduce, >indiferent de numarul web serverelor, am izolat problema la nivelul serverului >cu mysql.
Ok, daca zici ca nu ai acces la webservere si ai dedus tu ca e baza de date e problema atunci ai incercat sa dai un _show (full) processlist_ si sa vezi ce se intampla cu serverul ala? Cate si ce fel de query-uri ai? > >Banda de asemeni nu este problema, traficul este la 1-10% din capacitate, >saturatia fiind verificata prin alte teste. iops, cpu, memorie, astrele sunt aliniate? Ce fel de storage engine folosesti? innodb_buffer_pool_size este foarte important, dar daca ai myisam atunci aceasta setare este zero:) ? Ai ceva cache in fata bazei de date? > >Apreciez raspunsurile de pana acum, intentia initiala era de a vedea daca >cineva a mai patit ceva similar si are un hint spre care sa ma indrept, dat >fiind patternul identificat (shit hitting the fan @ 6k rpm), nicidecum nu >intentionam sa fac un troubleshooting crowdsourced. Imi pare rau sa te anunt, dar eu cand am patit treburi similare, problema nu a fost mereu aceeasi. Recent eu am avut o problema similara cand un serviciu abia sufla si aleator dadea 503... Problema a fost ca niste devi faceau un delete ucigator (facea facea full table scan). Am pus un index si s-a rezolvat problema. > >Incerc sa validez ipotezele legate de open ports/files limits si revin Sfatul meu este ca inainte sa investesti timp in investigatii complexe la retea sa te uiti mai atent la ce zice mysql-ul ala... > >Multumesc > >_______________________________________________ >RLUG mailing list >[email protected] >http://lists.lug.ro/mailman/listinfo/rlug Bafta! -- + Ionut + BOFH excuse #275 + Bit rot _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
