Мерси много.
1. И на мен ми направи впечатление това. Монгрелите наистина гълтат
памет.
2. По принцип карам с компилирано от сорс ръби. Причини - собствената
ми глупост. Има части от сайта (за щастие, административни), които
ползват стара версия на hobo, която работи с пачнат rexml, страшно
бавен. Който на всичкото отгоре не работи с нови ruby дистрибуции. Май
първото което трябва да направя, е да ги изхвърля. Ето и резултата от
strace:
<pre>
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
nan 0.000000 0 9 read
nan 0.000000 0 16 open
nan 0.000000 0 16 close
nan 0.000000 0 32 27 stat
nan 0.000000 0 9 fstat
nan 0.000000 0 27 mmap
nan 0.000000 0 8 mprotect
nan 0.000000 0 2 munmap
nan 0.000000 0 13 brk
nan 0.000000 0 12 rt_sigaction
nan 0.000000 0 2 rt_sigprocmask
nan 0.000000 0 9 9 access
nan 0.000000 0 1 execve
nan 0.000000 0 1 getrlimit
nan 0.000000 0 1 getuid
nan 0.000000 0 1 getgid
nan 0.000000 0 2 geteuid
nan 0.000000 0 2 getegid
nan 0.000000 0 1 arch_prctl
------ ----------- ----------- --------- --------- ----------------
100.00 0.000000 164 36 total
</pre>
Имам някакви проблеми точно с GC, ще прегледам enterprise-а. Макар че
думичката ми вдъхва страх.
Мерси и за останалите препоръки. Ще пробвам да swap-на с thin, и ще
пиша впечатления. Upload-а за сега не боли.
Петьо
On Aug 11, 5:05 am, Stoyan Zhekov <sto...@gmail.com> wrote:
> On Aug 10, 5:37 am, Петьо Иванов <under
...@gmail.com> wrote:
> > От една седмица деплойвам дълго разработвания и мигриран семеен
> > бизнес, който бъхтя от половин година. Реших да си споделя
> > впечатленията, белким помогнете, или помогнат на някого.
> Универсални рецепни няма, но все пак ето някой неща, които надявам се
> да помогнат:
> 1. slicehost: Използват 64-битови Xen domUs - хубаво за mysql, но Ruby
> процесите използват доста памет - почти два пъти повече, отколкото на
> 32 битови domU. Затова се отказах от slicehost.
> 2. Ruby: Не знам каква дистрибуция ползваш, поне на Debian/Ubuntu Ruby
> се компилира с --enable-pthread заради ruby-tk, което при vps доста
> забавя нещата. Малък тест:
> strace -c ruby -e '1.upto(100000) {|i| i.to_s}'
> и виж реда:
> 99.65 1.462627 7 200006 sigprocmask
> Дискусия по проблема:http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/a3...
> Добра идея е може би също да използваш ruby-enterprice [http://www.rubyenterpriseedition.com/] - patch-нати са garbage
> collection, memory allocator и др.
> 3. nginx: всички напоследък го препоръчват, но все пак не е silver
> bullet - Добър е за статиката, но като load balancer е слаб. По
> принцип си идва с прост Round Robin. RoR е извесна с това, че обслужва
> само по един request - то си е CGI базирано. Затова и ти трябват
> повечко application servers, било то mongrel или thin. Но ако е прост
> Round Robin и вече се обслужва някой request, nginx просто натиква
> следващия в опашката на поредния app server и той си чака там. Така
> скоро всички процеси са заети. Решения:
> - nginx-fair balancer: [http://wiki.codemongers.com/NginxHttpUpstreamFairModule
> ]
> - HAproxy (което бих ти препоръчал) -http://affectioncode.wordpress.com/2008/06/28/another-comparison-of-h...
> 4. god: Поне аз предпочитам monit [http://www.tildeslash.com/monit/]
> - лично мнение. Мисля, че ползва по-малко памет.
> 5. thin: предимствата са, че може да го "вържеш" с nginx на unix
> socket - някой твърдят, това ускорява нещата -http://macournoyer.wordpress.com/2008/01/26/get-intimate-with-your-lo...
> . Но ако ползваш HAproxy, това май губи смисъл.
> 6. Може да помислиш по пренаписването на някой части (специално ако
> има upload) от сайта на Merb [http://merbivore.com/] - по-малко
> памет и по-бърз (не е CGI базиран и би трябвало да обслужва няколко
> request-а едновременно).
