Diskuze: Session / mazání - (10 tisíc/den návštěvnost)
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
Člen
Zobrazeno 9 zpráv z 9.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí PHP, jsme si ověřili nabyté zkušenosti z kurzu.
V php.ini jsou k dispozici direktivy pro garbage collection.
session.gc_probability 1
session.gc_divisor 100
session.gc_maxlifetime 1440
Všeobecně by si mělo php poradit se zbytečnými session soubory celkem
obstojně samo bez nutnosti manuálního zásahu.
Tyhle tři direktivy se dají nastavovat i pomocí ini_set().
V podstatě ve výše uvedeném (výchozím nastavení) se spustí garbage
collection jednou ze 100 volání session_start() a označí session soubory
starší než 24 minut jako garbage k odstranění.
Výše zmíněné řešení od Petra je funkční pouze pokud se používá globální tmp složka. Pokud na jednom stroji běží vícero webů, není toho vhodné a používá se pro každý web samostatná tmp složka a v tomto případě už výše uvedené řešení nebude fungovat.
PHP by default nainstaluje do cronu:
/etc/cron.d/php5
Script od Ondřeje Surého, který ale nefunguje, alespoň tedy pro mě ne
/usr/lib/php5/sessionclean
Jako dočasné řešení používám vlastní shell script, který maže soubory, které se po dobu 30 minut nezměnily. To se pak volá ve stejných intervalech jako původní script a je to celkem rychlé. Na serverech se mi generují desítky sessions za vteřinu a neeviduji žádné razantní zpomalení způsobené tímto.
find /var/www/.../tmp -name 'sess_*' -type f -cmin +27 -exec rm {} \;
Pro smazání takto obrovského počtu souborů lze použít následující (rm * apod by se zahltilo a trvalo hrozně dlouho)
ls -f | grep ^sess_ | xargs rm -f
Pokud bys narazil na lepší řešení nebo se ti povedlo zmíněný script od Ondry zprovoznit, budu rád, pokud se podělíš a informuješ mě
Umíš vysvětlit, proč vy mělo být ls s pipama rychlejší než rm *?
Deleting millions of files from a directory can be a daunting task. rm -rf will expand the to glob every file in the directory and return an error such as "Argument list too long".
Obávám se, že Ubuntu zrovna s gc pracovat neumí, nebo aspoň co jsem četl. Nevím zda je nutné něco nastavit, nebo provést nějaký update, ale standardně to neumí. Když by tohle fungovalo, bylo by to asi super řešení. Určitě se na to ještě podívám.
Podobný script používám, ale opravdu jen podobný. Ještě se na to také podívám a určitě dám vědět. Když by to provádělo proces rychle a zároveň to nějak znatelně nezatěžovalo server tak to bude dobrým řešením pro svůj účel.
David Jančík [sczdavos]
Výše zmíněné řešení od Petra je funkční pouze pokud se používá globální tmp složka. Pokud na jednom stroji běží vícero webů, není toho vhodné a používá se pro každý web samostatná tmp složka a v tomto případě už výše uvedené řešení nebude fungovat.
Řešení by mělo fungovat i mimo globální složku. Je nutné nastavit pro každý jednotlivý web session.save_path.
katrincsak:
Obávám se, že Ubuntu zrovna s gc pracovat neumí, nebo aspoň co jsem četl. Nevím zda je nutné něco nastavit, nebo provést nějaký update, ale standardně to neumí.
V Debianu se defaultně php gc vypne a namísto toho se používá cron.
Důvod je ten, že z důvodu bezpečnosti má Debian nastavená práva pro
defaultní složku se sessions na root:root. Php gc pak do složky nevidí, ale
cron běžící pod rootem ano.
Je možné že Ubuntu tuhle vlastnost zdědilo.
Petr Linhart:
Děkuji, tohle je celkem důležitá informace a dává to logiku.
Všem děkuji za informace jakmile se opět dostanu k této problematice označím co z toho pomohlo. Samozřejmě zda máte další názory, tak určitě sem s nimi, každý názor se hodí a jakmile budu moct sdělím informaci.
Zobrazeno 9 zpráv z 9.