1

Temat: Problem z aktualizacją z wersji 4.9.22 do 4.9.60

Witam,
niestety samo skopiowanie nowych plików nie pomaga żeby zaktualizować estats z wersji 4.9.22 do 4.9.60.
Na początku nie łączyło z bazą.
Potem gdy ręcznie poprawiłem plik konfiguracyjny config.php połączyło z bazą, ale większość podstron estats nie działało.
Na razie przywróciłem poprzednią wersję z backupu, ale jak zaktualizować poprawnie do 4.9.60?

Dane konfiguracyjne estats to:

Wersja eStats: 4.9.22 - stable (01.08.2009 12:29:08);

Moduł bazy danych: eStats MySQL v3.0.09 - stable (28.09.2008 15:36:43);

Baza danych: MySQL;

Wersja PHP: 5.2.16-0+tld0;

Załadowane rozszerzenia PHP: PDO, PDO_ODBC, Reflection, SPL, SQLite, SimpleXML, Zend Optimizer, apache2handler, bcmath, bz2, calendar, ctype, curl, date, dba, dbase, dio, dom, eAccelerator, exif, filter, ftp, gd, gettext, hash, iconv, imagick, imap, ionCube Loader, json, libxml, mbstring, mcrypt, mhash, mime_magic, mysql, mysqli, odbc, openssl, pcre, pdo_mysql, pdo_pgsql, pdo_sqlite, pgsql, posix, pspell, session, shmop, soap, sockets, standard, suhosin, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, uploadprogress, wddx, xml, xmlreader, xmlwriter, xsl, zip, zlib;

Tryb bezpieczny PHP: N/A;

Oprogramowanie serwera: Apache;

Moduły Apache: core, http_core, mod_actions, mod_alias, mod_asis, mod_auth_basic, mod_authn_file, mod_authz_default, mod_authz_groupfile, mod_authz_host, mod_authz_user, mod_autoindex, mod_cern_meta, mod_cgi, mod_dir, mod_env, mod_expires, mod_headers, mod_include, mod_log_config, mod_logio, mod_mime, mod_mime_magic, mod_negotiation, mod_php5, mod_rewrite, mod_setenv, mod_setenvif, mod_so, mod_speling, mod_ssl, mod_status, mod_tld_stat, mod_vhost_alias, prefork;

System operacyjny: Linux;

Nazwa hostingu: VPS Luna z KEI.PL

2

Odp: Problem z aktualizacją z wersji 4.9.22 do 4.9.60

Dziwne, powinno wystarczyć nadpisanie plików...
Przywracanie bazy raczej nie było potrzebne, aktualizacja dodaje tylko kilka dodatkowych opcji, nie zmienia istniejących danych.
Może spróbuj podpiąć nową wersję równolegle do tej, w innym folderze, z tym zmodyfikowanym plikiem konfiguracyjnym, wtedy mógłbym się temu bliżej przyjrzeć.

Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.

3

Odp: Problem z aktualizacją z wersji 4.9.22 do 4.9.60

Podłączyłem pliki wersji estats 4.9.60 do bazy estats 4.9.22 - poniżej problemy które się pojawiły:

dla strony /index.php?vars=pl/general wyskakuje błąd(strona "ładuje się" biała):

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 66 bytes) in /home/users/estats-test/public_html/plugins/drivers/MySQL/plugin.php on line 581

część podstron z grupy /index.php?vars=pl/general też się nie ładuje

/index.php?vars=pl/visits - ładowanie tej strony i kolejnych podstron zajmuje 65sek., poniżej część zapytania MySQL które tak długo się wykonuje:

SELECT DISTINCT `visitors`.*, `details`.`id` AS `details` FROM `estats_website_visitors` LEFT JOIN `estats_website_details` AS `details` USING(`id`) WHERE (`robot` = '' OR `robot` = '0') AND `visitors`.`id` IN ('367973', '367972',  '367971',  '367970' ...

Reszta stron wygląda że działa poprawnie, ale nie powyższe które nie działają są jednak najważniejsze, najczęściej wykorzystywane.

Aha..  nie działa też nadal robienie buckupów index.php?vars=pl/tools/backups - po kliknięciu żeby wykonać kopie po chwili wyskakuje:

Fatal error: Maximum execution time of 30 seconds exceeded in /home/users/estats-test/public_html/lib/backups.class.php on line 119


Wygląda na to że chyba baza statystyk tak się rozrosła(backup ma 455MB) że estats nie może załadować jej danych.
Poniżej jeszcze screenshot jak wygląda zapełnienie bazy statystyk - ile jest rekordów w tabelach i ile ważą.

http://itspec.net/temp/estats-screenshot.png

Ostatnio edytowany przez sacud (17.06.2011 20:28:13)

4

Odp: Problem z aktualizacją z wersji 4.9.22 do 4.9.60

No tak, to dość gigantyczna liczba danych... ;-)
Co do Ogólnych, to "spowalniaczem" jest tabela stron, tutaj może pomóc dodanie dodatkowego indeksu (ale nie unikalnego) dla kolumny address (tabela sites), dla testowej bazy danych (podziękowania dla Kobera) zawierającej 147465 krotek w tej tabeli dało to zejście z 11 do 8 sekund, warto spróbować. Więcej się raczej nie wyciągnie, sprawdziłem jak to wygląda na silniku InnoDB i tam wypada niemalże tak samo (tylko pół sekundy gorzej).
Dla strony szczegółów powinno pomóc dodanie indeksu (ale nie unikalnego) do tabeli details, kolumny id, na testowej bazie zawierającej w tabelach odwiedzających 225 i 246 tysięcy krotek.
W przypadku kopii zapasowych to mamy problem, bo tam jest już zabezpieczenie przed dużą ilością danych (zapytania zwracają tylko "uchwyt" do zbioru danych, nie same dane), ale widocznie nie da się tą drogą tego obejść do końca, trochę to dziwne zresztą, bo wygląda na to, że PHP od razu pobiera dane i trzyma je po swojej stronie zamiast odbierać krotka po krotce... Jedyne co mi przychodzi do głowy, to sprawdzanie ilości danych przed próbą ich pobrania i dzielenie na kawałki, ale tu mamy dwa inne problemy, możliwość modyfikacji danych pomiędzy pobraniami (w sumie małe ryzyko i małe szkody, przynajmniej przy obecnej strukturze danych, ostatecznie można zasugerować albo automatycznie zablokować zbieranie danych na czas wykonywania kopii) i groźniejszy, możliwość skończenia się czasu na wykonanie skryptu (na niektórych hostingach nawet jedynie około pięciu sekund). To drugie też można by spróbować ominąć, jakimś etapowym wykonywaniem, z porównywaniem czasu wykonywania do limitu i przekazywaniem "współrzędnych" do rozpoczęcia następnego etapu, ale to dość skomplikowane i w najbliższym czasie raczej się nie pojawi (najwcześniej w 5.0).
Przy takich ilościach danych najlepiej używać narzędzi zewnętrznych, które nie są limitowane ustawieniami PHP.

PS. Udało Ci się tak wstrzelić z tym postem, że nie zdążył załapać się na mój czytnik RSS, a tego samego pewnie dnia wystąpił problem z konfiguracją mojego konta i nie zauważyłem tego aż do wczoraj. :-D

Nadszedł już czas, najwyższy czas, nienawiść zniszczyć w sobie.