Javaslatok a tárhely szolgáltatóknak...

[viacomkft]

ARTidas eredeti hozzászólása

Nos, én példának felhoznám a tegnapi esetemet.

Éppen egy rendezvény beléptetését végeztem (Kb. 110 ügyfél).
A honlap becsődölt (mysql error először, aztán már 500 as server hiba, 505 server hiba, és még miatyánk kínnya és magyarok nyilai jött még rá).

...

De a kedvencem, az előre megírt üzenetek Minek elolvasni, ha van egy sablon minden helyzetre?

Egy kis csemege:

Én: A ---- a szokott módon meghalt.
Kérném feltámasztását.
Tudom :
\"Dolgoznak rajta az illetékesek\".

...

SUMMÁZVA: Ne kezdjünk el kertelni ha feltesznek egy kérdést. Ha kigyulladt a serverterem, akkor mondják azt. Ha valaki elrontott valamit és egyebek JOGA VAN az ügyfélnek tudnia róla. Máig nem kaptam olyan választ, hogy mitől vannak ezek a sorozatos leállások és meghibásodások, de már napjában többször pár percesek ezek.

...

Mindezek mellett kiírják, hogy garantált a 99% rendelkezésre állás. Felmegyek a serverük hivatalos figyelőjére és kiírja, hogy 89%... persze, semmi pénz visszafizetés. Minek teljesíteni azt, amit ígérnek, ha már a pénzed úgy is náluk van? A tornaóra nehéz lehetett egyes embereknek gerinc nélkül.

Respect, Cheers,

Szia,

Igazán kíváncsi lennék egyébként arra, hogy ilyenkor a többi szerverlakó számára mit mondanak! Gyanítom, hogy a hibát nem Te követted el, hanem valamelyik másik oldal lefárasztotta a szervert, esetleg DoS támadás áldozata lett?

Sajnos azok a válaszok, amit fent említettél nagyon gyakoriak, nem biztos, hogy azért nem kapsz választ, mert nem merik elmondani, hanem inkább azért, mert halovány sejtésük sincs róla, hogy mi okozza a hibát! Nem akarom hibáztatni Őket, mert néha mi is találkozunk olyan jelenségekkel, amiknek a papírforma és elmélet alapján sosem szabadna megtörténnie, de mégis megtörténik. Sokszor van olyan, hogy egyes programok a nagy terhelés alatt hibákat vétenek. Aki nyílt forrású rendszereket használ fel kell készülnie arra, hogy amit ingyen kapott az nem tökéletes és néha neki kell hibát keresnie esetleg kijavítania! Kérdés az, hogy tud-e kezdeni valamit vele, ugyanis egy admin felületes szolgáltatást manapság már bárki el tud indítani és tudja is üzemeltetni, minden programozói sőt esetleg nagyon csekély linux ismerettel is!

Az is biztos, hogy sok cégnél ügyfélszolgálat gyanánt olyanok ülnek ott, akik inkább csak nyugtatni próbálják az ügyfelek haragját,de egyértelműen nem tudnak segítséget nyújtani. A rendszer üzemeltetőit pedig érthető módon kár ilyenkor hívogatni, mert ha az ügyfelekkel kell törődniük a hibajavítás helyett igen nehéz a problémára koncentrálni és a gyors javításból nem lesz semmi.

Ezekre a problémákra szerintem tökéletes megoldás lenne egy olyan üzenőfal, ami minden szerverhibától függetlenül tud üzemelni, így az ügyfelek is láthatják a hibaelhárítási folyamatot és az üzemeltetők is tudnak a feladatra koncentrálni. Esetleg twitter? Szerintetek ez nyújthat megoldást?

Végezetül pedig a programozó válasz szeretne dologra egy vicc jutott eszembe; mit mond a villanyszerelő az alkatrészboltban? "nekem biztosíték kell nem ígéret!"

P.Ü.-ben meg tudnád írni, ha nem titok hogy ki volt ez a szolgáltató?

[viacomkft]

Geri eredeti hozzászólása

kicsit off, de van itt sok server guru. ismer valaki mysql query analyzer free alternativát?

Szia Geri,

Ha egy szerveren egy-egy renitens hosszan futó lekérdezést szeretnél kicsippenteni, akkor elég lehet a slow query log! A jó benne az, hogy csak be kell kapcsolni

[scs]

viacomkft eredeti hozzászólása

Ezekre a problémákra szerintem tökéletes megoldás lenne egy olyan üzenőfal, ami minden szerverhibától függetlenül tud üzemelni, így az ügyfelek is láthatják a hibaelhárítási folyamatot és az üzemeltetők is tudnak a feladatra koncentrálni. Esetleg twitter? Szerintetek ez nyújthat megoldást?

Szerintem a twitter azért még annyira nem elterjedt, hogy ez megfeleljen. Viszont egy saját honlapon lévő felület (Ügyfélfiók jellegű valami), ahol a jóember belépést követően be tudja írni a nyűgjét-baját, meg ott megkapja esetleg a választ is, +esetleg egy felületen látja, hogy most épp "mindentuti" vagy "na-ezt-is-tönkrevágtuk", esetleg "hibaelhárítás-alatt" van kiírva, az talán nem lenne rossz. Bár majd a hozzáértőbbek megmondják. Nekem ilyen gondom még soha nem volt hála az égnek.

[Geri]

viacomkft eredeti hozzászólása

Szia Geri,

Ha egy szerveren egy-egy renitens hosszan futó lekérdezést szeretnél kicsippenteni, akkor elég lehet a slow query log! A jó benne az, hogy csak be kell kapcsolni

nem erre lenne szükségem, hanem a lekérdezéseket elemezni finomhangolás miatt. a query analyzerről eddig sok jót hallottam, de fizetős(bár az árát nem néztem), és annyira nincs rá szükségem hogy megvegyem.

[Tomessz]

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.

[viacomkft]

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.

Teljes mértékben igaz! Ugyanakkor van pár olyan dolog, amit ez közvetve befolyásol, például CPU terhelés, amit elképzelni sem tudok, hogy hogy lehetne mérni... Minden ügyfélnek joga van 10billió utasításig igénybe venni a processzort vagy hogy?

Adatforgalmi korlátok eddig sem voltak, nem tudom, hogy most miért találták ki, hogy bevezetik, hogy utána nagy önfényezés keretében korlátlanná tegyék. Így lehet eladni a levegőt is! Az viszont mindenki érdeke, hogy ne túlterhelt szervereken legyen a weblapja, amihez pedig valami féle korlátozást ki kell találni!

Javaslat?

[ARTidas]

Sajnos megint lemaradtam egy kicsit a mai nap, de válaszolva a kérdésekre és felmerült gondokra:

A beléptető rendszer már stabilan üzemelt fél éve. SOHA SEM használok CMS -t és egyéb motort. Mindet magam írom és fejlesztem. Csakis ezekben bízom és ismerem teljesen.

A hiba csakis a servernek köszönhető. Egyszerűen leállt és többszöri újra indírást igényelt.

A telefonközpontjukban dolgozóktól nem is várom el (naív lennék ha igen ) hogy egyáltalán azt tudja mi az a router és switch. De ha már van egy gond, valaki igazán mondhatna egy olyat nekik, hogy pl: kiment a biztosíték. DOS támadás, hack, egyéb. Egy mondat elejéig kellene csak, mert ha állandóan jön az, hogy biztosíték, akkor küldök nekik egy pár amperrel nagyobbat , de mivel még vasfogóval sem lehet kihúzni és hét pecsétes és 666lakatos egy ilyen leállás oka, én nekem ez VALAMIÉRT nem megnyugtató.

És eszembe jutott, egy kellemes 3-4 hónappal ezelőtti eset ...

Megyek fel myadminba, nézném át a cookie azonosítók tároló tábláját, hogy éppen a felhasználók miket tekintgetek meg és milyen URL ekkel is próbálkoznak, erre kiírja, hogy (sajnos a pontosat már nem tudom): A kiválasztott tábla sérült, kéjük forduljon a weblap üzemeltetőjéhez. Forduljak magamhoz? Jó gondolat, felhívom őket, mifeneegyemegmármegintmiértkellettkihúzniaserverta kvlefőzéséhez?...
Sikerült DB visszaállításkor (hogy minek állították helyre egyszer az adatbázisát a tárhelynek, nem tudom) sikerült megint lekapcsolniuk az egészet. És kiderült, hogy bezony a DB végén lévő tábláim mind megsemmisültek az éterben. DE SEBAJ!!! Mert az ÁSZF -ben naponta történő adatmentést ÍGÉRTEK!!! Akkor már kérném is, erre megkapom a választ, hogy sajnos a backupért felelős gép is hibás már 3 napja...

Többet tényleg nem kívánok írni a már lassan egy éve tartó rémálomról, mert kegyetlen miket kell elszenvednem miattuk és a főnököm nem akar cserélni, mivel hamarosan saját üzemű serverekre térünk át, addig még lesznek itt halottak a csatamezőn.

Ilyet sem kéne igazándiból tenni az ügyfelekkel

Cheers,

[gzoli]

viacomkft eredeti hozzászólása

Szia Geri,

Ha egy szerveren egy-egy renitens hosszan futó lekérdezést szeretnél kicsippenteni, akkor elég lehet a slow query log! A jó benne az, hogy csak be kell kapcsolni

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

[gzoli]

ARTidas eredeti hozzászólása

És eszembe jutott, egy kellemes 3-4 hónappal ezelőtti eset ...

Megyek fel myadminba, nézném át a cookie azonosítók tároló tábláját, hogy éppen a felhasználók miket tekintgetek meg és milyen URL ekkel is próbálkoznak, erre kiírja, hogy (sajnos a pontosat már nem tudom): A kiválasztott tábla sérült, kéjük forduljon a weblap üzemeltetőjéhez. Forduljak magamhoz? Jó gondolat, felhívom őket, mifeneegyemegmármegintmiértkellettkihúzniaserverta kvlefőzéséhez?...
Sikerült DB visszaállításkor (hogy minek állították helyre egyszer az adatbázisát a tárhelynek, nem tudom) sikerült megint lekapcsolniuk az egészet. És kiderült, hogy bezony a DB végén lévő tábláim mind megsemmisültek az éterben. DE SEBAJ!!! Mert az ÁSZF -ben naponta történő adatmentést ÍGÉRTEK!!! Akkor már kérném is, erre megkapom a választ, hogy sajnos a backupért felelős gép is hibás már 3 napja...
Cheers,

Ez akkor fordulhat elő, ha queryk futnak táblátokon, és valamiért elszáll adatbázis alatta. Ilyen okok lehetnek szerver elhal alatta hw hiba miatt, elfogy a hely, stb. Ezeket a hibákat lehet pl. MyISAM alapú tábláknál a myisamchk-el javítani, de ilyenkor biztosítani kell, hogy az adott táblához nem férnek hozzá. Általában csak a kulcsok karbantartásakor sérülhet meg ilyenkor, ezeket meg újragenerálja -r opcióval... de ha ilyen történik, akkor Ügyfélnek észre sem kellene vennie, mert a tisztelt Kollégáknak a szerver indításakor jelzi MySQL, hogy valami nincs rendben. De még pár megoldást google kidob ha rákeresel.

[ARTidas]

A nem hozzáférhetőséggel nincs gond, mert lényegében soha sem tudom használni, mikor kéne Murphi törvény. Igazából az idegesít, hogy nem tudom meddig lesz még ilyen kaotikus állapot és mitől van mindez...

Cheers,