- This topic has 38 hozzászólás, 6 résztvevő, and was last updated 16 years, 1 months telt el by
.
-
Bejegyzés
-
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.Nem felejtettem el a botokat, számoltam velük, csak arra nem számítottam, hogy egyszerre jön az összes… Szerintem ez máshol is problémát okozna kisebb szervereken. Eddig is jöttek, csak nem egyszerre és huszad ennyire nem lassították le a rendszert. Mennyire általános ez, hogy egyszerre ennyi keresőrobot jöjjön mindig egy időben egy adott szerverre?
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…
Azért akinek van tapasztalata / ötlete még, leírhatná, nem akarok eljutni a 145736-os tippig gabaman listáján. 🙂
Nem felejtettem el a botokat, számoltam velük, csak arra nem számítottam, hogy egyszerre jön az összes… Szerintem ez máshol is problémát okozna kisebb szervereken. Eddig is jöttek, csak nem egyszerre és huszad ennyire nem lassították le a rendszert. Mennyire általános ez, hogy egyszerre ennyi keresőrobot jöjjön mindig egy időben egy adott szerverre?
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…
Azért akinek van tapasztalata / ötlete még, leírhatná, nem akarok eljutni a 145736-os tippig gabaman listáján. 🙂
mivel 1 proci van a gepben ezert a geped elmeleti 100%-os terheltsege 1es load. ha a load pl 5 az azt jelenti, hogy 4 folyamatod varakozik a rendszerben. ez siman lehet egy olyan script/query miatt ami nagyon lassan fut le, mivel addig felgyulnek a processzek mogotte. jo lenne tudni mi okozza a loadot.. i/o wait? swap? a proci fogy el? a top ot figyelgesd a problemas idoszakban.
mivel 1 proci van a gepben ezert a geped elmeleti 100%-os terheltsege 1es load. ha a load pl 5 az azt jelenti, hogy 4 folyamatod varakozik a rendszerben. ez siman lehet egy olyan script/query miatt ami nagyon lassan fut le, mivel addig felgyulnek a processzek mogotte. jo lenne tudni mi okozza a loadot.. i/o wait? swap? a proci fogy el? a top ot figyelgesd a problemas idoszakban.
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
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz