Asistență tehnică forum și server

Started by Ionut, September 26, 2016, 09:32:33 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

nirolf

Tocmai am primit 2 erori d-alea în ~30 de secunde.

Ionut



Ionut

MySQL. Mie nu mi-a mai facut figuri. Hm...

__dir

Doar 1 mesaj astazi pe la 12-13, dupa nimic.

;)

frunzaverde

#35
Quote from: cristi5 on October 21, 2016, 08:45:24 PM
si eu. e postgres baza de date?

Cristi, e un MySQL hostat pe resurse dedicate prin Bluehost. Forumul e scris in PHP.

Bluehost limiteaza numarul de conexiuni deschise la MySQL la 15 deschise simultan. Nu pare ca putem schimba chestia asta, cel putin din interfata. SMF, softul forumului, deschide o conexiune separata si noua pentru fiecare tranzactie facuta de un utilizator. Colectia de gunoaie a PHP este notorie ca fiind proasta, pastrand conexiuni deschise perioade lungi dupa executia scriptului.

Ce-am rezolvat a fost sa facem conexiunile persistente (pentru ca conexiunile sunt deschise de scriptul PHP, le poate refolosi daca sunt libere in loc sa deschida altele noi, reducand numarul de conexiuni simultane deschise si pending). Mai mult, singura solutie e sa contactam Bluehost sa modifice nr. de conexiuni deschise din my.conf de la 15 la un numar mai rezonabil (80-100) pentru traficul pe care il avem.

Problema e cunoscuta de utilizatorii SMF, si confirmata de Bluehost (care insa nu s-a aratat dispus sa umble in configurarea serverului).
Cand esti amenintat cu ban permanent pentru ca ai criticat pozitia publica a unui politician, nu se mai poate numi conversatie sau forum, ci campanie electorala. Imi pare rau, dar din pacate, sunt nevoit va urez la revedere!

cristi5

#36
15 conexiuni mysql la un sistem three-tier cu sute de utilizatori e foarte putin. Daca traficul pe forum va creste, problemele astea vor aparea tot mai des si pentru tot mai multi utilizatori. In plus, toate thread-urile serverului http sunt incetinite pt ca asteapta dupa o resursa "gâtuită" (conexiunile mysql din pool-ul de conexiuni persistente). Am observat des ca unele accese merg rapid, altele asteapta cateva secunde si apoi merg rapid, asa se intampla cand serverul asteapta dupa o resursa.

Nu se poate pastra forumul unde e (cu toate configurarile actuale) si facut hosting de mysql (sau un linux cu o instalare mysql, 10 eur pe luna la hosteurope.de) in alta parte? Poate va merge mai incet din cauza transferulu intre cele 2 masini si subnets (SMF si mysql), dar ar putea merge de fapt mai rapid pt ca se elimina gâtuitura.

Cat e de mare baza de date actuala? Innodb sau myisam? Cate accese pe luna?

frunzaverde

#37
Quote from: cristi5 on October 21, 2016, 11:39:39 PM
15 conexiuni mysql la un sistem three-tier cu sute de utilizatori e foarte putin.

I-am spus lui Ionut sa contacteze Bluehost maine sa ii determine sa schimbe my.conf la macar 100. Ceea ce ar trebui sa fie suficient pentru nevoile curente ale forumului. Daca Bluehost nu accepta, va trebui sa gasim alt hosting. Am crezut ca trecutul la conexiuni persistente va rezolva macar cat-de-cat situatia, dar e tot prea putin.

Pana acum Bluehost s-a purtat foarte ok cu noi (inclusiv acces ssh, acces la loguri, diagnostice etc.), asa ca sper ca totul sa fie ok cu ei. Chiar au fost helpful in diagnosticarea problemei (stiam de la pranz ca numarul de conexiuni limitat e problema; am incercat sa reducem problema schimband conexiunile in persistente, ca sa reducem riscul de conexiuni deschise dar neutilizate).

Quote from: cristi5 on October 21, 2016, 11:39:39 PM
Nu se poate pastra forumul unde e (cu toate configurarile actuale) si facut hosting de mysql (sau un linux cu o instalare mysql, 10 eur pe luna la hosteurope.de) in alta parte? Poate va merge mai incet din cauza transferulu intre cele 2 masini si subnets (SMF si mysql), dar ar putea merge de fapt mai rapid pt ca se elimina gâtuitura.

Firewall-ul Bluehost nu accepta conexiuni la bazele de date in afara subnetului lor. Cel putin din experienta mea cu contul meu personal, care e tot pe Bluehost; Ionut are mult un cont mai higher-tier.

Daca nimic nu merge altfel, am putea sa migram serverul la ceva gen Amazon EC sau Google Compute Engine. Acolo avem acces la tot (fisiere de configurare, setari etc.), costurile sunt mai mari decat la un web-hosting dedicat, si am avea nevoie de administrarea initiala (cateva ore ca-i un LAMP simplu) si apoi administrare 1-2 ore pe luna, care sa vada ca masina merge ok, backupurile is ok, logurile sunt intregi etc. etc..

Quote from: cristi5 on October 21, 2016, 11:39:39 PM
Cat e de mare baza de date actuala? Innodb sau myisam? Cate accese pe luna?

E baza de date default (canned) folosita de SMF. 20 de tabele, in jur de 135 MB in total. Doua tabele au peste 1 MB, tabelul de posturi, care contine tot (110 MB) si tabelul de mesaje private (1.1 MB). Tabelele sunt indexate corespunzator (atat cat poate MySQL) pe coloanele care au sens (BTREE pe campul care identifica thread-urile si posturile intr-o structura arborescenta si BTREE pe cheia primara, si ceva hash pe continut). Deci nimic sofisticat sau imens.

Sunt 90% sigur ca e myisam (trebuie sa verifice Ionut, ca eu n-am datele de cont, dar Bluehost defaults pe myisam si SMF e compatibil cu MySQL-uri vechiute, ceea ce inseamna ca doar MyISAM merge). Numarul de utilizatori conectati simultan e modest (<1000 in peak-uri).
Cand esti amenintat cu ban permanent pentru ca ai criticat pozitia publica a unui politician, nu se mai poate numi conversatie sau forum, ci campanie electorala. Imi pare rau, dar din pacate, sunt nevoit va urez la revedere!

cristi5

#38
Pool-ul PHP de conexiuni persistente nu are o lista de asteptare? daca o cerere nu poate fi satisfacuta pt ca mysql nu mai accepta conexiuni, returneaza direct eroarea pe care o vedem? Cu alte cuvinte "stie" pool-ul ca sunt max 15 conexiuni fizice? Poate se poate configura acest pool... De ex sa setezi numarul maxim de conexiuni persistente la 15. Atunci nu va deschide mai multe conexiuni mysql, intrebarea e ce va face cu clientii nesatisfacuti...

Inteleg ca baza de date e pe alta masina decat cea pe care aveti acces ssh. Probabil e un server mysql urias, cu multe baze de date pt mai multi customers, si numarul de conexiuni limitat per utilizator (deci nu din my.cnf!). Ceva de genul:

ALTER USER 'user3'@'localhost' WITH MAX_USER_CONNECTIONS 20;

Ionut

Mda, deci nu se poate. Ma rog, se poate, dar nu vor. Doar pe dedicated server se poate.

frunzaverde

#40
Quote from: cristi5 on October 22, 2016, 01:38:42 AM
Pool-ul PHP de conexiuni persistente nu are o lista de asteptare? daca o cerere nu poate fi satisfacuta pt ca mysql nu mai accepta conexiuni, returneaza direct eroarea pe care o vedem?

Exact asta e implementarea standard,  când nu mai are în pool nimic disponibil scriptul își încheie execuția  (or die()). Singurul mod în care putem configura purtarea scriptului e sa rescriem softul forumului. Pentru ca php fiind php,  purtarea asta e în  zeci de locuri acolo unde se cere conexiune noua.


Quote from: cristi5 on October 22, 2016, 01:38:42 AM
ALTER USER 'user3'@'localhost' WITH MAX_USER_CONNECTIONS 20;

Am încercat
SET GLOBAL max_connections = 50
Dar nu avem privilegii sa executam asta...
Cand esti amenintat cu ban permanent pentru ca ai criticat pozitia publica a unui politician, nu se mai poate numi conversatie sau forum, ci campanie electorala. Imi pare rau, dar din pacate, sunt nevoit va urez la revedere!

__dir

O alta idee este sa mergeti cu un hosting mysql separat (gen: compose.com) sau Digital Ocean VPS (dar aici nu aveti management, doar backup)


cristi5

Fireste ca nu vor schimba max_connections sau alta schimbare in my.cnf pt ca asta ii va afecta pe alti utilizatori de mysql hosting. Ati intrebat si daca vor sa faca ALTER USER?

Dar cred ca e gresit configurat web serverul. Peste tot scrie ca trebuie limitat numarul de php child threads la numarul de conexiuni mysql. Atunci nu se vor face mai mult de 15 conexiuni mysql. Daca sunt 20 de http requests active simultan, 5 din ele vor trebui sa astepte...

Nu stiu cum se face asta in nginx dar pot sa aflu.

frunzaverde

Quote from: cristi5 on October 22, 2016, 03:03:11 PM
Nu stiu cum se face asta in nginx dar pot sa aflu.

Nu ne lasa sa umblam nici la setarile serverului de web. Singurul lucru pe care-l putem face este sa alegem versiunea de PHP pe care o vrem, cu un php.ini facut de ei, pe care-l putem modifica per director cu un php.ini modificat (dar doar in anumite variabile). Atat. E un hosting traditional - accesul nostru se limiteaza la /var/www si-atat.

Serverul de web si cel de mysql este pe aceiasi masina - connection string-ul foloseste localhost.

Nu vor sa schimbe conexiunile nici pe user nici in general (aparent fiecare user are propriul proces mysql la tier-ul la care suntem noi, asa ca umblatul in my.conf nu ne-ar afecta decat pe noi). Ne cer sa urcam la tier-ul superior (care e practic un fel de VM numai pentru noi) daca vrem asa ceva.
Cand esti amenintat cu ban permanent pentru ca ai criticat pozitia publica a unui politician, nu se mai poate numi conversatie sau forum, ci campanie electorala. Imi pare rau, dar din pacate, sunt nevoit va urez la revedere!

cristi5

#44
Dintr-un motiv sau altul eu nu am mai vazut eroarea.

Din moment ce atat configurarea serverului HTTP (de ex. numarul de PHP child threads) cat si configurarea bazei de date sunt in curte la hosting, inseamna ca problema e la hosting. Si daca au rezolvat-o, probabil nu se vor deranja sa ne spuna.

Cred ca efortul unui upgrade la server dedicat (si administrarea ulterioara!) pentru o aplicatie relativ mica (~100Mb de date si max 1000 de sesiuni active) nu se justifica. Pana la urma e o problema minora, sper sa nu se agraveze odata cu cresterea numarului de utilizatori. Fiind in setarile standard ale hosting-ului, banuiesc ca vor fi si alti clienti nemultumiti.