Ha jól láttam a settings.php-ban (illetve a szerveren globálisan) meghatározott session.gc_maxlifetime értéke határozza meg az időt, amíg az adatbázisban tárolódnak az értékek.
A cron rendben lefut időközönként?
Indítottam cron-t, ki- és bejelentkeztem, de eddig még egyszer sem futott le a függvény. Lehet, hogy errefelé van a probléma...
Tudja valaki ez mitől lehet?
Hát nem tudom ... de nagyon aggaszt, mert már 32 ezer rekordnál járok és nem látom mitől lenne egyszer csak vége. Van másik három drupál site-om és azok szépen ketyegnek nem látok ilyen furcsaságot.
A default 200 ezres session érték azt jelentené, hogy 138 napig tárolja a sessonöket? A google telenyomja a session táblát és ez 138 napig meg sem áll? Biztos így kell ennek működnie?
Beállítottam a session értékeket 1 napra ás felírtam a legöregebb sessin értéket. Pár napig nézegetem, de az az érzésem a debug azt fogja mondani nem törlődik belőle semmi, csak hozzá adódik ....
vagy csak a magyar fórumokon szokásos letorkolom/hozzá se szólok megy? Ne ábrándítsatok má' ki a drupálból és a magyar drupál közösségből.
Hetek óta szívok és .....
Legalább annyit bökjetek ki mekkora egy átlagos és jól működő sessions tábla napi 100 letöltés, 200 látogató mellett? Azt gondolnám beáll egy nagyjáboli fix méretre és a rendszer pucolja a régi, lejártakat.
Átlagos webhely adataival nem tudok szolgálni :) De megnéztem neked, a drupal.hu session táblája 1600 rekordos, a weblabor.hu session táblájában 333ezer(!) rekord van. Minkét esetben ezen rekordok kétharmada tegnapi vagy tegnapelőtti, egyharmada mai keltezésű (egyébként ez nagyon szépen illeszkedik a fent emlegetett két és fél napos alapbeállításhoz, ha grafikonon ábrázolnánk, jól látszana, hogy tegnap előttről már nincs annyi bejegyzés, és még ma sincs vége a napnak). Nem véletlen, hogy a Drupal 5-ösben törekednek az anoním sessionök elkerülésére, a drupal.hu session-ök közül közel száz azonosított felhasználó, a weblaboron kétszer annyi, a többi anoním session. (A weblabor régebbi Drupal verziót futtat, a Drupal.hu a legújabbat, látszik is).
A default 200 ezres session értéknél nem állt meg 34 ezer rekornál sem. Tegnap de. ürítettem a táblát, visszavettem egy napra az értéket. Most kb. 8000 rekord van benne és vannak benne másfél naposak is! Megnéztem az első tegnap délelőtti rekordot és még mindig benne van most is.
A 8000 rekordból csak 16 db nem anonim!!! A rendszer Drupal 5.1 (www.spicy.hu)
Hol lehet tovább keresni a hibát? Kérem segítsetek!
Az egész témát három napja indítottad, és már a tizenötödik hozzászólásnál tartunk... Azért én nem lennék a helyedben ennyire elégedetlen...
A default 200 ezres session értéknél nem állt meg 34 ezer rekornál sem.
És ez meglep? Fent már leírták, hogy ez időt határoz meg, ha neked hirtelen ennyi látogatód volt (mindegy, hogy spammerek vagy googlebot), akkor ne lepődj meg, hogy felugrott.
Hol lehet tovább keresni a hibát?
Először is a türelmetlenségben. A régebbi session azonosítók törlése nem automatikus az adott időpontban. Alapbeállításban egy százalék esélye van mindig annak, hogy a régi session-öket eltakarító kód egyáltalán el fog indulni, elvileg ez sokáig is elhúzhatja a munkamenetek életét. http://hu.php.net/session:
session.gc_divisor coupled with session.gc_probability defines the probability that the gc (garbage collection) process is started on every session initialization. The probability is calculated by using gc_probability/gc_divisor, e.g. 1/100 means there is a 1% chance that the GC process starts on each request. session.gc_divisor defaults to 100.
Én a helyedben még figyelném egy ideig a dolgokat, és nem türelmetlenkednék.
Egyébként a bemásolt settings.php tartalma semmi garanciát nem ad arra, hogy a PHP tényleg ezekkel a beállításokkal dolgozik. Ha a szerveren nem módosítható értékeknek vannak ezek beállítva, akkor hiába próbálod ini_set()-ből felülírni. Egy phpnfo() hívás az ini_set()-ek után meg tudja mutatni, hogy tényleg milyen beállításokat használ a PHP.
1, Elégedettségemet (már amennyire ez fontos) nem a hozzászólások száma, hanem azok minősége és használhatósága adja.
2, Nem olvasod el figyelmesen a hozzászólásokat, ha olyan analfabétának tartasz, hogy azt hiszem a 200 ezres értékből következik és arányítható a tábla rekordjainak száma é snem tudom, hogy időt határoz meg. Megnéztem a vonatkozó ini_set paraméterek pontos leírást (igaz egy mértékegységgel elnéztem a min. és a sec. vonatkozásában)
Én mielőtt ilyen fórumon tanácsot kérnék százszor utánanézek inkább előbb magamtól mindenhol, megpróbálom magam megoldani a dolgokat és ha végképpen nem megy akkor írok, mert félő hogy tanács helyett ilyen sértődött dorgálásban, égetésben lesz részem.
3, "Hol lehet tovább keresni a hibát?" -> Először is a türelmetlenségben. Na kössz ez aztán remek válasz. no comment.
4, "Én a helyedben még figyelném egy ideig a dolgokat, és nem türelmetlenkednék." Én se türelmetlenkednék, ha nem homlok egyenest máshogy viselkedne ez a sit emint a többi azonos kódot használó drupál oldalam. Nagyjából azonos a googlebot és spamrobot terhelése valamint a látogató száma. Ezért voltam kiváncsi, más oldalak statisztikájára ebből a szempontból, mert én csak az én pár drupál oldalamt tudom megnézni.
5, Kössz. Tudom, hogy nem biztos, hogy érvénre jutnak az ini_set beállításaim. Ezt is előbb ellenőriztem, csak a settings.php-ből egyszerűbb volt bemásolni.
és végül,
én tényleg meg akartam köszönni és hálát éreztem, hogy végre ránéztetek és a szavaimat tényleg köszönetnek szántam eredeileg!
Sajnálom, hogy egyből lámának nézve rutinból így reagáltál. Remélem normális mederbe kerül a téme és egymás égetése helyett problémamegoldásra kerül a hangsúly ;)
Már bocsánat, de amíg olyan értelmetlen összefüggéseket emlegetsz, hogy "A default 200 ezres session értéknél nem állt meg 34 ezer rekornál sem" addig nehéz arra asszociálni, hogy tudod, miről beszélsz. Abból lehet megítélni a hátteredet, amit ide írsz, például hogy a settings.php-t másolod be, abból nem derül ki, hogy tudod, hogy nem biztos, hogy az tényleg úgy van-e a futó PHP-dben, vagy ha tudod, ellenőrizted-e. Ilyen dolgokkal meg tudnánk egymásnak spórolni egy csomó időt!
No, mindenesetre tehetsz ilyet a Drupal sess_gc() implementációjába:
Ezután az eseménynaplóban nézegetheted, hogy lefut-e a szemétgyűjtés, a sess_gc típusú üzenetekre szűrve az eseményeket. Ha gyakran lefut, akkor persze ettől a watchdog táblád fog egy kicsit duzzadni, de úgyis ott ülsz mellette és egyfolytában figyeled, úgy látom.
Jól látod ott ülök a logok előtt ez a dolgom :D Sok (kb 10) éve üzemeltetek oldalakat (igaz pechetekre most már drupalt is), és megtanultam, hogy ha valami eltérően viselkedik a megszokottól, akkor azzal nem lehet viccelni, mert nagyon meg lehet szívni. Úgy tanítottak, hogy egy rendszergazda legyen inkább paranoiás, mint utólag sopánkodó ...
Beraktam az ominózus site-ra és egy jól működő kontroll site-ra debug kódot és az bizonyította, hogy tényleg nem fut le a session garbage az ominózuson, míg a másikon lefut időnként.
Tovább kerestem az angol drupal site fórumon és találtam haonló problémával küzködő kollégákat: http://drupal.org/node/58069 mely ezzel zárult: "PHP does this automatically based on your sessions_gc time. Not drupal's responsibility. read up on session garbage collection in php."
Egybevetettem a phpinfo() által adott értékeket a manualban leírtakkal.
És hoppá! a session.gc_probability értéke a szerveren 0! Tehát a valószínűsége hogy a karbantartás elinduljon 0/100 :D
Ezután újabb ini_set sorokkal egészítettem ki a settings.php-t és gondolom nem csodálkoztok, ha most már elégedett vagyok a rekordok számával. a biztonság kedvéért a session.gc_divisor-t belevettem a default értékkel, hátha holnap ezzel viccel meg a szolgáltatóm :)
Tehát Hojtsy Gábor köszönöm, hogy segítettél a debug kóddal és helyes irányba tereltél ;) és fentartom, hogy nem kellett türelmesnek maradnom, paranoia rulez!
Szerencsés mellékhatása ennek a témának (örülök, hogy ezen keresztül kiderült), hogy a Weblaboron egy kis kód módosítással megoldottuk, hogy az ott teljesen felesleges anoním session tárolás ne történjen meg. Így a háromszázezerről pár százra csökkent a session bejegyzések száma, és a Weblabor is jobban muzsikál.
Véletlenül találtam meg ezt a topikot, és pont nekem is az volt a problémám, három hét alatt 100.000 sor gyült fel a session táblában. Már kézzel ürítgettem, mert a tárhelyszolgáltatónál kiléptem a 30 MB -os keretből. Nem gondoltam volna, hogy a szolgáltató a ludas (web-szerver.hu) na nem akarom én leszolni, csak tudom, hogy itt is sokan használják, és nem sejtik hogy a session.gc_probability 0 ra van állítva.
Na a lényeg, hogy szerintem be kerülhetne ez az 1 sor a Drupal csomagba mert biztos vagyok benne hogy sok ember nem is sejti, hogy nincs karbantartva a session táblája.
H. Gábor nem tudom neked erről mi a véleményed, esetleg megemlíthetnéd az illetékeseknek. :) Biztos sokakon segítene.
Érdekességképpen még megnéztem néhány szolgáltatót:
nem nagyon vicces a dolog
jelzem, már 31 ezer recordnál tart a tábla
cron?
Szia.
Ha jól láttam a settings.php-ban (illetve a szerveren globálisan) meghatározott session.gc_maxlifetime értéke határozza meg az időt, amíg az adatbázisban tárolódnak az értékek.
A cron rendben lefut időközönként?
Üdv: Zoli
A cron a log szerint szépen fut a poormanscron-al 30 percenként.
Én is az általad említett értékek letekerésétől vártam a megoldást. Default értékük 200 ezer és én ezt visszavettem 7200-ra.
Fura
Beszúrtam a következő sort a session.inc fájl sess_gc függvényébe:
$fp = fopen("/tmp/proba.log", 'w');fwrite($fp, "Proba");fclose($fp);Indítottam cron-t, ki- és bejelentkeztem, de eddig még egyszer sem futott le a függvény. Lehet, hogy errefelé van a probléma...
Tudja valaki ez mitől lehet?
Üdv: Zoli
a sessions tábla csak tovább hízik
Hát nem tudom ... de nagyon aggaszt, mert már 32 ezer rekordnál járok és nem látom mitől lenne egyszer csak vége. Van másik három drupál site-om és azok szépen ketyegnek nem látok ilyen furcsaságot.
Kézzel...
_Szerintem_ ideiglenesen futtasd le manuálisan azt az sql lekérdezést, amit a drupal is futtatna a sess_gc függvényben.
De előtte azért csinálj egy backup-ot... mert lehet, hogy butaságot mondok.
Üdv: Zoli
session tárolás 138 napig?
A default 200 ezres session érték azt jelentené, hogy 138 napig tárolja a sessonöket? A google telenyomja a session táblát és ez 138 napig meg sem áll? Biztos így kell ennek működnie?
Kb. 2.5 nap
Az másodpercben van megadva, ami kb. 2.5 napot jelent.
Üdv: Zoli
akkor csak gáz van a session táblával
mert 7200-ra vissza véve session limiteket, lifetime-okat... már meg kelett volna állnia (most 34 ezer rekordnál tart)
Sessions táblát ürítettem
Beállítottam a session értékeket 1 napra ás felírtam a legöregebb sessin értéket. Pár napig nézegetem, de az az érzésem a debug azt fogja mondani nem törlődik belőle semmi, csak hozzá adódik ....
Van itt a fórumon néha sagítőkész drupal guru is?
vagy csak a magyar fórumokon szokásos letorkolom/hozzá se szólok megy? Ne ábrándítsatok má' ki a drupálból és a magyar drupál közösségből.
Hetek óta szívok és .....
Legalább annyit bökjetek ki mekkora egy átlagos és jól működő sessions tábla napi 100 letöltés, 200 látogató mellett? Azt gondolnám beáll egy nagyjáboli fix méretre és a rendszer pucolja a régi, lejártakat.
átlagos?
Átlagos webhely adataival nem tudok szolgálni :) De megnéztem neked, a drupal.hu session táblája 1600 rekordos, a weblabor.hu session táblájában 333ezer(!) rekord van. Minkét esetben ezen rekordok kétharmada tegnapi vagy tegnapelőtti, egyharmada mai keltezésű (egyébként ez nagyon szépen illeszkedik a fent emlegetett két és fél napos alapbeállításhoz, ha grafikonon ábrázolnánk, jól látszana, hogy tegnap előttről már nincs annyi bejegyzés, és még ma sincs vége a napnak). Nem véletlen, hogy a Drupal 5-ösben törekednek az anoním sessionök elkerülésére, a drupal.hu session-ök közül közel száz azonosított felhasználó, a weblaboron kétszer annyi, a többi anoním session. (A weblabor régebbi Drupal verziót futtat, a Drupal.hu a legújabbat, látszik is).
akkor az én session kezelésemmel valami hibádzik ....
Köszönöm, hogy végre ránéztetek a fórumra!
A default 200 ezres session értéknél nem állt meg 34 ezer rekornál sem. Tegnap de. ürítettem a táblát, visszavettem egy napra az értéket. Most kb. 8000 rekord van benne és vannak benne másfél naposak is! Megnéztem az első tegnap délelőtti rekordot és még mindig benne van most is.
A 8000 rekordból csak 16 db nem anonim!!! A rendszer Drupal 5.1 (www.spicy.hu)
Hol lehet tovább keresni a hibát? Kérem segítsetek!
végre ránéztünk?
Az egész témát három napja indítottad, és már a tizenötödik hozzászólásnál tartunk... Azért én nem lennék a helyedben ennyire elégedetlen...
És ez meglep? Fent már leírták, hogy ez időt határoz meg, ha neked hirtelen ennyi látogatód volt (mindegy, hogy spammerek vagy googlebot), akkor ne lepődj meg, hogy felugrott.
Először is a türelmetlenségben. A régebbi session azonosítók törlése nem automatikus az adott időpontban. Alapbeállításban egy százalék esélye van mindig annak, hogy a régi session-öket eltakarító kód egyáltalán el fog indulni, elvileg ez sokáig is elhúzhatja a munkamenetek életét. http://hu.php.net/session:
Én a helyedben még figyelném egy ideig a dolgokat, és nem türelmetlenkednék.
Egyébként a bemásolt settings.php tartalma semmi garanciát nem ad arra, hogy a PHP tényleg ezekkel a beállításokkal dolgozik. Ha a szerveren nem módosítható értékeknek vannak ezek beállítva, akkor hiába próbálod ini_set()-ből felülírni. Egy phpnfo() hívás az ini_set()-ek után meg tudja mutatni, hogy tényleg milyen beállításokat használ a PHP.
Re: végre ránéztünk? Session tábla mizéria
1, Elégedettségemet (már amennyire ez fontos) nem a hozzászólások száma, hanem azok minősége és használhatósága adja.
2, Nem olvasod el figyelmesen a hozzászólásokat, ha olyan analfabétának tartasz, hogy azt hiszem a 200 ezres értékből következik és arányítható a tábla rekordjainak száma é snem tudom, hogy időt határoz meg. Megnéztem a vonatkozó ini_set paraméterek pontos leírást (igaz egy mértékegységgel elnéztem a min. és a sec. vonatkozásában)
Én mielőtt ilyen fórumon tanácsot kérnék százszor utánanézek inkább előbb magamtól mindenhol, megpróbálom magam megoldani a dolgokat és ha végképpen nem megy akkor írok, mert félő hogy tanács helyett ilyen sértődött dorgálásban, égetésben lesz részem.
3, "Hol lehet tovább keresni a hibát?" -> Először is a türelmetlenségben. Na kössz ez aztán remek válasz. no comment.
4, "Én a helyedben még figyelném egy ideig a dolgokat, és nem türelmetlenkednék." Én se türelmetlenkednék, ha nem homlok egyenest máshogy viselkedne ez a sit emint a többi azonos kódot használó drupál oldalam. Nagyjából azonos a googlebot és spamrobot terhelése valamint a látogató száma. Ezért voltam kiváncsi, más oldalak statisztikájára ebből a szempontból, mert én csak az én pár drupál oldalamt tudom megnézni.
5, Kössz. Tudom, hogy nem biztos, hogy érvénre jutnak az ini_set beállításaim. Ezt is előbb ellenőriztem, csak a settings.php-ből egyszerűbb volt bemásolni.
és végül,
én tényleg meg akartam köszönni és hálát éreztem, hogy végre ránéztetek és a szavaimat tényleg köszönetnek szántam eredeileg!
Sajnálom, hogy egyből lámának nézve rutinból így reagáltál. Remélem normális mederbe kerül a téme és egymás égetése helyett problémamegoldásra kerül a hangsúly ;)
mit tudunk egymásról?
Már bocsánat, de amíg olyan értelmetlen összefüggéseket emlegetsz, hogy "A default 200 ezres session értéknél nem állt meg 34 ezer rekornál sem" addig nehéz arra asszociálni, hogy tudod, miről beszélsz. Abból lehet megítélni a hátteredet, amit ide írsz, például hogy a settings.php-t másolod be, abból nem derül ki, hogy tudod, hogy nem biztos, hogy az tényleg úgy van-e a futó PHP-dben, vagy ha tudod, ellenőrizted-e. Ilyen dolgokkal meg tudnánk egymásnak spórolni egy csomó időt!
No, mindenesetre tehetsz ilyet a Drupal sess_gc() implementációjába:
Ezután az eseménynaplóban nézegetheted, hogy lefut-e a szemétgyűjtés, a sess_gc típusú üzenetekre szűrve az eseményeket. Ha gyakran lefut, akkor persze ettől a watchdog táblád fog egy kicsit duzzadni, de úgyis ott ülsz mellette és egyfolytában figyeled, úgy látom.
Tényleg köszönöm!
Beraktam a kódot.
Jól látod ott ülök a logok előtt ez a dolgom :D Sok (kb 10) éve üzemeltetek oldalakat (igaz pechetekre most már drupalt is), és megtanultam, hogy ha valami eltérően viselkedik a megszokottól, akkor azzal nem lehet viccelni, mert nagyon meg lehet szívni. Úgy tanítottak, hogy egy rendszergazda legyen inkább paranoiás, mint utólag sopánkodó ...
HG! Pont került a sessions tábla mizéria végére!
Megosztom a tanulságokat:
Beraktam az ominózus site-ra és egy jól működő kontroll site-ra debug kódot és az bizonyította, hogy tényleg nem fut le a session garbage az ominózuson, míg a másikon lefut időnként.
Tovább kerestem az angol drupal site fórumon és találtam haonló problémával küzködő kollégákat: http://drupal.org/node/58069 mely ezzel zárult: "PHP does this automatically based on your sessions_gc time. Not drupal's responsibility. read up on session garbage collection in php."
Tehát még egyszer nekilátam a php manual még tüzetesebb bogarászásának: http://www.phpfreaks.com/phpmanual/page/ref.session.html
Egybevetettem a phpinfo() által adott értékeket a manualban leírtakkal.
És hoppá! a session.gc_probability értéke a szerveren 0! Tehát a valószínűsége hogy a karbantartás elinduljon 0/100 :D
Ezután újabb ini_set sorokkal egészítettem ki a settings.php-t és gondolom nem csodálkoztok, ha most már elégedett vagyok a rekordok számával. a biztonság kedvéért a session.gc_divisor-t belevettem a default értékkel, hátha holnap ezzel viccel meg a szolgáltatóm :)
most így néz ki a kiegészítés:
ini_set('session.gc_probability',1);
ini_set('session.gc_divisor',100);
Tehát Hojtsy Gábor köszönöm, hogy segítettél a debug kóddal és helyes irányba tereltél ;) és fentartom, hogy nem kellett türelmesnek maradnom, paranoia rulez!
/sites/default/settings.php
ini_set('arg_separator.output', '&');
ini_set('magic_quotes_runtime', 0);
ini_set('magic_quotes_sybase', 0);
ini_set('session.cache_expire', 86400);
ini_set('session.cache_limiter', 'none');
ini_set('session.cookie_lifetime', 86400);
ini_set('session.gc_maxlifetime', 86400);
ini_set('session.save_handler', 'user');
ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid', 0);
ini_set('url_rewriter.tags', '');
ini_set('memory_limit', '64M');
mellékhatás
Szerencsés mellékhatása ennek a témának (örülök, hogy ezen keresztül kiderült), hogy a Weblaboron egy kis kód módosítással megoldottuk, hogy az ott teljesen felesleges anoním session tárolás ne történjen meg. Így a háromszázezerről pár százra csökkent a session bejegyzések száma, és a Weblabor is jobban muzsikál.
Köszi a segítséget
Véletlenül találtam meg ezt a topikot, és pont nekem is az volt a problémám, három hét alatt 100.000 sor gyült fel a session táblában. Már kézzel ürítgettem, mert a tárhelyszolgáltatónál kiléptem a 30 MB -os keretből. Nem gondoltam volna, hogy a szolgáltató a ludas (web-szerver.hu) na nem akarom én leszolni, csak tudom, hogy itt is sokan használják, és nem sejtik hogy a session.gc_probability 0 ra van állítva.
Na a lényeg, hogy szerintem be kerülhetne ez az 1 sor a Drupal csomagba mert biztos vagyok benne hogy sok ember nem is sejti, hogy nincs karbantartva a session táblája.
H. Gábor nem tudom neked erről mi a véleményed, esetleg megemlíthetnéd az illetékeseknek. :) Biztos sokakon segítene.
Érdekességképpen még megnéztem néhány szolgáltatót:
extra.hu Rendben
hostgator.com Rendben
000webhost.com Rendben