pleple

Mi neo w mieszkaniu studenckim w ciągu ostatnich tygodni pada kilkukrotnie każdego dnia. Za zwyczaj na parę minut ale każdego dnia. Centralkę mam 300 m od siebie, parametry łącza są jak marzenie ale po prostu rozłącza się router i nie może zsynchronizować. W domu natomiast neo chodzi bez jakichkolwiek przerw od paru miesięcy. Wszystko więc zależy od tego gdzie się mieszka.

W ogólności tak, w końcu ns1 to jakiś serwer, nie ?

"Możemy" a nie "mogą"? To już wróży źle.. A poza tym wystarczy spojrzeć na stronę, panie haker co oferuje audyty bezpieczeństwa. Perl 5.6 i PHP 4.2.3, to jakiś żart?

Polska jest w UE już ładnych parę lat. Może czas na update wiadomości politycznych ?

To poczekaj może jeszcze troszkę bo właśnie jest w końcowej fazie opracowywania nowy sheduler w jądze Linuksa - CFS. Bardzo prawdopodobne, że zostanie włączony już do 2.6.24.

Według mnie nie zupełnie. Przy stałej szybkości magistrali oraz pamięci, procesor może być szybszy lub wolniejszy. Przyspieszenie działania pamięci bądź magistrali nie przyspieszy znów działania procesora. Kiedy trzeba współpracować, wtedy oczywiście (jak wspomniałem i ja i Ty) wszystkie współpracujące części mają wpływ na szybkość działania systemu (ale nie jest to wpływ wprost). W dzisiejszych czasach żaden procesor (przynajmniej z takich dostępnych śmiertelnikom) nie ma odpowiednio dużego cache, według Twojej definicji:) Cache opiera się na zasadzie lokalności (czasowej i przestrzennej) zasobów, ma ograniczyć odwołania do pamięci z podobnego obszaru w ciągu pewnego (niezbyt długiego) okresu czasu (żeby np móc przechować w cache kontekst procesu i najważniejsze dane z jakich korzysta podczas jego działania). W przypadku systemów wielozadaniowych ogólnego przeznaczenia nie da się jednak uniknąć ciągłego skakania po obszarach pamięci a ilość cache jaką posiadamy jest średnio 100-1000 razy większa niż ilość pamięci operacyjnej jaka jest używana przez system. Tak więc procesor zasadniczo mamy o dwa rzędy wielkości za mało cache, żeby procesor mógł relatywnie rzadko odwoływać się do pamięci i żeby pamięć ta nie była bezpośrednim wsparciem dla procesora Inna sprawa, że to kłóciłoby się z zasadą działania cache... Ale chyba dopiero po wyedytowaniu więc przed tym jak ja zacząłem odpowiadać. Tak. To jest makro liczące: #define CALC_LOAD(load,exp,n) \ load *= exp; \ load += n*(FIXED_1-exp); \ load >>= FSHIFT A tak jest używane: static inline void calc_load(unsigned long ticks) { unsigned long active_tasks; /* fixed-point */ static int count = LOAD_FREQ; count -= ticks; if (unlikely(count < 0)) { active_tasks = count_active_tasks(); do { CALC_LOAD(avenrun[0], EXP_1, active_tasks); .... Tutaj jest definicja count_active_tasks() (z kernel/timer.c): static unsigned long count_active_tasks(void) { return nr_active() * FIXED_1; } FIXED_1 to po prostu 1.0 w IEE754, a nr_active jest zdefiniowane w kernel/sched.c: unsigned long nr_active(void) { unsigned long i, running = 0, uninterruptible = 0; for_each_online_cpu(i) { running += cpu_rq(i)->nr_running; uninterruptible += cpu_rq(i)->nr_uninterruptible; } if (unlikely((long)uninterruptible < 0)) uninterruptible = 0; return running + uninterruptible; } Tak więc wliczają się tylko aktywne i nieprzerywalne. Jakbyś miał wątpliwości to w kernel/sched.c jest zdefiniowanych trochę innych niż nr_uninterupatble i nr_running (jest np nr_iowait czy nr_context_switches, które jak widać nie są wliczane.

To tylko jedna ze składowych. Istotna jest też szybkość pamięci, szybkość magistrali itp (należy też zauważyć, że szybkość działania poszczególnych komponentów jest ze sobą powiązana). Load avarage jest takim dziwnym wskaźnikiem, który w prost zależy od długości kolejki procesów planisty. Mówiąc prościej, load avarage jest tym niższy im więcej czasu procesy śpią.

Nie. Load jest parametrem globalnym dla całego systemu. W pewnym sensie loadavg jest funkcją zależną od "jakości sprzętu". To właśnie ona decyduje o tym jak szybko może dany proces zakończyć swoje działanie a im dłużej ten działa tym większy loadavg generuje. Zobacz mój post w tym temacie żeby dowiedzieć się czym dokładnie jest load avarage: http://www.webhostingtalk.pl/index.php?showtopic=9526

W ofercie nie jest napisane ile kosztuje dodatkowy transfer po przekroczeniu bazowego limitu w przypadku serwerów dedykowanych. Chyba dajecie możliwość dokupienia transferu? Miło by również było gdybyście trochę przybliżyli trochę informacji na temat Waszego DC, zabezpieczenia jakie posiadacie na wypadek różnych awarii, łącza itp.

A myślisz, że społeczność innych krajów to co, lepsza jest? P.S. Często czytam Twoje posty i nie rozumiem. Zepsuły Ci się klawisze odpowiadające za znaki przestankowe?

krk jeśli nie wiesz jaką dystrybucję wybrać to znaczy, że totalnie nie znasz tematu. Najlepiej więc weź taką, której używa jakiś Twój znajomy albo taką do której najłatwiej jest Ci znaleźć jakąś pomoc (pogooglaj chwilę za jakimiś grupami użytkowników tych distro czy forami, itp). Myślę, że jeśli chodzi o OpenSUSE to chyba najsłabiej jest ona przystosowana do serwerów. Fedora choć na serwer się nadaje to nie polecam jej ze względu na jej politykę wydań (krótkie cykle, krótki support itp.). Poza tym niedługo (pewnie kwestia dni) wyjdzie już Fedora 8 a Ty masz tylko 6 do wyboru. Pozostaje więc Debian (spora społeczność, długie cykle wydań, mocno dopracowane distro), najlepiej w wersji 4 bo 3.1 to już niezły dinozaur (wyszedł ponad 2 lata temu). P.S. Strasznie treściwa odpowiedź kisiek.

Widzę, że nie bardzo jesteś zorientowany w temacie więc napisze bardzo ogólnie i mocno upraszczając: Nie da się przekroczyć ilości posiadanego RAMu. Jak go zabraknie to procesy nie będą mogły się po prostu odpalić, lub będą się zatrzymywać bo nie starczy im do zaalokowania. Jest jeszcze kwestia partycji wymiany, która zapobiega temu by zbyt szybko skończył się RAM ale działa to strasznie wolno.

Ale ja nie mam i nigdy nie miałem zamiaru przekonywać ani Ciebie ani nikogo innego (bo i niby jaki miałbym mieć w tym interes?). Tym bardziej nie uważam, że migracja jest wskazana. Opiekuję się sporą ilością maszyn, do tego studiuję, mam swoje projekty oraz inne zajęcia. Na za dużą ilość wolnego czasu nigdy nie narzekałem. Nie mam zamiaru migrować na 32bit ale kiedy i tak konfiguruję nową maszynę to często wybieram (choć nie zawsze mogę wziąć udział w podjęciu decyzji bo to w końcu nie moje serwery) 64bit. Też póki co nie widzę sensu migracji, nie uważam żebyś był kiedyś zmuszony do niej ale w pewnym momencie (i to myślę, że za parę lat) stanie się to niepraktyczne bo wszyscy skupią się już na 64bit jako standardzie i to na 32bitach będą problemy z odpaleniem oprogramowania. Nie jestem fanem 64bit, nie propaguje używania systemów 64 bitowych i zasadniczo to jakich wersji systemu używają inny mi po prostu... sam wiesz.

Nie chodzi mi o odbijanie piłeczki ani tym bardziej o przekrzykiwanie. Nie rozumiem tylko zupełnie tego podejścia. Nowe standardy? Hardcore? PHP6? Jak to się ma do architektury 64bit? 64bitowe architektury w Linuksie są od dawna a i x86-64 trochę czasu tu jest. 64 bitowe procesory to po prostu codzienna rzeczywistość a nie jakaś nowość. I mi w ogóle nie chodzi o te pare % (bo w rzeczywistości w pewnych sytuacjach 64 bitowa architektura może być wolniejsza) ale właśnie o brak problemów w przyszłości (wolę już mieć system 64 bit niż później migrować). Podsumowując: Ty wolisz 32bit bo dzięki temu masz więcej wolnego czasu. Mi użycie 32bitowego systemu (na serwerze) nie przynosi ani trochę więcej wolnego czasu niż użycie 32bitowego więc na prawdę nie widzę powodów dla którego miałbym nie używać 64bitowego systemu już teraz (i to na nim budować infrastrukturę) i nie martwić się o migrację za parę miesięcy/lat. Każdy ma swoje racje, tyle.

Ale nigdy nie będzie tak samo przetestowane jak ludzie nie zaczną go używać, prawda? Poza tym to, że nie jest aż tak przetestowane jak oprogramowanie 32bitowe to nie znaczy jeszcze, że jest ZA mało przetestowane (ostatecznie nie ma aż tak dużo zmian żeby dużo było do testowania). Co do pytania to uważam, że warto. Co prawda narażasz się na trochę nowych problemów ale jednocześnie też pozbywasz się pewnych innych. Póki co, szczególnie w jądrze Linuksa, obsługa architektury 64bitowej jest DUŻO czystsza i przejrzysta.

Procesory 64 bitowe są zasadniczo szybsze jak pracują w swoim natywnym trybie. I powiedzenie, że używanie natywnego trybu jest "pchaniem się na siłę" jest według mnie totalnym nonsensem.

I skąd wartość akurat 3GB? Bo 4GB można zaadresować w 32bit? No i co z tego? Używając PAE można spokojnie zaadresować 64GB nawet na 32bit.

Z Javą to też zdaje się problem polega tylko na braku pluginu do przeglądarek. Sama maszyna wirtualna jest, nie ?

Zasadniczo jeśli oprogramowanie jest OpenSource i używa go więcej niż kilka osób to najprawdopodobniej już działa na 64bit. Kwestia dostosowania oprogramowania do 64bit jest rzeczą banalną (chyba, że oprogramowanie odwołuje się bardzo mocno do sprzętu ale niewiele jest takiego). Są już przecież wersje 64bit każdej dystrybucji i za zwyczaj ich repozytoria są niewiele mniejsze niż odpowiedników 32bit. To fakt, oprogramowanie 64bit nie jest aż tak przetestowane (bo jest mniej użytkowników tej architektury) a niestety czasem pewne błędy występują tylko w przypadku systemów 64bit. Mimo to stawiając nowy serwer (gdyby to zależało ode mnie) nie wahał bym się i użył 64 bitowej dystrybucji.

Sry.. miało być "przy tworzeniu procesów FastCGI..". Taki proces tworzony jest raz na wiele wywołań strony. Inaczej jest z CGI kiedy to proces tworzony jest za każdym razem więc nie rozumiem czemu pierwszy miałby trwać tak długo a następne już nie.

CGI? Jakoś nie widzę powodów dla których na CGI tak miałoby być. Wtedy raczej przy każdym wygenerowaniu strony czas byłby taki sam. Ja raczej stawiam na to, że albo przy tworzeniu procesu CGI coś długo zajmuje albo procesy są po prostu wyswapowane (ale wtedy odpalenie strony nie powinno zając więcej niż sekundę-dwie).

A spytałeś czy maja zamiar to poprawić skoro czasem się zdarza? Pewnie odpowiedź brzmiała (by) "niestety używamy oprogramowania od lxlabs.com więc nie możemy nic zrobić"...

Albo łatwiej, i prawie tak samo dobrze - zmienić ciężkiego prefork MPM na o niebo wydajniejszy MPM worker.. P.S. To ciekawe jak ludzie dają się nabierać na te porównania w stylu "jesteśmy N razy szybsi niż Apache"... Tak Apache to niezły kombajn ale też sam w sobie jest właściwie głównie takim frameworkiem (APR + APR-UTILS) i pewnym szkieletem. Tam praktycznie wszystko dzieje się wewnątrz modułów, które można swobodnie wymieniać. Silnikiem jest MPM i to od niego najwięcej zależy w kwestii wydajności. Nie widzę powodów dla których jakiś serwer WWW miałby być o niebo szybszy i lżejszy od takiego samego rozwiązania stworzonego w formie modułów Apache. Prefork jest ślamazarny (ale domyślnie w większości dystrybucji Linuksa i innych systemów używa się go domyślnie dla kompatybilności) i żaden nowoczesny serwer nie używa takiego podejścia. Ale mamy do wyboru worker, event, threadpool, leader (eksperymentalne) i wiele zewnętrznych modułów (ITK, metux, perchild itp).

No i dochodzisz do tego momentu, gdzie albo musisz kupować coraz to lepszy sprzęt bo oprogramowanie jest zaprojektowane do używania zasobów tylko jednego serwera, albo zmieniasz oprogramowanie.

Ta.. a poza tym zawsze źle napisanej aplikacji to będzie za mało..