Téma: Javaslatok a tárhely szolgáltatóknak...

Tomessz eredeti hozzászólása

Ne írják le a következő mondatot: Korlátlan adatforgalom - ameddig a többi felhasználót nem zavarja.
Inkább írják le, hogy mennyi forgalom lehet havonta Gb-ban.

A korlátlan adatforgalom olyan igéret, mint a házassági fogadalom. Az is egy életre szól, de csak addig működik ténylegesen, ameddig a másik felhasználót (házastársat) nem zavarja.

Sajnos a GB forgalmat nem lehet előre megmondani. Mert nem mindegy, hogy pl. 100MB-os TIFF-eket töltenek le, vagy 10KB-os cuccokat, de 10000 darabot, és sokan. Utóbbi esetben bármelyik HDD megfekszik a random IO művelettől, és felmegy a load, ami miatt a másik honlapok is lassabbak lesznek. Viacomkft korábbi postjában kifejtette bőségesen az ok okozati tényezőt, de egy 10e napi oldalletöltésű átlagos oldalig szerintem 1 szolgáltatónak sem szabadna reklamálnia, de ahogy a fórumot olvasom, sok konkurencia ezt megteszi.

Van mod apache alá, ami korlátozza a GB-ot vagy akár más paraméterek alapján, de szerintem nem az a megoldás, hogy Ügyfeleket korlátozunk...

gzoli eredeti hozzászólása

És hogy definiálod mi a lassú query? Mert ugye bállíthatod sec pontosságra, hogy mi kerüljön oda, esetleg bekapcsolsz még pár pöcköt, és akkor a logba kerülnek azok a select-ek is, amik nem kulcs alapján kapcsolódnak, és még sokmindent lehet. De amit így kiszed, az teljesen hasztalan is lehet, mert pl. mi van ha tábla szintű lockot nyom valami, próbál pár egyszerű update futni, de nem megy neki, várja a lockot, csak nehogy dead lock legyen a végén. A lassú futás fog bekerülni, de lehet, hogy egyáltalán nem az a hibás. A környezetről meg ne is beszéljünk... ha épp túlterhelt gipsz jakab pc hosting rendszere, akkor a hdd io képessége erősen túlterhelt, és sokkal lassabban tudja végrehajtani az update-eket, sokkal több minden kerül a slow query-be.
Az sem mindegy, hogy mysql hogy van beállítva... néhány konkurenciánál láttam, hogy pár GB memóriával rendelkeznek a szervereik, amik hát őszintén harmat gyenge, mivel MySQL is szereti a select-ek eredményeit cache-ből kiszolgálni, na de ahhoz jó beállítás kell.
Így egy nagyon sok változós rész leszűkítése csak slow query-re nem túl biztos, hogy a hiba forrását találod meg vele.

Szia, mivel alapvetően a slow query beállítást nem átlag fehasználóként teheted meg ezért értelem szerűen ez inkább az operátor/rendszergazda számára jelenthet segítséget. Nem állítottam, hogy önmagában ez megoldás, de annak ismeretében, hogy a szerver milyen állapotban van, a rendszergazda már tud gondolkozni azon, hogy hol lehet a hiba. Logikus, hogy ha belépsz a szerverre és a load az egekben van, akkor elkezdesz gondolkozni azon, hogy elsősorban nagyon kevés a memóriád vagy lassú a háttértárolód. (egy megjegyzés, néha a túl nagy mysql cache inkább ront a helyzeten, mint javítana, főként akkor, ha az ember a teljes memóriát adja neki és nem marad a linux disk cache számára, esetekben a cache csökkentése jótékony hatással lehet a rendszer átlag teljesítményére).

Ha valaki egy viszonylag nagy teljesítményű mysql szervert szeretne, érdemes nagyon sok memóriát belepakolnia, 8 akár 16GByte-ot is, evvel kompenzálni tudja azt, hogy a háttértároló rendszere nem egy brutális gyorsaságú valami, amire egy sqlnek szüksége van. Súlyosbítja a helyzetet az, hogy attól, hogy RAID-be teszik a winchestereket sokan megnyugszanak, mondván biztosan gyorsabb lesz meg minden, a RAID nem gyorsításra van kitalálva, az egy kompromisszum! Ahogy írtad valóban sok szolgáltató igen kevés memóriával látja el a mysql szervereket, de a legrosszabb, hogy mindezen a szerveren fut még a levelezés és a web is!

A slow query log végeredményben a memória állapotának valamint a hardware állapotának ismeretében tud sokat segíteni üzemeltetés közben, természetesen nem ad válasz az esetlegesen zárolt táblákra, de mindenféleképpen megmondja a napi több millió lekérdezésedből, hogy merre keresgélj!

gzoli eredeti hozzászólása

Sajnos a GB forgalmat nem lehet előre megmondani. Mert nem mindegy, hogy pl. 100MB-os TIFF-eket töltenek le, vagy 10KB-os cuccokat, de 10000 darabot, és sokan. Utóbbi esetben bármelyik HDD megfekszik a random IO művelettől, és felmegy a load, ami miatt a másik honlapok is lassabbak lesznek. Viacomkft korábbi postjában kifejtette bőségesen az ok okozati tényezőt, de egy 10e napi oldalletöltésű átlagos oldalig szerintem 1 szolgáltatónak sem szabadna reklamálnia, de ahogy a fórumot olvasom, sok konkurencia ezt megteszi.

Van mod apache alá, ami korlátozza a GB-ot vagy akár más paraméterek alapján, de szerintem nem az a megoldás, hogy Ügyfeleket korlátozunk...

Szia Zoli,

természetesen kihagytam rengeteg okot, ha gondolod folytathatom is, de lehet nem mindenkit érdekel ebben a témában, csak viszonylagos képet szerettem volna mutatni, hogy egy bizonyos ok gyakorlatilag lavinát indíthat el evvel okozva drasztikus lassulást, esetleg szerveromlást. A direkt adatkorláttal én sem értek egyet, mert ha egy szervert szeretnél ellehetetleníteni, akkor ne statikus file-okkal probálozz, hanem kezdj el kényelmes 20-40-80 szálon php oldalakat lekérni (az apache benchmark erre tökéletesen megfelel), a php segítségével igen hamar eléred, hogy az, amiből elég gyakran kevés van az fog elfogyni, azaz a memória. A memóriahiánytól a rendszer azonnal fuldoklani kezd és a swap-hez fordul, ami természetesen joval lassabb lesz, mint a memória, így a terhelésed simán pár perc alatt felfuthat akár a csillagos égig, mivel a CPUd érdemleges munka helyett a disk i/o-val fog babrálni. Apropó ha a swap-et kikapcsolod, akkor pedig memória fogyás esetén a linux elkezd elég érdekesen viselkedni, ami jelen pillanatban a memóriakezelő hibája, bővebb infó a kernel buglistákon.

Tapasztalta-e valaki, hogy a 2.6.2x.x kernelek a teljes memória lefoglalása után egyszerűen csak elfagynak? Jelenleg ezt minden 64bit-es rendszeren sikerült reprodukálnunk.

gzoli eredeti hozzászólása

Sajnos a GB forgalmat nem lehet előre megmondani. Mert nem mindegy, hogy pl. 100MB-os TIFF-eket töltenek le, vagy 10KB-os cuccokat, de 10000 darabot, és sokan. Utóbbi esetben bármelyik HDD megfekszik a random IO művelettől, és felmegy a load, ami miatt a másik honlapok is lassabbak lesznek. Viacomkft korábbi postjában kifejtette bőségesen az ok okozati tényezőt, de egy 10e napi oldalletöltésű átlagos oldalig szerintem 1 szolgáltatónak sem szabadna reklamálnia, de ahogy a fórumot olvasom, sok konkurencia ezt megteszi.

Van mod apache alá, ami korlátozza a GB-ot vagy akár más paraméterek alapján, de szerintem nem az a megoldás, hogy Ügyfeleket korlátozunk...

Az előző postomból épp csak a lényeg maradt le, azaz pár php kéréssel, ami alig okoz pár megabyte-o forgalmat, jóval nagyobb terhelést okozhatsz pillanatok alatt, mint akár több gigabyte-os forgalommal.

Webhosztingnál sajnos mindenki arra licitál, hogy mekkora tárhelyet ad, pedig mindannyian tudjuk, hogy a tárhely szinte a legolcsóbb dolog a mai háttértároló kapacitások mellett. Sajnos senki sem fogalmazza meg, hogy mi alapján lehetne kordában tartani azt, ami tényleg határt szab a szerveren, azaz memória foglalást és a cpu időt. Tény, hogy ez a két adat jelen pillanatban konkrétan mérhetetlen, ezért egy weboldal látogatottsága alapján (adatforgalom) próbál mindenki következtetni erre, ami többnyire működik, de sokszor nem jól...

Végül megint oda jutunk, hogy ezeket az adatokat korlátozni nem lehet, vagy rugalmasan kell kezelni és más tényezők alapján kell eljárni de a piac nem ezt az irányt diktálja. A jelenlegi piac inkább az olcsóbb és kevésbé szabályozottabb szolgáltatások felé mutatják az irányt, ami persze idővel sem a szolgáltatónak sem az ügyfélnek nem lesz jó, de a marketing megint különbözik a technikai lehetőségektől.

scs eredeti hozzászólása

Én ugyan még az életben nem hostoltattam külföldinél, tehát nem is fogok belemenni összehasonlításba. Viszont azt leírhatom, hogy mi
Most úgy vagyok, hogy egy fórumtárs által nyújtott VPS-en zörög az aprós honlapom. És eszemben sincs elmenni innen. Korábban egy jóval olcsóbb helyen voltam, de - finoman fogalmazva - nem igazán jött be. Most meg láttam/hallottam jópár másik lehetőségről, melyek közül van olcsób is, de akkor is maradok. És ha lesz további honlapom, a fontosabbak akkor is ezen a helyen maradnak, mert talán többe kerül, de a megbízhatóság és a megfelelő ügyfélszolgálat, stb. mind megtérülnek.

A régi szolgáltatódnál én voltam az a szerencsés aki 3 alkalommal újratelípítette a szerveredet hajnali 2 óra körűl, és még számos esetben visszaállította webszervered konfigurációs állományát. Igen, nem elírás 24/7 ben dolgozunk. Szóval azért nem értem az elégedetlenségedet, mert amikor csak hazavágtátok a szervert mindannyiszor visszaraktam neked, beállítottam minde szervízt "azonnal". Persze 5 perccel később már valóban elégedetlenűl hívtál, mert eltartott vagy félóráig míg lement egy reinstall+backup. Aki ért egy kicsit is a technikához, az tudja hogy nem kis erőfeszítés több ezer ügyfél archivumából visszaállítani egyetlen usert. A kollégákkal napi szinten ugarttuk egymást veled, és fogadásokat köttötünk hogy mikor konfigoljátok el ismét a VPS-t. A sokadikdik eset után, már kínomban templatet készítettem a nevdre dedikálva, hogy expressz sebességgel tudjam visszaállítani az adataidat. Megértem Én hogy nem értesz a Linux-hoz, és nem is olvstad el az amúgy szájbarágos dokumentációt sem, ezért voltam próbáltam türelmes lenni veled, és segíteni amiben tudtam. Az hogy ennek ellenére mégsem tudtatok elboldogulni úgy gondolom a te hibád, hiszen több mint 16000 felhasználó használja probléma nélkül a rendszerünket, még multinacionális cégek is sokkal nagyobb forgalmú portálokkal mint ami neked van. És mégsem ismerem minden rendszergazdát névszerint, mert csak keveseknél fordúl elő hogy főműsoridőben elindít egy backupot ami ugye több órát is eltarthat, azután észreveszi hogy közben a szerver leállt és nem mennek a weboldali, ezért nyom egy restartot is szervernek. Természetesen így a backup állomány corrupttá vállik amiből még a legjobb indulattal sem lehet visszaállítani semmit. Én azt gondolom a te esetedben egyértelműen az volt a gond hogy nem sikerűlt minimális szinten megismerni a kezelő felületet, és a gyári kontroll panellelt sem. Annyira nem lehet rossz a rendszerünk, ha még most is > 10 domain nevet tartasz rajta. Egyetlen hibája hogy a felhasználó baklövéseit nem ignorálja, de igaz az a mondás: a felhasználó legnagyobb ellensége maga a felhasználó.
Továbbiakban sok sikert kivánok a jövőben is az oldaladhoz.

Scs ügyfél levelére nem fogok válaszolni, mert kérdést valójában nem fogalmazott meg. Viszont egy-két észrevételt azért tudok tenni:
Sajnos mi nem tartozunk klasszikusan a kicsi cég kategóriába, nyilván valamiféle struktúrát kell tartani a cég működtetésre. Ha nincs telefonos ügyfélszolgálat akkor azt jelenti, hogy tényleg nincs. Ha azt írjuk ki hogy ügyfélszolgálat 9-17 között működik, akkor az autómata reggel 9 óra 0 perckor kapcsolja be a vonalakat, és 17 óra 0 perckor meg lekpcsolja azokat. A fentiek miatt scs-nek megadtam a saját magán mobil számomat is, hogy ha valami gondja van akkor hívjon akár akkor is ha nem dolgozom. Azt hiszem azt nem is vitatta hogy volt rá példa, hogy otthonról hajnali 2 órakkor intéztem a VPS felélesztését. Ennyit az ügyfelek felé mutatott lojalitáról

Nálunk ticketing rendszer működik, amikor beküldesz egy levelet azonnal nyit egy ticketet. Az nem történik meg hogy nincs megoldva, és megválaszolva egy levél, mert akkor itt villogna a képernyőm közepén egy nagy piros figyelmeztetés. Lehet hogy a sw hibás, és pont a te leveled vesztette el, de ez is külső gyártó hibája.

Annyit még hozzá tennék, hogy akkor amikor nálunk volt a weboldal az még erősen fejlesztési/tesztelési státuszban volt. Nyomonkövetve az archivumokat naponta változott a "privát területed".

Nálunk egy 256MByte memóriával szállított VPS-t használtatok. A VPS-hez nincs swap, amit el is mondunk minden alkalommal és az internetten is százmillió fórumon leírják hogy a VZ OS szintű virtualizációt csinál, és tényleg nincs swap. A webszervert (Apache-ot használtok) és az SQL-t rendesen be kell konfigolni, a lekérdezéseket optimalizálni mert hamar kifutottok a memóriából. Ki is futott minen alkalommal.

Mindíg azt mondjuk, hogy mi nem adunk supportot ingyen! Aki azt igényli hogy fogjuk a kezét, és javítgassuk a ki a config fájlokat az fizesse meg a mérnoki óradíjat. Ez mindenkinek fel van ajánlva, csak hát ugye az nem ingyen van. Mi alapvetően szerver időt és erőforrást adunk bérbe a "számítási felhőből", és nem az ügyfél weboldalát üzemeltetjük. Minden egyes weboldalunkon nagybetűkkel ki van írva, hogy support nincs. A szolgáltatás körülményeit az ÁSzF szabályozza, és külső hiteles szolgáltatón keresztűl mérjük a szolgáltatás minőségét (Medián). Amennyiben nem megfelelő a szolgáltatás, azonnal visszafizetjük a szolgáltatás árát is akár, amire volt már példa. Annak ellenére hogy technikai támogatás plusz pénzért adunk, az emailben feltett kérdésekre igyekszünk válaszolni. Ha hiba van, akkor nyilván előbb megoldjuk a hibát, azután foglalkozunk a telefonálással. Ha az ügyfélnek egyéni igénye/kérése van akkor sorbanáll.

Nézd vannak ideheza is 1 fős szolgáltatók, és vannak olyanok ahol többen is dolgoznak. Mindegyiknek megvan a maga hátránya/előnye. A kicsi szolgáltatók drágábak, bevállanak olyan dolgokat is amiket normál körülmények között nem biztos hogy megtesznek. Egy nagyobb cégnél vannak tartalék eszközök, a rendszergazdát nem az ágyból kell előrángatni viszmajor esetén...


Az ügyfelekre nézve 2 féle ügyfél van:
Az egyik csoport nem keresi a kapcsolatot a szolgáltatóval lépten nyomon, ezek vannak többségben.
A másik csoport ennek az inverze, ha nem látja meg a kedvenc weboldalát reggel ébredés után, akkor azonnal emeli fel a telefont, és árad belőle a panaszáradat. Gyakran van rá eset, hogy a problémája csak helyi jellegű, és saját ISP szolgáltatójára tartozik, nem pedig a tárhelyszolgáltatóra.

Jöttem megint tiszta vizet öntögetni.

Ügyfélszolgálat
Hajnal kettőkor nem hívtam senkit. Este 6 után (egy-két alkalommal 8-kor is) igen. Meg reggel is próbálkoztam.
Ha az embernek elszáll a honlapja, vagy nem tud belépni a Plesk felületre, meg SSH-val sem tud kapcsolatot létesíteni vele, hogy egyáltalán megnézze mi lehet a gond, akkor azért próbál telefonálni. Szerintem...

sipi eredeti hozzászólása

Nyomonkövetve az archivumokat naponta változott a "privát területed".

Volt olyan is. Meg volt olyan is, hogy nem.
De most jön a lényeg!

sipi eredeti hozzászólása

Nálunk egy 256MByte memóriával szállított VPS-t használtatok. A VPS-hez nincs swap, amit el is mondunk minden alkalommal és az internetten is százmillió fórumon leírják hogy a VZ OS szintű virtualizációt csinál, és tényleg nincs swap. A webszervert (Apache-ot használtok) és az SQL-t rendesen be kell konfigolni, a lekérdezéseket optimalizálni mert hamar kifutottok a memóriából. Ki is futott minen alkalommal.

Akkor mégis miért fizettem 4250 Ft + ÁFÁ-t???
A 256 mega RAM-os VPS 1250 + ÁFA lett volna.
Én viszont a legnagyobb VPS csomagra kötöttem szerződést, amihez 1 giga RAM, 3000 Mhz procisebesség és 25 giga tárhely járt volna.
Miért csak 256 mega RAM-ot kaptam mégis?
(Esetleg felrakjam a szerződésemet vagy a számlát a fórumra, ha előtalálom? Abban benne van, hogy mi volt alatta. Na meg azért emlékeimben még mindig megvan, hogy a tárhely a legnagyobb volt a Plesk szerint is. Szépen írta, hogy 1 giga RAM van, stb.)

Szerintem nem is érdemes innentől tovább nyaggatni a dolgot, ez elég sokat elárult... Javaslom itt fejezzük be.