Eu zic sa ne concentram mai bine asupra rezolvarii problemei.
Teoretic incepem sa reintram pe drumul cel bun. Acum sa vedem daca este sau nu asa. Testam/monitorizam pana luni-marti sa vedem cum sta treaba, in ce directie ne indreptam.
Postez mesajul de mai jos in speranta ca este cineva care are o idee salvatoare/o solutie. Poate a mai intampinat problema in trecut. Print screen-uri cu ce vedem noi si restul de peste 68.000 useri nu cred ca sunt catalogate ca solutie ci "constatare".
Singura mentiune e ca baza de date are 2.2GB nu 4.5 cum spun ei. Si este destul de probabil sa putem sa o mai micsoram o idee deoarece am gasit cateva chestii care "nu ne mai trebuie" si ar merge exportate si stocate pe ceva suport optic.
Buna ziua,
In urma verificarilor realizate pe serverul dumneavoastra, am gasit o tabela marcata "crashed". Am reparat-o.
clubford_forum.phpbb_privmsgs optimize Error Table './clubford_forum/phpbb_privmsgs' is marked ...
clubford_forum.phpbb_privmsgs optimize Error Table 'phpbb_privmsgs' is marked as crashed and la...
Am folosit scriptul gasit in directorul /root/mysqltuner.pl de pe serverul dumneavoastra si am gasit urmatoarele:
[!!] Highest connection usage: 88% (264/300)
[OK] Key buffer size / total MyISAM indexes: 16.0M/1.6G
[OK] Key buffer hit rate: 99.4% (2B cached / 12M reads)
[OK] Query cache efficiency: 46.0% (8M cached / 19M selects)
[!!] Query cache prunes per day: 587919
[OK] Sorts requiring temporary tables: 0% (1K temp sorts / 1M sorts)
[!!] Joins performed without indexes: 15292
[OK] Temporary tables created on disk: 24% (345K on disk / 1M total)
[OK] Thread cache hit rate: 99% (3K created / 1M connections)
[!!] Table cache hit rate: 0% (4K open / 2M opened)
[OK] Open file limit used: 79% (7K/10K)
[OK] Table locks acquired immediately: 99% (15M immediate / 15M locks)
[OK] InnoDB data size / buffer pool: 4.9M/16.0M
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Reduce your overall MySQL memory footprint for system stability
Reduce or eliminate persistent connections to reduce connection usage
Adjust your join queries to always utilize indexes
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
max_connections (> 300)
wait_timeout (< 30)
interactive_timeout (< 30)
query_cache_size (> 2M)
join_buffer_size (> 8.0M, or always use indexes with joins)
table_cache (> 4000)
Asa cum precizeaza si mesajul de mai sus, aveti resursele hardware de memorie ale serverului in proportie de 99% ocupate de serverul mysql. Mai adaug ca aveti in serverul mysql baze de date care ocupa 4.5GB si ca aceste baze de date se afla pe un HDD sata care are si el limitarile lui.
Este normal ca atunci cand realizati o comanda care trebuie sa studieze 4.5GB de baze de date sa dureze mai mult. Aceasta comanda va dura si mai mult in cazul in care deja exista o incarcare pe server. Am dat mai devreme o comanda de optimizare pe baza de date de la forumul clubford, lucru care a dus serverul in incarcare de 50, iar daca nu as fi oprit-o ar fi blocat intreg serverul.
de silviupn69 » 13 Iul 2011, 15:25 
