Miałem (nie)przyjemność kontaktu z hostit i nie polecam. Zgłosił się do mnie klient z prośbą o migrację z ich serwerów sklepu i poczty, bo był problem z pamięcią. Okazało sie że serwer z 512MB ramu nie był w stanie podźwignąć małego sklepu na sote (php) + mysql. Pocztę okazuję się że sami sobie hostujemy na swoim serwerze o czym klient nie został powiadomiony - nie wiem czy to standardowe rozwiązanie, ale przynajmniej info powinno być.
Dodam tylko że tan sam sklep działał bez problemów na serwerach (tez 512) znanego z DRUG’ów mlomnicki’ego obok aplikacji na spree, takze zadne memory leaki imputowane przez support hostit nie wchodzily w gre.
Jeżeli nic się u nich nie zmieniło to raczej omijać.
Ten sam sklep, ale czy ta sama wersja Rails? Nie zamierzam bronić firmy która uważa że dostęp do plików przez SFTP to coś, czym należy się chwalić w 2011 roku, ale Railsy w okolicach 3.0.x potrafiły cieknąć straszliwie.
(A z rails_admin (swego czasu, nie wiem jak teraz) to już w ogóle masakra i także w trybie produkcyjnym.)
Tak. Dramatyczne wycieki już można było obserwować w okolicy 303-304, w samym 307 już było trochę lepiej, w okolicach 3010-3011 podobno poradzili sobie z tymi wyciekami zupełnie.
Ciekło głównie w środowisku developerskim, więc nie było dramy.
(ale oparta o Spree aplikacja potrafiła co request kolejne 50MB łyknąć źródło babola było gdzieś w AbstractController, jeśli dobrze pamiętam – kiedyś robiłem risercz na ten temat, ale porzuciłem jak się okazało że załatane)
Rails 3.0.9. Ale to akurat mało ważne, bo wyciek był potężny i nawet w środowisku produkcyjnym, oraz totalnie ustawał po wykomentowaniu rails_admin (nie pamiętam wersji, ale była to wtedy-najnowsza) z Gemfile.
To były okolice 20-22. lipca 2011.
Szukaliśmy źródła wycieku z ekipą 314Technologies (świetny team zresztą, uwielbiam z nimi pracować).
Nawet postawiliśmy aplikację w specjalnym środowisku (ruby 1.8.7, na systemie 64-bitowym, env production), celem przeczołgania memprof-em.
Dowcip polegał na tym, że o ile powodem wycieku było dodanie rails_admin do Gemfile, o tyle sam wyciek się robił w klasach HAMLs.
Logi z memprofa: https://gist.github.com/1411465 – patrz linijki z klasami HAMLa.
(aplikacja oczywiście w trybie produkcyjnym, wynik po jednym żądaniu “/”)
Nie mam pojęcia czy to zostało naprawione, skończyło się wywaleniem rails-admina, nie wiem co się dalej w tym projekcie działo.
źródło babola było gdzieś w AbstractController, jeśli dobrze pamiętam – kiedyś robiłem risercz na ten temat, ale porzuciłem jak się okazało że załatane)