Debian és Ubuntu szervereken a Drupal sessions tábla túl nagyra nő

Probléma: Ha Debian vagy Ubuntu szerveren futtatsz Drupal-t és a session kezeléssel kapcsolatos beállításokat nem állítottad át a php.ini-ben, akkor a Drupal sessions tábla soha nem lesz ürítve, ezért túl nagyra fog duzzadni, napról napra egyre jobban lelassítva a weboldaladat.

Megoldás: A Drupal settings.php-be szúrd be ezt a két sort:

<?php
ini_set
('session.gc_probability',   5);
ini_set('session.gc_divisor',       100);
?>

és esetleg finomhangold ezt a sort:
<?php
ini_set
('session.gc_maxlifetime',   200000);
?>

Egy másik megoldás, ha a .htaccess fájlba vagy az Apache virtualhost definícióba szúrod be ezt a két sort:
php_value 'session.gc_probability' 5
php_value 'session.gc_divisor' 100

Miért csak Debian alapú szervereken?

Nade mit is csinál ez a két sor és miért kell ezzel külön foglalkozni a Debian alapú szervereken?

Ahhoz, hogy megértsük a problémát, bele kell kicsit mélyednünk a Drupal lelkivilágába.

Nem csak az asztali gépemen fut Ubuntu, hanem szervernek is szívesen használom. Így vettem észre, hogy az f1vilag.hu oldalon, ami egy elég forgalmas site, a session táblában nagyon sok bejegyzés van. Hamar kiderült, hogy a táblából soha nem kerülnek ki a régi sorok, mindig csak az újak kerülnek beszúrásra.

Utánanéztem, hogy ez hogyan lehetséges, és egy kis keresgélés után kiderült, hogy a Drupal a sess_gc nevű függvényében ürítené a táblát. Az is hamar kiderült, hogy ezt a függvényt nem közvetlenül hívja meg a Drupal, hanem indirekt módon, a PHP-t kéri meg, hogy néha hívogassa ezt a függvényt, amikor a PHP azt jónak látja. Ezt egyébként úgy éri el a Drupal, hogy a session_set_save_handler függvény 6. paramétereként megadja visszahívandó callback függvényként a 'sess_gc'-t.

A PHP egy véletlen sorsolással dönt arról, hogy mikor kell meghívni a munkamenet szemétgyűjtőt, ismertebb nevén a session garbage collectort. A fent beállított értékek esetén, minden 100 oldalletöltés esetén átlagosan 5 alkalommal fog végrehajtódni a takarítás.

Ez mint szép és jó, de miért nem teszi ezt meg magától a PHP Debian alatt és miért teszi meg más rendszerek alatt? A választ megkapjuk, ha bepillantunk a php.ini ide vonatkozó részébe egy Ubuntu vagy Debian alatt:

; Define the probability that the '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.

; This is disabled in the Debian packages, due to the strict permissions
; on /var/lib/php5.  Instead of setting this here, see the cronjob at
; /etc/cron.d/php5, which uses the session.gc_maxlifetime setting below.
; php scripts using their own session.save_path should make sure garbage
; collection is enabled by setting session.gc_probability
;session.gc_probability = 0
session.gc_divisor     = 100

Debian alatt tehát ki van kapcsolva a php beépített session garbage collection funkciója, és helyettesítve van egy ütemezett feladattal (cronjob). Ami viszont csak annyit tesz, hogy a php session fájljait törölgeti félóránként. Ezért nem lesz soha meghívva a drupal sess_gc függvénye és ezért nő a sessions tábla a végtelenségig. A php.ini-ben, mint fent olvashattuk, nem is érdemes visszakapcsolni ezt a funkciót. Inkább a Drupal-ban állítsuk vissza ezt a funkciót, amelynek hatására már rendszeresen meg fog hívódni a sess_gc függvény és nem nő a végtelenségig a sessions tábla.

10 hozzászólás

A weboldal látogatottságától

A weboldal látogatottságától függ, általánosan nem lehet semmit mondani a méretről. A sessions tábla soraiban van egy UNIX "timestamp" mező. Nézd meg melyik a legrégebbi. Ha túl régi akkor ebből is látni fogod, hogy nálad is jelentkezik-e a probléma.

Nnna, ebből a nyilvánvaló

Nnna, ebből a nyilvánvaló bugból is látszik, hogy a Drupal egy elég amatőr rendszer. Ha igazán profi és megbízható CMSt akartok, aminél nem kell minden pillanatban azon remegni, hogy mikor lassul be végzetesen, mint a Drupal, a DotNetNuke az egyértelmű választás. Persze egy kicsit több szakértelem kell hozzá, de nincsenek benne ilyen komoly hibák! (nem véletlen - egy profi csapat fejleszti, nem netes hekkerek!)

Én hajlandó lennék hinni

Én hajlandó lennék hinni neked, ha legalább néhány tényt felsorakoztatnál. A politikusoktól már megszokhattuk az érzelem-dús, tényektől mentes nyilatkozatokat, az IT szakmában még nem.

És ahogy NeverGone is írta, egy "apró" probléma az érveléseddel, hogy a hibát nem is a Drupal okozza. Nnna, ez az ami nyilvánvaló kellett volna legyen Neked is :)

Zsolti: Bocsi, de ezt

Zsolti: Bocsi, de ezt alaposan mellénézted. :)
Itt nem a Drupal hiányosságáról van szó, hanem a Debian alapú rendszerekben (ilyen az Ubuntu is) oldották meg másképpen a problémát.
Szóval szerintem kicsit frissítsd az ismereteid, mert ez a hozzászólásod erős amatőrségre vall, a "profi csapat" vs. "netes hekkerek" témában pedig csak ennyit: http://acquia.com/

Új hozzászólás