Pamięci… dajcie mi więcej pamięci! (MyBB)

29 stycznia 2009, by: kozik

Próba uruchomienia „Rebuild thread counters” na forum MyBB z „trochę” większą ilością wątków (niż standardowa) do przerobienia w jednym etapie. Efekt? Skrypt zjada pamięć i zjada… i zjada… i tak pewnie by zjadał do kilkuset MB, o ile wcześniej memory_limit w PHP go nie wywali. OK – zwykły bug w nieprawidłowym dbaniem o użycie pamięci. Gorzej z reakcją MyBB na zgłoszenie buga…

Problem rozchodzi się w cache’u wątków w get_thread() (plik inc/functions.php, MyBB 1.4.4), który działa na zasadzie lokalnej zmiennej statycznej przechowującej dane każdego wczytywanego wątku. Normalnie to działa… ale jak zapuści się np. ten „Rebuild thread counters„, to ładuje do cache’u każdy wątek. Zatem jeśli ustawimy przeliczanie liczników w jednym przebiegu (proces dzieli się na etapy, gdzie trzeba klikać „next„) na 5000 wątków skrypt będzie idiotycznie ładował i trzymał te 5000 wątków. No i się wywali, bo to idzie w setki MB.

Prosta łata – ograniczyć wielkość cache’a wątków. No bo po co ma to rosnąć, prawda? Zgłoszenie:MyBB 1.4.4
Rebuilding Thread Counters with large Entries per page (e.g > 5000; with overall threads above 100000) fails with „Allowed memory size of 64 MB exhausted”.
Memory usage grows because of static $thread_cache in get_thread() which holds every thread. This is not necessary – we do not have to cache every thread… So maybe limit the size of $thread_cache?
Proof of concept with hard limit (solves the issue, but there can be more elegant solutions) in patch.

Reakcja MyBB?

Yep. And those bigger boards have been correctly configured. I should know, since I help run one of them. In fact it is approximately 30 times bigger then yours and recount and rebuilds run smooth and fast.
You need to configure your server correctly if you want to do more then MyBB’s default values for recounting.

No w mordę jeża, zwiększanie memory_limit ma być rozwiązaniem (bo do tego się sprowadza „konfiguracja”, poza może odchudzeniem wagi PHP) na leniwe programowanie i złe zarządzanie przez skrypt używaną pamięcią? Nie ważne ile user zażyczy sobie, żeby wątków przerabiało – skrypt może wywalić się z powodu przekroczenia czasu (max execution time), ale nie może pożerać pamięci w nieskończoność! User może wpisać niebotycznie ogromne wartości, a skrypt ma ciągle panować nad swoim memory footprint!

Szczerze mówiąc, to można się załamać widząc takie podejście w tworzeniu oprogramowania… i odchodzi ochota zgłaszania bugów upstream.

Wysłano w Blog - Web | Tagi: , , , , | 5 komentarzy »

Adres dla trackback. RSS dla komentarzy w tym wpisie.

5 komentarzy

  1. matc Says:

    Tak jakby nie patrzeć, MyBB jest „wolne”, czyli nie płatne i darmowe. Idąc dalej tym tokiem, można stwierdzić, że autorzy nie mogą być do niczego „zmuszeni”. Aczkolwiek skoro wydają w sieci skrypt, powinni zadbać o najmniejsze możliwie elementy mogące być w jakimś stopniu i bugiem. Tutaj popieram, że czytając wątek lekko się zdegustowałem w stosunku do tego podejścia, a raczej reakcji upstream. Skoro „jest możliwość” optymalizacji jakiegoś elementu/funkcji skryptu, to powinno się to zrobić. A w tym wypadku wychodzi, że masz sobie podrasować ustawienie na serwerze i tym samym w ewentualnym wypadku – zajechać go.

    Jestem ciekaw jakby wyglądałaby taka sprawa w przypadku zgłoszenia bugu (który byś znalazł) w jednym z płatnych skryptów, typu: IPS bądź vBulletin®. Zastanawia mnie także to, jak oni rozwiązali tego typu funkcje.

    koziolek, powiedz, czemu wybór
    padł na MyBB? Bo zdaje sobie sprawę, że jednak dla Bauer’a wydać kasę na licencje typu wcześniej wymienionych płatnych skryptów, nie byłoby problemem.

    Chętnie bym także zobaczył tutaj jakiś test IPS wersji 2 i wczesnej bety 3 z Twojego punktu technicznego i funkcjonalnego.

  2. kozik Says:

    Autorzy mogą ignorować bugi… ale nierozerwalnie z ruchem open-source wiąże się społeczność i to co ona zwraca do projektu. Społeczność zresztą to nie tylko ludki po świecie rozesłani, ale i pracownicy firm, którzy wykorzystują dany produkt i postanawiają coś „zwrócić w zamian”.

    Dokładnie takie samo podejście przerabiałem tam z rok temu po zgłoszeniu kilku poprawek odnośnie wydajności i użycia pamięci (np. walenie o memory_limit przy wyświetlaniu dużego wątku w trybie „threaded view”). Mimo ewidentnie nieprawidłowego kodu odpowiedzią bywało „ja mam duże forum i u mnie działa, naucz się konfigurować swój serwer”.

    Niestety nie mogę się pozbyć wrażenia, że każdy bug jest dla kogoś tam ujmą na honorze i zawracaniem głowy. Inna sprawa, że teraz to jest Wolne Oprogramowanie, więc zawsze mogę wziąć kod i zrobić forka :) , więc nie powinienem narzekać.

    Jeśli chodzi o IPB i vBulletin, to nie miałem do czynienia z ich deweloperami czy supportem, ale stawiam, że podchodzą poważnie do zgłoszeń. Klient to dla nich pieniądze, a na rynku webaplikacji panuje duża konkurencja. Ale to już domniemanie.

    Czemu MyBB a nie IPB/vBulletin? Częściowo zniechęcała zamknięta licencja oprogramowania (MyBB też było wtedy częściowo zamknięte, ale przynajmniej darmowe) i idąca z tym trudność z oceną ile to jest warte realnie. No i był to wtedy bardzo obiecujący projekt. Można było w niego łatwo wskoczyć i wykorzystać. Decyzję podejmowałem prawie 3 lata temu… i kto wie czy teraz podjąłbym taką samą?

    Samego IPB nie testowałem intensywnie… kod nie jest dostępny ot tak do wglądu (przynajmniej nie znalazłem nic oficjalnie). Z tego co widziałem, to technicznie MyBB 1.2 i 1.4 nie dorastają IPB do pięt. Widać ogromne różnice w projekcie i sposobie kodowania. Ale to się zmienia – w końcu i MyBB zaczęło używać systemu kontroli wersji, poprawia się jakość kodu od strony projektu (mniej funkcji, więcej klas i metod)… może zacznąć używać jakiegoś normalnego systemu typu Bugzilla niedługo? :)

  3. matc Says:

    Czyli jednak nie miałeś narzuconego wyboru przez wydawnictwo Bauer?

    Co do IPS, dobrze wiedzieć o ich „porównaniu”. Ale nie zaprzeczysz, że MyBB od strony funkcjonalnej sporo oferuje, zwłaszcza także, że pozwala na łatwe dodawanie różnej formy modyfikacji poszerzających jego funkcjonalność?

    Ostatnio wyczytałem trochę o nowym IPS 3, zmian w kodzie ogrom. Ponoć rewelacyjnie odciążyli jeszcze to wydanie względem serwerów, a wygląd powiem, że robi na swój sposób wrażenie…

    Nie wiem też czemu, ale bardzo łatwo to zaobserwować, w sumie to wiele osób to zaobserwowało.IPS bardzo, bardzo ładnie się indeksuje w Google, porównując je do MyBB czy innych skryptów.

    Aczkolwiek forum PC Format wcześniej bez SEO także imponująco się zindeksowało w Google.

  4. kozik Says:

    1. Wybór był tu mój… porównując z innymi bezpłatnymi skryptami – bardzo trafny. Porównując z płatnymi? Można dyskutować :) .

    2. MyBB oferowało i oferuje wystarczająco jak na zaawansowane forum dyskusyjne. IPB oferuje jeszcze więcej, ale to nie znaczy, że te dodatkowe funkcjonalności byłyby wykorzystane.

    3. MyBB nie ma praktycznie żadnych optymalizacji/usprawnień SEO. Kuleje. Żadnych SEO linków, meta tagów dostosowanych do treści, sitemap (XML i wersji HTML, aby realizować „3 kliknięcia od głównej”), a do tej samej treści prowadzą różne linki. Pod względem SEO jest to porażka.

    Jedyne co ma to „lekką wersję” oraz przyjazne linki (które praktycznie nie mają znaczenia przy SEO, bo nie zawierają żadnej informacji dla GoogleBota).

    Na mój gust wysoka pozycja forum PC Format w Google jest dzięki forumowiczom i ich treści.

  5. O wydajności MyBB słów kilka… - LukasAMD weblog Says:

    [...] silnika – doskonałym przykładem są problemy na forach PC Format i NEXT opisywane przez koziolka – autorzy nie reagują na uwagi, radząc lepiej ustawić serwer… Brawo, to się nazywa [...]

Dodaj komentarz




Uwaga: Włączona jest moderacja komentarzy, więc nowy komentarz nie ukaże się bezpośrednio po jego wysłaniu.

Uwaga: Działa filtr antyspamowy. Jeśli umieścisz w komentarzu odnośniki, to może on zostać błędnie zakwalifikowany jako spam.