Pomoc przy zamykaniu połączeń do bazy

Flaw - 02-06-2007 23:44
Pomoc przy zamykaniu połączeń do bazy
Witam.

Od dłuższego czasu mam problem ze stroną na koncie Plan90. Błąd związany jest z bazą danych - mój CMS nie zamyka połączeń z bazą. Chodzi o Post Nuke a dokładniej moduł Post Schedule.

Błąd, który się pojawia:
ERROR: (PostSchedule_userapi_monthView) MySQL server has gone away.

Był on przez administratorów OVH 'rozwiązywany'. Nie miałem go na poprzednim hostingu, przed przenosinami serwera, więc wynika to z ograniczeń nakładanych przez OVH, ale założyłem że skoro docelowo i tak jest błąd po stronie PostNuke, to naprawię. Zgodnie z poradami supportu - zamknąłem (jak mi się wydaje) połączenia w funkcji, która zwraca błąd (PostSchedule_userapi_monthView).

Dodałem $result->Close(); przed return, ale to nie pomogło. PNUSERAPI.ZIP - tutaj wgrałem cały plik z tą funkcją (odpowiada ona za wyświetlenie wydarzeń), która zwraca błąd, każde $result->Close(); zostało przeze mnie dopisane... Może będzie potrzebne więcej plików tego modułu to proszę o info.

Mam wspomniany błąd co 6-7 odsłon strony www.wrock.pl, nic się nie poprawiło. Nie wiem więc, co mogę zrobić więcej.

Pytanie i prośba do administratorów, czy zrobiłem to dobrze - support odesłał mnie na forum. Może przejrzenie zipa pomoże...

Czy da się sprawdzić w logach, która dokładnie funkcja, w jakim miejscu itp nie zamyka połączenia z bazą? Może wspólnie uda się przeprowadzić testy nie zajmując dużo czasu adminom?

Jest to dla mnie istotne, ponieważ obecnie Google ma zaindeksowane ponad 140 podstron mojego serwisu, które... zawierają błąd a nie właściwą treść a staty wyraźnie pokazują spadek odsłon po przenosinach.

Pozdrawiam i liczę na odrobinę poświęconego czasu. Dziękuję.

sLoDkI - 03-06-2007 23:57
Po pierwsze: obstawiałbym przy zmianie długości czasu podtrzymania połączenia z bazą danych na krótszy, ale nie wiem czy da się to zmienić w tym CMSie.. bo z tego co widze to wogóle nie zamyka połączeń z bazą :(

W takim razie nic tylko pozamykać wszystkie połączenia po wykonaniu zapytań, i upewnić się że jest poprawnie zaimplementowane ponowne łączenie się z bazą.

Nie ma to jak własny wkład w projekty Open Source :)

Jutro rano postaram się zerknąć w logach które funkcje jeszcze się wywalają..

PS. może nowsza wersja ma poprawione te błędy? Albo jest jakiś patch?

PS.2. W momencie kiedy się Panu skrypt wysypie skrypt, proszę wejść na: http://90plan.ovh.net/infos/ i sprawdzić konfiguracje "90plan - webXXX" gdzie XXX jest numerem serwera - to ułatwi nam przeszukiwanie logów ;)

pozdrawiam.

Flaw - 04-06-2007 22:31
web228.

Nie ma nowszej wersji, przynajmniej tego modułu - jedyne co mi zostało to albo przenieść serwer tam gdzie mi dobrze całość chodziła, całkowicie przebudować serwis (możłiwe za parę miesięcy) lub za kasę wynająć programistę który mi to zidentyfikuje/naprawi - każdy z nich jest kosztowny...

Mimo że z modułu Post Schedule korzysta dużo Post-Nuke, który jest popularnym CMSem to tylko moja strona z tym błędem jest zaindeksowana w sieci - musiała się nietypowa konfiguracja na OVH spotkać z nieoptymalnie napisanym kodem...

Dziękuję za zainteresowanie i czekam na jakieś info.

mariano - 05-06-2007 11:57
Byc moze Twoje klopoty zwiazane sa ze zmienna "wait_timeout" na naszych serwerach sql. Jest ona ustawiona na 120 sekund - to troche malo, ale ratuje ludzi przed bledem "max connections reached". Sprobuj zwiekszyc ja po polaczeniu z baza. Najpiej odszukaj funkcje "dbconnect" i zaraz po ustanowieniu polaczenia z baza wykonaj zapytania: "set wait_timeout=80000;" i "set interactive_timeout=80000;". Jesli to tutaj lezy problem, powinno pomoc.

Oczywiscie najlepiej jest jednak poprawic kod php. Dorazne rozwiazania zawsze sie mszcza. :)