Blizzard Odesláno 5. říjen 2007 Odesláno 5. říjen 2007 jj, já jen pro info... aspoň když to chvíli nejde udělam něco v práci Citovat
ondra Odesláno 5. říjen 2007 Odesláno 5. říjen 2007 No vidis, ja zas kvuli foru neudelam v praci nic misto prace ladim mysql Jinak jsem jeste zmenil typ spojeni fora na databazi, uvidime co to udela. Citovat
ondra Odesláno 5. říjen 2007 Odesláno 5. říjen 2007 tak jsem z toho jelen.... tedka to zase zacyklilo nebo co a nevim, fakt nevim. Sledoval jsem vytizeni pameti a procesu, to bylo vsechno v pohode, mel 0,5gb ram volny, cpu jel na 10procent, presto mysql odmitlo pracovat. Situace byla v tom, ze od uzivatele peugeot-club-db (coz je user, ktery se pripojuje k db) tam byl nejaky dotaz, ktery tam furt stal - ostatni dotazy tohoto uzivatelle se postavily do "fronty" - system je tedka nastaven, ze v pripade, ze do 30s nedostane odpoved, ze se ma ukoncit - ale tenhle puvodni dotaz trval cca 180 sekund a furt trval... a ostatni tim padem byly Locked spis me zarazilo, ze mysql tenhle dotaz automaticky neodrizlo - zkousel jsem schvalne jinej dotaz pod jinym uzivatelem, ten se po 30sek automaticky ukoncil naprosto v pohode. Ale od uzivatele peugeot-club-db proste tam obcas nejakej dotaz zustane viset - a tim padem se nedostane na ostatni. Proto volam o pomoc - umi nekdo s mysql na administratorsky urovni? Ja uz fakt netusim... Citovat
ondra Odesláno 5. říjen 2007 Odesláno 5. říjen 2007 PS: Jeste jsem zapnul logovani dlouhejch dotazu - tim padem se snad dozvime, kterej presne dotaz z fora to dela... pokud se to podari, pak dotycna tabulka dostane za trest takovy oindexovani, ze se z toho nevzpamatuje Citovat
Pata Odesláno 5. říjen 2007 Odesláno 5. říjen 2007 ondra: tak proc tu obsahlou (300mb) tabulku nerozdelis? Staci vytvorit druhou, ktera bude mit dva sloupce - id_dotazu a pocet_odpovedi a tahle se bude updatovat, tudiz bude zamkla, ostatni budou volne pro cteni? ... Kadopadne je to spatne osetrene (navrhnute, naprogramovane?), protoze pro zmenu jednoho radku tabulky staci zamknout jenom ten radek ... alespon v tomhle pripade - zbytecne zamykas celou tabulku a pak dochazi k uvaznuti ... ps: mel bych o tom neco vedet, kdyz jsem z toho v kvetnu statnicoval :super:super Citovat
Pata Odesláno 5. říjen 2007 Odesláno 5. říjen 2007 ondra: neber to jako kritiku, jen se snazim najit reseni Osobne bych vyresil to zamykani, pak uz bude pokoj na furt.... Citovat
skupko Odesláno 8. říjen 2007 Odesláno 8. říjen 2007 Nezda sa mi od vyvojarov rozumne indexovanie pristupov na stranky davat do DB, kde su ja jednotlive prispevky :-P. Alebo je 300MB databaza ciste indexova - to sa mi nechce verit. Este by som dodal, ze od tvorcov MySQL je odporucane z hladiska vykonnosti vhodne mat viacero malych databaz rozdelenych do mensich tabuliek, ako jednu veliku databazu z malym poctom tabuliek a indexov. Cize ak mas v databaze fora aj tabulky vyuzivane inymi aplikaciami, je lepsie tieto presunut do samostatnej databazy. Dalej su v konfiguracii MySQL aj parametre definujuce maximalne pocty simultannych konekcii na server. Dalsou vecou z pohladu PHP je vhodne vyuzivanie perzistentnych konekcii do MySQL - na to by ale bolo nutne upravovat PHP kod. Dalsim problemom vztahujucim sa na vykonnost systemu je aj konfiguracia Apache web servra (hlupo pradpoklam, ze prave tento web server pouzivate) a konkretne jeho parametrov kontrolujucich pocet obsluhujucich procesov a pocet klientov, ktorych je schopny kazdy z procesov obsluhovat v jednom case. Ano, je to taka mala alchymia, vela zdaru . Na akom OS bezia Vase stranky? Mimochodom 1GB pre databazu sa mi zda urcite dost... myslim, ze Vas web server nie je az natolko vytazovany... samozrejme zla implementacia (programatorska) tohto fora moze sposobit, ze pri vacsom zatazeni by toto forum polozilo aj ten najsilnejsi server . Citovat
Recommended Posts
Zúčastnit se diskuse
Můžete odpovědět a až poté se registrovat If you have an account, sign in now to post with your account.