T

Daj trochę więcej pamięci na cache dla mysql i (jeśli nie masz raidu) przenieś bazy na drugi dysk. Z tego co wkleiłeś wynika, że jedyne co się być może zaczyna przestawać wyrabiać to dyski. Ogólnie nawet teraz nie wygląda to źle, po czym wnosisz, ze serwer jest przeciążony?

Podeślij też wynik `free -m`.

Pana skrypty zachowywały się dość dziwnie. Zasadniczo nie generowały istotnego obciążenia (najczęściej były wręcz niezauważalne) pomijając 3 opisane sytuacje kiedy próbowały wręcz zarżnąć serwer. Nie było to także obciążenie baz danych tylko wygenerowane przez same skrypty. Dlatego wnioskuje, że powstał jakiś błąd podczas ich instalacji. Nigdy nie blokujemy kont ani ich części jeśli nie utrudniają one pracy innym użytkownikom. Gdyby wygenerował Pan np. średnie obciążenie nawet 20% ale o spokojnym rozkładzie, nie przeciążając serwera, to skontaktowalibyśmy się po prostu e-mailem i pomogli poprawić skrypty lub zaproponowali inne rozwiązanie gdyby poprawić się ich nie udało i konto napewno nie byłoby blokowane. Robimy to tylko, gdy nie ma innego wyjścia. Natomiast sytuacje z błędami podczas instalacji i konsekwencjami jak u Pana czasami się zdarzają -- jeden z naszych klientów zainstalował np. własną aplikację z niewłaściwie napisaną obsługą błędów i ustawił `chmod 777` dla jednego z katalogów, co w naszym systemie (skrypty uruchamiane z prawami użytkownika) spowodowało generowanie błędów i niewłaściwą ich obsługę przez aplikacje klienta, a w konsekwencji bardzo duze obciążenie serwera. Udało się to poprawić w minutę.

Często skrypt nawet nie przeciąża baz danych, tylko sam w sobie jest tak beznadziejnie napisany, że obciąża serwer. To się tyczy w szczególności Joomli.

Na bazy danych nie ma absolutnie żadnego sensu brać dual core przy dyskach sata i takiej ilości pamięci. Oczywiście ten pierwszy. Mam pewne podejrzenia, że problem może leżeć gdzie indziej. Jeśli możesz to pokaż wynik `top -bn 10 | grep -i "cpu"` w szczycie.

Jeśli ilość odwiedzin była mała, to być może popełnił Pan jakiś błąd instalując skrypty. Faktem jest, że pierwszy z nich wygenerował w pewnym momencie na dłuższy czas load 60.0 (!) na mało obciążonej maszynie, a drugi około 20.0. Od godziny 18:40 przez pół godziny jeden z Pana skryptów bez przerwy wykorzystywał całą wolną moc procesora (około 60% -- były to godziny szczytu). Niestety nie odpowiedział Pan na maila z informacją o skrypcie przeciążającym serwer (a moze odpowiedź do nas nie dotarła?). Zawsze staramy się pomóc rozwiązać tego typu problemy i najczęściej się to udaje. Ogólnie takich problemów z serwerami wirtualnymi jest bardzo mało, w lipcu były dwa lub trzy i bodaj tylko opisany powyżej nie został z sukcesem rozwiązany.

Joomla to moim zdaniem najgorszy CMS. Zdecydowanie wolę fora by Przemo.

U nas w cenie 25 zł + VAT za 3 miesiące może Pan otrzymać serwer z 2 GB przestrzeni dyskowej, 33 GB transferu miesięcznego i bez innych limitów. Jest oczywiście m.in. dostęp do shella i crontaba. Szczegółowa oferta.

Zdziwiłbyś się. ;-)

A dlaczego miałby tego nie robić? Po to wymyślono /etc/shadow wiele lat temu, żeby /etc/passwd mogło być dostępne. Oferujemy dostęp do shella (dla niektórych kont pełny, z możliwością kompilacji własnego oprogramowania itd.) więc w zasadzie niemożliwe (a w każdym razie bezsensowne) byłoby ograniczenie dostępu dla klientów do ich katalogu domowego. Możliwość odczytania /etc/passwd czy wylistowania katalogów domowych użytkowników nie jest żadną luką w bezpieczeństwie. To już ich problem. Zabezpieczeniem konta jest hasło, nie login. Loginy z definicji są jawne. Oceniając bezpieczeństwo warto wiedzieć, na co patrzeć. Z ciekawszych (raczej rzadko spotykanych rzeczy) rzeczy mamy np.: - Katalog na strony jest podlinkowany do domowego z zupełnie innego miejsca, dzięki czemu do samego katalogu domowego nie ma praw dostępu nawet apache - Prawa dostępu do wielu rzeczy są ustawione za pomocą aclek - Wszystkie skrypty użytkowników są uruchamiane z prawami danego użytkownika, a nie serwera httpd To są właśnie jedne z rzeczy, które mają istotny, a przede wszystkim rzeczywisty wpływ na bezpieczeństwo.

W każdym razie nie mogłoby tam być nic wykorzystujacego mocno bazy danych.

Nie bądź taki mądry, dalej sprecyzował, że to nie download.

Zapraszam do przetestowania naszych serwerów wirtualnych Home (opcja płatności SMS-em) lub do skorzystania z aktualnej promocji na serwer Biznes Promo za jedyne 59 zł + VAT rocznie (szczegóły w sygnaturce). Najpierw pytałeś o coś z 4 GB transferu miesięcznie, a teraz zastanawiasz się na pakietem z 90 GB. To czego właściwie potrzebujesz? :-)

Nie.

Ja do OVH miałem ponizej 40 ms (TPNET). Zresztą różnica na poziomie 20 ms w takim zastosowaniu jest bez znaczenia.

Zrozumiałem, tyle że nie ma związku z tematem. Dla mnie EOT.

Jakieś bardziej realne testy, a nie tylko proste zmierzenie transferu. Powinny brać pod uwagę rzeczywistą wydajność dysków przy odczycie (wyszukiwaniu) i zapisie małych porcji danych, tak jak to się dzieje w hostingu. Mam np. dyski ATA 7,2K (PATA, nawet nie SATA) które w `hdparm -t` osiągają 64 MB/s, ale to wcale nie oznacza, ze są porównywalne z SCSI 10K w zastosowaniu hostingowym. Dodam, że ten podsystem dyskowy wypada mi lepiej w testach niż SATA na serwerach dedykowanych. Z tym się zgadzam, dlatego używam dysków SATA. Nie sądze, żeby system zlokalizowany na jednym dysku SCSI był bardziej wydajny niż rozrzucony po kilku dyskach SATA. Lub inaczej -- jeśli w cenie jednego dedykowanego Dual Xeona/2xSCSI mogę mieć cztery Dual Core/2xSATA to wybór też jest raczej oczywisty.

Nie pij tyle. Stwierdziłem, że na podstawie fałszywych danych nie da się wyciągnać poprawnych wniosków co jest wręcz truizmem, a Ty mi wyjeżdżasz z sumami kontrolnymi. Litości. Jak wyżej -- nie pij tyle. Napisałem, że moje serwery wypadły dobrze, żeby nikt nie pomyślał, że krytykuje test tylko dlatego, że wypadły źle. Wydawało mi się to oczywiste. Powyższe testy nie mówią niestety wiele o rzeczywistej wydajności. A co do Raptorów to maja one zbliżoną cenę do dysków SCSI.

Tam nic "nie lata", hdparm pokazuje transfer na poziomie 60-70 MB/s, co jak wiadomo jest dla dysków ATA krańcem możliwości, ergo -- są prawie nieobciążone. To bodaj najlepsze dyski ATA (PATA) jakie powstały. Te 80 GB to natomiast stare Barracudy 7 (mam je w firmowym serwerku, który obsługuje stronę i pocztę firmową). I sam widzisz ile warte są takie testy...

Ja hostowałem ich tam wiele i nie zauważyłem żadnych problemów. Co było nie tak?

Wyjdzie drożej, a pingi nie mają żadnego znaczenia w takim zastosowaniu. Litości...

Sensowny test składałby się z dwóch cześci: testowej strony wykorzystującej typowe funkcje (php, mysql itp.) którą umieszczałoby się na badanym serwerze oraz skryptu pobierajacego stronę i mierzacego czas pobrania, który należałoby uruchomić na (wielu) innych maszynkach i uśrednić wynik. Tak w ogóle, to niezłym testem ogólnej wydajności systemu (jako takiego -- nie systemu hostingowego) jest czas kompilacji np. kernela.

Niestety obawiam się, że to kolejny bezsensowny test. Athlon XP 1800+ (1533 MHz), 1 GB RAM, 2x80 GB ATA 2 MB cache wypadł mi w nim lepiej niż Dual Xeon 1.8 HT, 2 GB RAM, 2x250 GB ATA 16 MB cache, a w jednej z innych maszynek pokazał np. "File Copy 256 bufsize 500 maxblocks 1077.0 1.0 0.0".

A to ciekawe. W jaki sposób chcesz z błędnych danych wyciągać poprawne wnioski? Litości... Przecież się nie chwalę, zaznaczyłem tylko, ze pomimo dobrego wyniku uważam test za bezsensowny.

OVH. Może nawet najtańszy wystarczy? TS ma małe wymagania sprzętowe.