Hozzászólások
-
Bejegyzés
-
dotmind wrote:en azert hasznalnam a top-ot, mert latod az egyes folyamatok memoria, processzorhasznalatat, es a a gep i/o, es swap ehseget is egy kepernyon. raadasul nem kell semmit telepiteni kulon a vasra
Szerintem aki nem tudja mit keres és nem a legprofibb a webadmin terén, jobb ha lát mindent, tisztán, érthetően.
Code:19.1%us, 9.6%sy, 0.0%ni, 67.6%id, 1.0%wa, 0.5%hi, 2.2%si, 0.0%stA fenti sor nem mindenkinek beszédes. 🙂 Ellentétben ezzel:
http://pagesperso-orange.fr/sebastien.godard/tutorial.htmldotmind wrote:(emlekeim szerint a sar nincs benne pl az alap debianban)http://packages.debian.org/etch/sysstat
Mellesleg a Debian Woody (3.0) óta része az alap (main) disztribnek, bár Debian Slink (2.1) a contrib részben tárolja.
dotmind wrote:en azert hasznalnam a top-ot, mert latod az egyes folyamatok memoria, processzorhasznalatat, es a a gep i/o, es swap ehseget is egy kepernyon. raadasul nem kell semmit telepiteni kulon a vasraSzerintem aki nem tudja mit keres és nem a legprofibb a webadmin terén, jobb ha lát mindent, tisztán, érthetően.
Code:19.1%us, 9.6%sy, 0.0%ni, 67.6%id, 1.0%wa, 0.5%hi, 2.2%si, 0.0%stA fenti sor nem mindenkinek beszédes. 🙂 Ellentétben ezzel:
http://pagesperso-orange.fr/sebastien.godard/tutorial.htmldotmind wrote:(emlekeim szerint a sar nincs benne pl az alap debianban)http://packages.debian.org/etch/sysstat
Mellesleg a Debian Woody (3.0) óta része az alap (main) disztribnek, bár Debian Slink (2.1) a contrib részben tárolja.
A.) eset: a sar kimenetében megtalálja a válszt és nem ír többet.
B.) eset: rosszra gondol, megsértődik, és nem ír többet.
;D
A.) eset: a sar kimenetében megtalálja a válszt és nem ír többet.
B.) eset: rosszra gondol, megsértődik, és nem ír többet.
;D
u-player wrote:Mennyire általános ez, hogy egyszerre ennyi keresőrobot jöjjön mindig egy időben egy adott szerverre?Az egyenes logikát követed, ami jelen esetben nem vezet sehova. Nem azt kell megoldani, hogy miért jön 10 robot egyszerre, hanem hogy egyszerre 10 folytonos oldal beolvasás miért terheli le ennyire a gépet. Azonkívül lehet hogy csak látszólagos az egyidejűség, és valójában már 1 pásztázás is szörnyen lassú, a hosszú végigolvasás közben jön a többi ami tovább fogja a gépet.
u-player wrote:A tippeket azért köszi, természetesen keresem tovább a probléma forrását. Nem hinném, hogy egy adott PHP szkripttel lenne gond, mert a botok nem mindig ugyanazon az oldalon „landolnak”, amikor a szerverre érkeznek, mégis egy-két szóból felmegy a load…Mint itt mindenki más, én is csak jót torpedózom, mert a nagy terhelés alatt készült apache access log nélkül 100%-ban tiszta vaktában lövöldözés bárki bármit is ír. Akár mesterséges terhelésnél is tesztelhetsz (pl. „wget -m”), nem kell megvárni a keresőket. Az az egy biztos, hogy a válasz az apache és a PHP napló fájlokban van, a kérdés inkább az, hogyan tudod dalra fakasztani őket.
dotmind wrote:a top ot figyelgesd a problemas idoszakban.Szerintem az esetben csak a sar (vagy egyenértékű 🙂 ) jöhet szóba
u-player wrote:Mennyire általános ez, hogy egyszerre ennyi keresőrobot jöjjön mindig egy időben egy adott szerverre?Az egyenes logikát követed, ami jelen esetben nem vezet sehova. Nem azt kell megoldani, hogy miért jön 10 robot egyszerre, hanem hogy egyszerre 10 folytonos oldal beolvasás miért terheli le ennyire a gépet. Azonkívül lehet hogy csak látszólagos az egyidejűség, és valójában már 1 pásztázás is szörnyen lassú, a hosszú végigolvasás közben jön a többi ami tovább fogja a gépet.
u-player wrote:A tippeket azért köszi, természetesen keresem tovább a probléma forrását. Nem hinném, hogy egy adott PHP szkripttel lenne gond, mert a botok nem mindig ugyanazon az oldalon „landolnak”, amikor a szerverre érkeznek, mégis egy-két szóból felmegy a load…Mint itt mindenki más, én is csak jót torpedózom, mert a nagy terhelés alatt készült apache access log nélkül 100%-ban tiszta vaktában lövöldözés bárki bármit is ír. Akár mesterséges terhelésnél is tesztelhetsz (pl. „wget -m”), nem kell megvárni a keresőket. Az az egy biztos, hogy a válasz az apache és a PHP napló fájlokban van, a kérdés inkább az, hogyan tudod dalra fakasztani őket.
dotmind wrote:a top ot figyelgesd a problemas idoszakban.Szerintem az esetben csak a sar (vagy egyenértékű 🙂 ) jöhet szóba
u-player wrote:dotmind: 1 db 1 magos CPU (eddig bőven elég volt ez is), az átlagos terheltség 0.00 és 0.10 között van, (…) amikor (mondjuk tegnap este 8 után) 30-35 oldal / 10 perc. Szóval (szerintem) minimális.Az apache (és csak az apache) egy lassú 5 éves gépen is több 100 kérés / másodperc sebességgel képes kiszolgálni. Az más kérdés, hogy a többi komponens mire képes.
u-player wrote:Mostanában megérkeznek egyszerre a keresőrobotok (náhány perc eltéréssel) és szépen elindul felfelé a terheltség, egészen 10-11-ig, és ha elmennek a „kedves” botok, akkor is jóval 5 felett marad. Egyértelműen az apache miatt magas a terheltség, olyankor több szálon fut, és csak egy apache restart (csak a restart, a reload nem) oldja meg a problémát. Cron-ból nem fut semmi olyankor, mysql is teljesen normálisnak tűnik.Az apache (mint szoftver) egy HTTP kiszolgáló szerver, az apache (mint user ID) egy apache nevű folyamat (+ szálak) ami az apache szoftver és a dinamikusan betöltött modulok (pl. PHP) ténykedéseit együttesen azonosítja. Tehát apache != apache.
u-player wrote:vector: az uptime / top / htop-nál mutatott értékekre gondolok a terheltségi értékeknél… elfogadom, hogy az apache nem jól van beállítva, de ezzel most így kapásból nem tudok mit kezdeni, mert még sosem találkoztam ezzel a jelenséggel.Egy rossz beállítás egyedül ritkán okoz nagyságrendileg száz vagy ezerszeres lassulást.
u-player wrote:Én sem a robots.txt-t piszkálnám, úgy gondolom, hogy az apache-al kellene valamit kezdenem… csak megint nem akarom elhinni, hogy egyedül én futok bele ebbe a problémába, és gondoltam, hogy lesz, aki kapásból megmondja, hogy „na fiam ezt itt is itt nem jól állítottad be…” 🙂A tartalomkiszolgálás és teljesítmény optimálás komplex folyamat. Nem fogsz olyan okosságot kapni, hogy „ezt álltsd át erre, és minden rendben lesz lesz”.
Sajnos megfeletkezel arról a tényről, hogy egy kereső egyenletesen mindent körbejár, míg „normális használat” esetén nagyjából az oldalak több mint 90%-a a forgalom kevesebb mint 10%-ában kerülnek kiszolgálásra. Így egy cikk PDF export vagy egy valósidejű képgenerálás (pl. diagramm) nagyjából többezer weboldal kiszolgálásáig tart és nem okoz lenyeges terhelést. Mivel kicsi a terhelés nincs gyorstárazás, tehát a keresők minden tartalmat valósidejűleg generálnak.
Mit kellene tenni hogy „megjavuljon”?
1. naplózd a PHP kéréseket
2. nézd meg milyen dinamikus tartalom van kiszolgálva
3. nézd meg van-e gyorstáratás valahol
(…)
999. nézd meg nincs-e valahol rossz algoritmus egy PHP kódban
(…)
9999. nézd meg valamelyik PHP szkript nem szolgáltat-e túl sok adatot (több MB)
(…)
99999. nézd meg hogy az XXX nevű portál motor beállításaiban az YYY opciónak az értéke valóban ZZZ.
(…)
145736. add fel, reménytelen.u-player wrote:dotmind: 1 db 1 magos CPU (eddig bőven elég volt ez is), az átlagos terheltség 0.00 és 0.10 között van, (…) amikor (mondjuk tegnap este 8 után) 30-35 oldal / 10 perc. Szóval (szerintem) minimális.Az apache (és csak az apache) egy lassú 5 éves gépen is több 100 kérés / másodperc sebességgel képes kiszolgálni. Az más kérdés, hogy a többi komponens mire képes.
u-player wrote:Mostanában megérkeznek egyszerre a keresőrobotok (náhány perc eltéréssel) és szépen elindul felfelé a terheltség, egészen 10-11-ig, és ha elmennek a „kedves” botok, akkor is jóval 5 felett marad. Egyértelműen az apache miatt magas a terheltség, olyankor több szálon fut, és csak egy apache restart (csak a restart, a reload nem) oldja meg a problémát. Cron-ból nem fut semmi olyankor, mysql is teljesen normálisnak tűnik.Az apache (mint szoftver) egy HTTP kiszolgáló szerver, az apache (mint user ID) egy apache nevű folyamat (+ szálak) ami az apache szoftver és a dinamikusan betöltött modulok (pl. PHP) ténykedéseit együttesen azonosítja. Tehát apache != apache.
u-player wrote:vector: az uptime / top / htop-nál mutatott értékekre gondolok a terheltségi értékeknél… elfogadom, hogy az apache nem jól van beállítva, de ezzel most így kapásból nem tudok mit kezdeni, mert még sosem találkoztam ezzel a jelenséggel.Egy rossz beállítás egyedül ritkán okoz nagyságrendileg száz vagy ezerszeres lassulást.
u-player wrote:Én sem a robots.txt-t piszkálnám, úgy gondolom, hogy az apache-al kellene valamit kezdenem… csak megint nem akarom elhinni, hogy egyedül én futok bele ebbe a problémába, és gondoltam, hogy lesz, aki kapásból megmondja, hogy „na fiam ezt itt is itt nem jól állítottad be…” 🙂A tartalomkiszolgálás és teljesítmény optimálás komplex folyamat. Nem fogsz olyan okosságot kapni, hogy „ezt álltsd át erre, és minden rendben lesz lesz”.
Sajnos megfeletkezel arról a tényről, hogy egy kereső egyenletesen mindent körbejár, míg „normális használat” esetén nagyjából az oldalak több mint 90%-a a forgalom kevesebb mint 10%-ában kerülnek kiszolgálásra. Így egy cikk PDF export vagy egy valósidejű képgenerálás (pl. diagramm) nagyjából többezer weboldal kiszolgálásáig tart és nem okoz lenyeges terhelést. Mivel kicsi a terhelés nincs gyorstárazás, tehát a keresők minden tartalmat valósidejűleg generálnak.
Mit kellene tenni hogy „megjavuljon”?
1. naplózd a PHP kéréseket
2. nézd meg milyen dinamikus tartalom van kiszolgálva
3. nézd meg van-e gyorstáratás valahol
(…)
999. nézd meg nincs-e valahol rossz algoritmus egy PHP kódban
(…)
9999. nézd meg valamelyik PHP szkript nem szolgáltat-e túl sok adatot (több MB)
(…)
99999. nézd meg hogy az XXX nevű portál motor beállításaiban az YYY opciónak az értéke valóban ZZZ.
(…)
145736. add fel, reménytelen.vector wrote:Nem vagyok benne biztos de régen valaki csinált egy átutalásos plugint asszem az OSCommerce-hez és talán a K&H API-ját használták. De a modul biztos megkészült, járj utána melyik bankra.Sok bankhoz képes nagyon sok szoftver kártyás fizetési módot bizosítani. De most fordított irányra van szükség, nem küldeni kell, hanem a fogadott átutalásokat kellene kezelni az összeg és közlemény rovat alapján. Ahogy értelmezem, olyan automata warez FTP-hez nagyon hasonló megoldás kellene, ahol a pistike befizeti a lóvét számlára, és automatikusan megkapja az FTP hozzáférést ha a számlán megjelenik a pénz. Nem teljesen egyértelmű, ezeket hámoztam ki:
1. lakossági bankszámlát lehet használni
2. kézi beavatkozás nélkül lehet lekédezni a bejövő utalásokat
3. egyszerű GET/POST hívásokkal.Ezzel szemben a tény:
1. csak céges számlával megy, külön szerződéssel
2. jogi (felelősség megállapítás) probléma miatt csak kézi beavatkozással működik
3. erős titkosítás és általában hardveres aznosító eszköz használatával vehető igénybe
+1: egyedi szerződéssel és hitelesített szoftverrel minden megvalósítható, de megfizethetetlen.Viszont van lakossági „netbank” szolgáltatás, amit ha valaki robottal vesz igénybe megsérti a felhasználási szabályokat és letiltják a számláját.
Tehát van elméleti lehetőség, csak a realitás zéró.
vector wrote:Nem vagyok benne biztos de régen valaki csinált egy átutalásos plugint asszem az OSCommerce-hez és talán a K&H API-ját használták. De a modul biztos megkészült, járj utána melyik bankra.Sok bankhoz képes nagyon sok szoftver kártyás fizetési módot bizosítani. De most fordított irányra van szükség, nem küldeni kell, hanem a fogadott átutalásokat kellene kezelni az összeg és közlemény rovat alapján. Ahogy értelmezem, olyan automata warez FTP-hez nagyon hasonló megoldás kellene, ahol a pistike befizeti a lóvét számlára, és automatikusan megkapja az FTP hozzáférést ha a számlán megjelenik a pénz. Nem teljesen egyértelmű, ezeket hámoztam ki:
1. lakossági bankszámlát lehet használni
2. kézi beavatkozás nélkül lehet lekédezni a bejövő utalásokat
3. egyszerű GET/POST hívásokkal.Ezzel szemben a tény:
1. csak céges számlával megy, külön szerződéssel
2. jogi (felelősség megállapítás) probléma miatt csak kézi beavatkozással működik
3. erős titkosítás és általában hardveres aznosító eszköz használatával vehető igénybe
+1: egyedi szerződéssel és hitelesített szoftverrel minden megvalósítható, de megfizethetetlen.Viszont van lakossági „netbank” szolgáltatás, amit ha valaki robottal vesz igénybe megsérti a felhasználási szabályokat és letiltják a számláját.
Tehát van elméleti lehetőség, csak a realitás zéró.
legutóbbi hsz