Skocz do zawartości

cyberluk

Użytkownicy
 Wyświetl profil  Zobacz jego aktywność

  • Zawartość

    97

  • Rejestracja

  • Ostatnio

Posty napisane przez cyberluk

  1. Napisano · Raportuj odpowiedź

    możliwe bezpłatne użycie do 512 MB RAM

     

    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...

  8. Napisano · Raportuj odpowiedź

    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 :)

  9. Napisano · Raportuj odpowiedź

    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.

  10. Napisano · Raportuj odpowiedź

    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.

  11. Napisano · Raportuj odpowiedź

    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.

  13. Napisano · Raportuj odpowiedź

    kluczowe w tej wypowiedzi jest "w miare" , dziekuje :0

     

    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ł ;)

     

    zgadzam sie z tym - szczegolnie z tym ze test ma byc pisany POD KONKRETNY SYSTEM

    Np. system hostingowy ;)

     

    to jeszcze tylko dla zaspokojenia wlasnej ciekawosci sprawdz sobie co tak _naprawde- znalazlo sie z omawianej zmiennej

    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 :)

  14. Napisano · Raportuj odpowiedź

    hosting to "zywy organizm" nie jestes w stanie go dobrze przetestowac bo albo zrobisz test "rozrywkowy" w warunkach domowych czyli cala maszyna twoja, albo na uzywanej przez kilka (nascie/dziesiat/set) osob maszynie

     

    zadna z powyzszych sytuacji nie odda prawdziwego obrazu - pokaze tylko _mniej wiecej_ co mozna uzyskac

     

    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.

     

    prosze skompiluj w gcc cos takiego:

    int a= 100000000000000000000000000000000000000000000;

    (oczywiscie bez "ficzerow" w stylu bignum ;) )

    Ależ proszę bardzo:

     

    cyberluk@snoopy:~$ gcc -o test_file test.c

    test.c:3:9: warning: integer constant is too large for its type

    test.c: In function 'main':

    test.c:3: warning: integer constant is too large for 'long' type

    test.c:3: warning: overflow in implicit constant conversion

    cyberluk@snoopy:~$ ./test_file

     

    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...

     

    j++ _zawsze_ zajmie cos w pamieci chocby glupi jeden bajcik na INC

     

    a jesli rozpatrujesz wersje bez j++ (zauwazylem twoja poprawke: EDIT) to i tak kompilator nie powinien sobie ot tak wywalic kawalka kodu - ktory z pozoru nic istotnego nie robi bo jak by na to nie patrzec taka petla moze miec istotny wplyw na dzialanie calego programu

    Wiem, że nie powinien - pewnie dlatego większość kodu tworzę w C, a czasami w assemblerze...

  15. Napisano · Raportuj odpowiedź

    i o to chodzi,

    wiekszosc rzeczy ktore maja istotny wplyw na czas generowania strony (czyli "szybkosc" dzialania hostingu) nie jest mierzalna, to co mozemy zmierzyc daje jakis mniej lub bardziej PRZYBLIZONY obraz rzeczywistosci

    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?

     

    co do dopisywania zer to oczywistym jest ze nie mozna tego robic bez konca

    Można, tylko kod nie wykona się w skończonym czasie ;)

     

    co do kodu w c i javie roznica w czasie wykonania nie wynika w doskonalosci jezyka (srodowiska) a raczej z jego niedoskonalosci - jesli wprowadzisz liczbe (w kodzie) wieksza niz 32 bitowa (zakladam prace w srodowisku 32 bitowym) to zostanie ona "przycieta" (dobry kompilator powinien wywalic blad) do wartosci ktora mozna upchnac na 32 bitach moze to byc proste obciecie / zaokraglenie, w efekcie wcale licznik petli nie bedzie zawieral liczby ktora oczekujemy lecz jakas "przyblizona" - na pewno mniejsza od oczekiwanej

    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...

  16. Napisano · Raportuj odpowiedź

    pisalem o twoim tescie a nie o tym omawianym

     

    z ta "drobna " roznica, ze kod twojego testu miesci sie w pamieci cache

     

    a ten wokol ktorego toczy sie dyskusja nie

     

    tu moja pomylka, zle policzylem ilosc zer :)

     

    Tylko, że mój test robi prawie (podkreślam prawie, bo nie chciało mi się przepisywać go dokładnie - to ma być tylko przykład - chodzi głownie o pętlę) dokładnie to samo co ten PHPowy. Chodziło mi o pokazanie, ze testujesz tak naprawdę jakość języka-kompilatora/interpretera/vm'a, a nie wydajność platformy hostingowej. To czy jest to napisane w C, czy w PHP, czy w Javie nic nie zmienia... To, że mój kod zmieścił się w cache też o niczym nie świdaczy. Po prostu wynik będzie lepszy. Cały trick polega na tym, że taki test sprawdza tylko malutki kawałek języka-kompilatora/interpretera/vm'a, który ma się nijak do sprawdzenia całej platoformy. Nie będę już wspominał takich o zmianie trybu pracy PHP'a...

    Nie wiem jak to prościej wytłumaczyć. To tak jakbyś za pomocą programu w C, które realizuje:

    - weź dwie liczby

    - pomnóż je przez siebie

    - dodaj do trzeciej

    - weż literki od a dof

    - wpisz pod adres pamięci

    - dopisz na końcu te literki poprzedniego ciągu znaków

    - powyższe operacje wykonaj 100k razy i zmierz czas

     

    Chciał przetestować scheduler w kernelu albo podsystem I/O... Już rozumiesz o co chodzi?

     

    Ten PHPowy benchmark możeby być jakimś marnym miernikiem wydajności maszyny, jeżeli:

    - odpalisz go na czystej maszynie - zapiszesz wynik

    - odpalisz na obiciążonej maszynie - zapiszezs wynik

    - porównasz te wyniki

    Wtedy wyjdzie Ci mniej więcej ile procentowo masz dostępnego czasu procesora. Nadal nie jest to testowanie platformy, tylko konkretnej, okrojonej funkcjonalności w samym PHP i konkretnego składnika systemu jakim jest procesor.

     

    A co do zer ;)

    Dopisałem jeszcze jedno:

    cyberluk@cyberluk-desktop:~$ time ./benchamrk

     

    real 0m0.199s

    user 0m0.192s

    sys 0m0.004s

    i jeszcze:

    cyberluk@cyberluk-desktop:~$ time ./benchamrk

     

    real 0m2.030s

    user 0m2.000s

    sys 0m0.028s

    I tak mogę dopisywać ;) Fakt, że po którymś razie pętla będzie wykonywała się 10 lat, ale w końcu się wykona :)

     

    Z ciekawostek - wiesz, że powyższy kod, jeżeli wpisze mu tam 64 zer skompilowany za pomocą C będzie pewnie się kręcił kilka lat. W javie ten sam kod wykona się w kilka ms? To tak żeby dodać pikanterii i pokazać, że takie pętle testują nie to co trzeba...

     

    EDIT: Eh mała pomyłka :) Ten ostatni przykład to pętla bez tego j++... Sorki

  17. Napisano · Raportuj odpowiedź

    to powyzsze "cos" jest kompletnie bez sensu gdyz:

    1 - brak "pomiaru" czasu

    2 - zakres zmiennych jest bledny i program nie wyjdzie z petli

    kolejna bzdura,

    testy tego typu nie badaja wylacznie wydajnosci procesora ani wydajnosci jezyka, maja zbadac jak szybko jest generowana strona ato zalezy od bardzo wielu czynnikow

     

    No i właśnie o to mi chodziło ;) Dokładnie na takiej pętli opiera się ten benchmark PHPowy. Czyli sam sobie odpowiedziałeś, że ten test jest bzdurą. Różnica jest taka, że tutaj miał być odpalany w postaci time ./benchmark - pomiar czasu przez gotowe narzędzie, a w benchmarku PHP ten pomiar był dodany - przed "funkcją do sprawdzenia wydajności" pobierany był timestamp pierwszy raz, po wykonaniu tej funkcji drugi raz i różnica, to była czas zwracany dla użytkownika.

     

    A teraz najciekawsze:

    cyberluk@cyberluk-desktop:~$ cat benchamrk.c

    int main() {

    int i,j;

     

    for (i=0; i<10000000; i++)

    j++;

     

    return 0;

    }

    cyberluk@cyberluk-desktop:~$ gcc -o benchamrk benchamrk.c

    cyberluk@cyberluk-desktop:~$ time ./benchamrk

     

    real 0m0.022s

    user 0m0.024s

    sys 0m0.000s

    cyberluk@cyberluk-desktop:~$

     

    A jednak działa ;)

  18. Napisano · Raportuj odpowiedź

    Ale logika jest prosta. Ten test nie ukazywał wydajności maszyn tylko ogólnie całego środowiska, więc i w jakimś stopniu określał efektywność i jakość serwerów (rozumianych jako szybkość działania strony klienta) danej firmy.

    Nie, ten test nie wykazywał niczego. OK, to może inaczej:

     

    void main() {

    int i,j;

     

    for (i=0; i<10000000; i++)

    j++;

    }

     

    Odpalamy od teraz ten test na wszystkich serwerach. Może to nie PHP, ale pokaże nam, jak wydajny jest kernel danego systemu :) Już rozumiesz o czym mówię? Testy, które działają w pętli i wykonują jakieś proste operacje typu dodaj dwie liczby, przepisz string do zmiennej nie mają żadnego sensu i wcale nie ukazują jakości czy wydajności środowiska. Co najwyżej mogą pokazać jak wydajny jest procesor (pojęcie względne) lub jak wydajny jest sam język.

    Na dokładkę powiem Ci, że na pustym Xeonie 3.6GHz ten "benczmark" wypadł gorzej niż na progreso...

  19. Napisano · Raportuj odpowiedź

    (...)

     

    podsumowujac: nie wazne jakiej jakosci jest test, jesli bedzie uruchomiony na roznych maszynach i tak da jakis obraz roznic miedzy nimi

     

    Błąd - ten test nie udowodnił niczego. Nie ma różnicy, czy PHP działa jako mod_php, jako CGI, jaki FastCGI czy jako CLI. Brak zmian przy różnych modułach. Ten test pokazał tylko, jak beznadziejnym językiem jest PHP i jak dużo poprawili w PHP5. Myślałem, że opisie jak działa benchamark to jest jasne...

  20. Napisano · Raportuj odpowiedź

    I co jej po takim łączu? :| Ostatnie test pokazały, że na Solarisie 10, który ma o 40% bardziej wydajny stos TCP/IP niż pozostałe systemy, do osiągnięcia 10Gbit/sec potrzeba:

    - stacja wysyłająca: 3 procesory SPARC T1 8 corów, 32 wątki

    - stacja odbierająca: 4 procesory SPARC T1 8 corów, 32 wątki

     

    Test był robiony benchmarkiem - chyba tt się nazywa.

     

    W przypadku normalnego ruchu, te wymagania będą przynajmniej dwa razy takie... Do tego 40Gbit i wychodzi maszyna, która cenowo zabije każdego :D

  22. Napisano · Raportuj odpowiedź

    Jeżeli masz linki >100m to tylko światłowód. Standardy xEthernet zostały przewidziane po miedzi na 100m i koniec. To, że komuś działa, nie oznacza, że będzie stabilne i poprawne. Chyba, że zrobisz tak:

     

    site | ---- 100m ---- switch ---- 100m ---- | 2 site

     

    z tym, że switch to taki switch prawdziwy, a nie jakieś switching-huby.

  23. Napisano · Raportuj odpowiedź

    Bo generalnie sie nie da :P Sa przypadki, w ktorych to jest mozliwe ale w ogolnosci przed DDoS'em sie nie obronisz :lol:

     

    Jasne, jest sprzet, ktory radzi sobie z naprawde poteznymi atakami... Sa nawet serwerownie, ktore pomagaja w zwalczaniu prostych atakow (a nawet tych wiekszych - oczywiscie w tym przypadku dochodza oplaty rozpoczynajace sie od 1000$). Ale jak juz zauwazyl bellerofont to nie sa rozwiazania, na ktore moze pozwolic sobie ktos posiadajacy kilka serwerow w budzetowej serwerowni (i nie posiadajacy pf'a :P).

    Z drugiej strony zastanawia mnie co to za atak, skoro Hetzner jeszcze nie zastosowal blackholingu wobec atakowanego IP. Zarowno SoftLayer (przy ataku >20mbps) jak i LeaseWeb (przy ataku >35k pps) od razu null-routuja atakowane IP, a sa to serwerownie z o wiele lepszymi laczami niz Hetzner.

     

    Tak, wiem - wszystkie mądre książki od security mówią, że na tego typu ataki nie ma sposobu... Tak jak napisałem - nie chodzi o całkowite zapobieganie takim atakom. Chodzi o minimalizację ich skutków. Jeżeli nie stać firmy na Junipery, niech postawi kompa z FreeBSD. Nawet najsłabsze zabepieczenie jest lepsze niż brak jakichkolwiek zabezpieczeń...

  24. Napisano · Raportuj odpowiedź

    Ludzie kochani... litości... ta, można kupić dobry router, stawiać honeypoty, loadbalancery i inne cuda przemysłu IT,

    ale... co taki klient budżetowej serwerowni ma zrobić? no nic...

    to co sobie ustawi via iptables/pf to ma... reszta należy już tylko do opatrzności

    z tego co pamiętam to przykładowo w Netdirekt to odrazu odcinają IP i taka pomoc ze strony ich działu NOC

     

    Ok, tylko z postów wynikało, że globalnie się nie da. W przypadku budżetowej serwerowni - "no się nie da", ale nie oznacza to, że w innych przypadkach nie można...

  25. Napisano · Raportuj odpowiedź

    Jasne...

     

    Jasne - ma rację. Czasy kiedy się nie dało dawno minęły... A przynamniej można minimalizować skutki takiego ataku... Do DoS'a czy DDoS'a można zaliczyć zarówno flood jak i atak typu SYN, RST, czy fragmentami pakietów. Z tego co pisali inni użytkownicy, flooda można wykluczyć, bo pingi były w miarę OK. Skoro flooda można wykluczyć (czy to na ilość pakietów, czy pasmo), to pozostaje cała reszta. Zaznaczam tutaj, że przed DoSem lub DDoSem typu flood nie ma możliwości obrony, dopóki nie współpracujemy z operatorem sieci.

    W przypadku pozostałych ataków, które nie wysycają w 100% pasma można wykorzystać sprzęt np. Junipera, który ma SYN proxy, analizuje błędne pakiety i odrzuca je na styku Internet<>Nasz sieć. Ba, nawet OpenBSD i jego PF ma Syn Proxy i normalizację pakietów. Od tygodnia wiem, że FreeBSD też (btw p, podoba mi się :lol: )

    Jeżeli chodzi o atak, który symuluje setki tysięcy klientów faktycznie i poprawnie pobierających stronę z naszego serwera, to można na przykład wykorzystać moduł do Apache, który robi hash listę i dla połączeń, gdzie ilość req/sec przekracza 100/sec, zawsze odeśle 404. W przypadku kiedy jeden klient wykona tylko jedno pobranie strony, ta metoda jest jednak mało skuteczna...

    Chociaż i tutaj jest pewien sposób - load balancer z obsługą Vhostów na którym kierujemy ruch na osobną maszynkę z odpalonym HoneyPotem czy lewym serwerem WWW. Taki load balancer poradzi sobie z 10k czy 50k połączeń, a usługi pozostałych klientów będą działały poprawnie...

    Oczywiście zawsze są wyjątki od reguły (np. ja ostatnio taki miałem). Nie oznacza to jednak, że mamy siedzieć z założonymi rękami i czekać, aż nam zwnou dowalą.

    Żeby nie było - kilka lat temu dzięki atakowi na moje serwery wyleciała większość sieci POL34. Wszystkie routery pogubiły sesje BGP, a ruch wchodzący do polski wynosił około 27Gb/sec ;) Dzięki tym rozwalonym sesjom, lokalni użytkownicy mieli dostęp do serwera :P To też jest sposób...

×