cyberluk

Heh uwielbiam takie ściemy A jakiś regulamin możliwości wykorzystania tego RAMu? Skoro jest taka możliwość i to bezpłatnie, to czemu nie dać po prostu 512MB? To tak jak z tymi ciągłymi "okazjami" w sklepach...

Normalnie biorę 1500 zł netto za miesiąc, ale mogę zejść do 1000 zł. Umowa o dzieło. Może być?

Oj dobra, w drugim temacie dopisałem, że może być FreeBSD. Ale nie zgodzę się, że *BSD jest lepsiejsze od Solka Od linuksa - owszem (zresztą już kiedyś gadaliśmy na ten temat).

Ja Ci polecę komplet Dedyk + Solaris. Jak dopiero zaczynasz, zacznij od porządnej platformy. Pracując na linuksie spotka Cię z czasem wiele rozczarowań...

Rozumiem, że za godzinę? Mogę Ci wysłać moje CV.

Źródełka... Przynajmniej 2.6.22...

I to on Ci pewnie zabija procka... Nie zapytałem o najważniejsze... Masz EXT3 na tych dyskach? Kjournald odpowiada za uaktualnianie zmian "dziennika" przy filesystemie, tzw. journala.

Ja mam tak: avg-cpu: %user %nice %system %iowait %steal %idle 1,00 0,00 8,00 38,00 0,00 53,00 Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn sda 188,00 18,64 18,21 18 18 avg-cpu: %user %nice %system %iowait %steal %idle 1,99 0,00 7,96 64,18 0,00 25,87 Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn sda 139,00 9,51 25,79 9 25 avg-cpu: %user %nice %system %iowait %steal %idle 1,50 8,50 4,50 45,00 0,00 40,50 Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn sda 113,00 1,52 16,74 1 16 avg-cpu: %user %nice %system %iowait %steal %idle 0,51 33,84 4,04 10,61 0,00 51,01 22:56:43 up 3:46, 8 users, load average: 0.59, 0.30, 0.25 [code][13604.576000] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [13604.576000] ata3.00: configured for UDMA/133 [13604.576000] ata3: EH complete [13604.576000] sd 2:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [13604.576000] sd 2:0:0:0: [sda] Write Protect is off [13604.576000] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00 [13604.576000] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Dodam, że jest to dysk w laptopie. Przyszło mi do głowy jeszcze coś. Nie odpalił Ci się żaden trackerd/beagle albo coś podobnego? Bo to one mogą powodować taki duży load. To co ja kopiowałem do tych logów było indexowane przez tracker'a

Z iostata ładnie widać, że faktycznie system leży na I/O Wait. Są dwie możliwości: 1. Kernel nie obsługuje Ci poprawnie kontrolera, postaraj się zrobić upgrade. Nie wiem, który masz kernel, ale przy moich problemach z i965 wystarczył z 2.6.18 na 2.6.22. 2. Trafiłeś na lewe dyski. Mam w domu WDka 80GB, który chodzi jak krew z nosa. Taka seria dysków wyszła sobie, która wszystkie operacje odczytu rozbija na bardzo małe requesty I/O. Koniec końców, dysk dobija do 280tpsów, system jest zajechany, a transfery słabe. Sprawdzałem go na wielu kontrolerach, płytach i system operacyjnych - zawsze to samo. W końcu znalazłem info, że chłopaki mają błąd w firmwarze i... no i ten dysk tak ma. 300tpsów przy odczycie jednego dużego pliku to baaaardzo dużo. Jak jeszcze to przełożysz na 32MB/sec, to już w ogóle porażka... Sprawdź nowy kernel na początek, a jak nie, to zostaje lipa z dyskami.

Odpal podczas kopiowania iostat -m 1 i wklej kilka linijek jak już w systemie load podskoczy. Wyszukaj w logach (np. dmesg) wszystko co dotyczy inicjalizacji kontrolera i wklej tutaj. Ja tak miałem 2 dni temu z płytą Intela na i965 i Core2 Duo. Do tego dorzucili jakiegoś pseudoPromisa i dopiero ostatni kernel pomógł... Kernel nie potrafił pogodzić obsługi przerwań z 2 corami, zaraz potem wykopywało się DMA i dysk chodził jak stacja dyskietek.

pff, czym tu się podniecać - trochę nowych bladów wsadzili do szafki i wielkie halo Btw, z tymi bladami jest straszny problem cieplny... 3 miechy temu jak testowałem sprzęt pod nową platformę, to miałem HPki, Intele i IBMy. Koniec końców kupione zostały maszynki 1U.

Albo przegapiłem, albo nikt nie wspomniał o ATM. Miesiąc temu jak szukałem DC do mojego projektu dali mi lepszą ofertę od GTS'a. Bardzo profesjonalne podejście no i jakby nie patrzeć - mają lepsze łącza niż GTS.

Czekaj, czekaj. Ja cały czas staram Ci się uświadomić, że ten konkretny benchmark, który wszyscy odpalali jest z tyłka. To, że każdy benchmark jest obłożony błędem to chyba logiczne. Kwestia jest taka, że może to być benchmark całkiem z tyłka (taki jak ten PHPowy), albo specjalnie napisany pod testy danego systemu - wtedy taki benchmark będzie całkiem dokładny. Przestrzelenie wydajności systemu o 5% w porównaniu do 200% czy 300% jest chyba sporą rozbieżnością. Ba, nie wspomnę już o zignorowaniu sporej części elementów systemowych i programowych, które mogą mieć wpływ na wydajność hostingu, a w tym konkretnym benchmarku zostały pominięte. To tak jakbyś w czasie prowadzenia projektu miał kupić serwery za 1 mln zł. Albo się pomylisz o 10% i będzie +/- 100k zł, albo się pomylisz o 200% i wyjdzie, że albo serwery wcale nie są potrzebne, albo będą kosztowały 3mln zł Np. system hostingowy Ja wiem co tam się znalazło. Nie zmienia to faktu, że program dał się skompilować i nawet się uruchomił. Dobra, bo pewnie żaden z nas nie ustąpi Ten konkretny benchmark PHP jest z tyłka - z tym się chyba zgodzisz. Każdy benchmark jest opatrzony błędem - z tym też się chyba zgodzisz. Benchmarki są potrzebne - muszą być napisane w odpowiedni sposób i musimy wiedzieć, czego oczekujemy od systemu i co chcemy zmierzyć - musimy stworzyć metodologię benchmarka. To chyba też jest jasne. Peace

A kto mówi o warunkach domowych? Ja mówię o laboratorium, gdzie mam 15 serwerów i każdy z nich może generować jakiś rodzaj ruchu. Jak robiliśmy testy Oracla z Novellem i IBMem, to soft do benchmarku udawała setki klientów robiących zakupy w sklepie. I wiesz co? Był na tyle dokładny, że po wdrożeniu systemu wynik różniły się o 5% od rzeczywistego obciążenia systemu... Oczywiście podpieranie się benchmarkiem opartym na ab, czy podobnym narzędziu też nie jest miarodajne. Jest na 100% lepsze niż przedstawiony tutaj benchmark, ale daleko mu do prawdziwego softu do wykonywania testów. Przy odpowiedniej składance narzędzi i przygotowaniu środowiska testowego da się w miarę dokładnie określić wydajność platformy. Dla każdego systemu da się napisać benchmark. Musi on być zrobiony z głową. Im bardziej skomplikowane środowisko, tym więcej pracy trzeba włożyć w przygotowanie testów. Ależ proszę bardzo: Co nie zmienia faktu, że jest to tylko warning i dało się przypisać tak dużą liczbę do int'a. Ba program nawet się uruchomił... Tak, wiem - dobry programisty pisze kod na tyle czysto, żeby nie było warningów. Ale dobry programista nie przypisuje tak dużej liczby do int'a świadomie. Natomiast sprawdzenie, czy wynik 2^128 zmieści się w int nie leży już w "kompetencjach" kompilatora i on po prostu coś takiego oleje... Wiem, że nie powinien - pewnie dlatego większość kodu tworzę w C, a czasami w assemblerze...

Ależ oczywiście, że prędkość hostingu jest mierzalna. Ba, nawet lepiej pokaże wydajność całej platformy, niż składanie takiego wyniku z kawałeczków. Co z tego, że w dodawaniu PHP wypadnie Ci mega-super-hiper ekstra, jeżeli okaże się, że np karta sieciowa jest z tyłka i totalnie zamuli Ci środowisko, albo dyski nie wydolą i skrypty będą wisiały w oczekiwaniu na I/O? Prosty przykład. Odpalałem ten skrypt (chodzi mi o tego PHP'a) na wypasionej maszynie - 2x Quad Core Xeon, 16GB RAMu, podpięty po FC do macierzy 2TB zbudowanej na dyskach 36GB 15k obr/min (policz sobie wydajność I/O tego systemu) z 4GB cache. I wiesz co? Chodził porównywalnie lub gorzej niż na progresso - oboje korzystamy z Debiana i wydaje mi się, że na progreso php był/jest z paczek. Różnica jest taka, że w przypadku hostingu ta maszyna pociągnęłaby klientów z 4 albo 5 maszyn progreso... Gdzie tutaj Twoja logika? Gdzie jakość tego benchmarku? Można, tylko kod nie wykona się w skończonym czasie Różnica wynika w doskonałości kompilatora. Kompilator w Javie wie, że ta pętla jest pusta i nie będzie jej "kręcił"... To jest "ficzer" języka zaimplementowany przez jego twórców. C tak nie potrafi... Żaden kompilator nie będzie wiedział, czy "pojemność" zmiennej nie skończy się w trakcie działania programu. Jakby tak było - ehh piękne czasy - zero buffer overflow itp...