#linux #debian #virtualbox Mam serwer-debian x8664 na vboxie, goszczony na lubuntu, procesor amd x3 1.8GHz. Na debianie działa jre7+apache2+tomcat7. Serwer działa po to by chodziło na tym jruby i railsy ze standardową bazą sqlite. Jest to najprostsza testowa apka zrobiona za pomocą:
rails g scaffold Pracownik imie:string wiek:integer adres:text
Problem jest w tym, że jak robie coś na railsach poprzez przeglądarke(dodawanie użytkowników poprzez wypełnianie tych 3 pól tekstowych) to zużycie CPU na wirtualnym, jednordzeniowym debianie skacze mi do 40%. Zużycie ramu to przec cały czas 360MB. Żeby było jasne Debian na vboxie nie ma X Window System.
/proc/cpuinfo na Debianie pokazuje 1 rdzeń 3GHz na systemie głównym są 3 x 1.8GHz
Jeden człowiek używa apki a ta zużywa momentami 40% cpu. Jest to najgówniańsza apka-demo jaką da się zrobić w rails. To jest normalne? Dodam, że na VPS na hostingu gdzie chciałbym to przetestować działa np. jeszcze postfix+dovecot które też byłyby używane przy rejestracji, a jako baza postgres zamiast sqlite. VPS na hostingu to najtańszy testowy VPS z jednym wątkiem na AMD Opteron(tm) Processor 6128 cpu MHz : 2000.000 Do tego firma hostingowa nie życzy sobie aby ten cpu był przez dłuższe okresy wykorzystany na max.
Dlatego zanim zmarnuje czas na stawianie tej konfiguracji na VPS chciałbym się zapytać tutaj jak się ma wydajność na virtualboxie do wydajności na vps (hosting ma vps na VMware zamiast Vbox). Może ktoś wie jaki trzeba mieć serwer aby obsłużył jednocześnie np. 5 użytkowników na konfiguracji jre7+apache2+tomcat7+rails i nie dostawał zadyszki (ile ramu i wątków). W końcu może to też wina railsów w trybie development enviroment i cache? A może konfiguracji czegoś z trio jre7, apache2, tomcat? Troche jestem zdziwiony po podobno_ jruby miało być szybsze od zwykłego ruby.
Ja bym stawiał na development i ewentualnie nie cachowanie czegoś. Nie wiem jak w ror, ale wiele systemów potrafi tak dużo wolniej chodzić - co jest przecież akceptowalne dla developerki. Druga rzecz, pytanie czy środowisko jest w całości ustawione już poprawnie i nie można tego zoptymalizować jakoś. Próbowałeś sprawdzić jak chodzi nie w trybie dev, tylko produkcyjnym?
@Pies_: Zainstalowałem w trybie produkcyjnym. Każde odświeżenie strony z 11stoma utworzonymi pracownikami to wzrost użycia CPU w kilku procesach Tomcata. Łącznie każde odświeżenie to 20% użycia CPU.
Tworzenie dodatkowego rekordu(pracownika) to był na początku skok o ponad 40% w użyciu CPU a teraz skacze do 100% a i jest komunikat w przeglądarce
@Jojne_Zimmerman: Dowalało 100% bo po dodaniu apki produkcyjnej zapomniałem skasować apke devepment z tomcata. Obie korzystały z tej samej bazy i to mogło powodować problem. Aktualnie rails w trybie production postawiony na tomcacie, za serverem apache2 łapie znośne dwadzieścia pare % CPU przy dodaniu nowego rekordu, poniżej 20% przy odświeżeniu wszystkich. 0.7% w spoczynku. Chyba rzeczywiście tryb dev miał na to wpływ. I o dziwo łapie max ~50% gdy dodaje
@Jojne_Zimmerman: also: We're sorry, but something went wrong. - masz ustawienie produkcyjne. Na czas programowania włącz dev. I osobiśćie gryzłbym za spolszczanie modeli i parametrów. ;)
@Jojne_Zimmerman @marahin: przeczytałem i doczytałem. CPU ma bardzo duże zużycie, bo to... JRuby. A JRuby ma to do siebie, że ora CPU, ale jest bardzo stabilne. Osobiście korzystam na produkcji z trzema apkami, w tym jedna która regularnie odświeża informacje, parsuje i wyświetla. Load zawsze koło 1 - 1.1, przy reloadach nginxa / restartach aplikacji, przy starcie JRuby, sięga 100%. Jeśli chcesz tego uniknąć, musisz iść w MRI.
Mam serwer-debian x8664 na vboxie, goszczony na lubuntu, procesor amd x3 1.8GHz.
Na debianie działa jre7+apache2+tomcat7. Serwer działa po to by chodziło na tym jruby i railsy ze standardową bazą sqlite.
Jest to najprostsza testowa apka zrobiona za pomocą:
Problem jest w tym, że jak robie coś na railsach poprzez przeglądarke(dodawanie użytkowników poprzez wypełnianie tych 3 pól tekstowych) to zużycie CPU na wirtualnym, jednordzeniowym debianie skacze mi do 40%. Zużycie ramu to przec cały czas 360MB. Żeby było jasne Debian na vboxie nie ma X Window System.
/proc/cpuinfo na Debianie pokazuje 1 rdzeń 3GHz
na systemie głównym są 3 x 1.8GHz
Jeden człowiek używa apki a ta zużywa momentami 40% cpu.
Jest to najgówniańsza apka-demo jaką da się zrobić w rails.
To jest normalne? Dodam, że na VPS na hostingu gdzie chciałbym to przetestować działa np. jeszcze postfix+dovecot które też byłyby używane przy rejestracji, a jako baza postgres zamiast sqlite. VPS na hostingu to najtańszy testowy VPS z jednym wątkiem na
AMD Opteron(tm) Processor 6128
cpu MHz : 2000.000
Do tego firma hostingowa nie życzy sobie aby ten cpu był przez dłuższe okresy wykorzystany na max.
Dlatego zanim zmarnuje czas na stawianie tej konfiguracji na VPS chciałbym się zapytać tutaj jak się ma wydajność na virtualboxie do wydajności na vps (hosting ma vps na VMware zamiast Vbox).
Może ktoś wie jaki trzeba mieć serwer aby obsłużył jednocześnie np. 5 użytkowników na konfiguracji jre7+apache2+tomcat7+rails i nie dostawał zadyszki (ile ramu i wątków).
W końcu może to też wina railsów w trybie development enviroment i cache? A może konfiguracji czegoś z trio jre7, apache2, tomcat?
Troche jestem zdziwiony po podobno_ jruby miało być szybsze od zwykłego ruby.
#java #programowanie #ruby #rails #hosting #vps
Próbowałeś sprawdzić jak chodzi nie w trybie dev, tylko produkcyjnym?
Zainstalowałem w trybie produkcyjnym.
Każde odświeżenie strony z 11stoma utworzonymi pracownikami to wzrost użycia CPU w kilku procesach Tomcata. Łącznie każde odświeżenie to 20% użycia CPU.
Tworzenie dodatkowego rekordu(pracownika) to był na początku skok o ponad 40% w użyciu CPU a teraz skacze do 100% a i jest komunikat w przeglądarce
We're sorry, but something went wrong.
Dowalało 100% bo po dodaniu apki produkcyjnej zapomniałem skasować apke devepment z tomcata. Obie korzystały z tej samej bazy i to mogło powodować problem.
Aktualnie rails w trybie production postawiony na tomcacie, za serverem apache2 łapie znośne dwadzieścia pare % CPU przy dodaniu nowego rekordu, poniżej 20% przy odświeżeniu wszystkich. 0.7% w spoczynku.
Chyba rzeczywiście tryb dev miał na to wpływ. I o dziwo łapie max ~50% gdy dodaje
Komentarz usunięty przez autora
Prócz