2011-10-19 8 views
36

PHPマニュアルから、session.gc_probabilityとsession.gc_divisorは、この確率に基づいてgcが発生すると述べています。私はそれを得る。PHPガベージコレクションの明確化

私は、この確率がセッション単位であるのか全体的なのかについてはっきりしていません。

したがって、GCが発生する確率が1%(1/100)であれば、1つのセッションが拡張され続けると、1%の変更があるたびに特定のセッションがクリーンアップされることを意味しますか?これは、既存のすべてのセッション(および新しいセッション)の1%が他のすべての既存のセッションでGCを起動することを意味しますか?

私はそれが後者であると確信しています、私は確かにしたいです。

この質問の目的は、私たちのサイトでは、長期間のセッション(6ヶ月)を利用したいと考えています。すべてのセッションの1%でGCがトリガーされると、GCはその1時間または2時間ごとに終了するため、長期セッションの目的が実質的に削除されます。

+2

非常に興味深い質問! +1 –

+0

related http://stackoverflow.com/questions/3865303/debian-based-systems-session-killed-at-30-minutes-in-special-cron-how-to-overri –

+0

これを読んでいる人は誰でも6ヶ月間のセッションファイルでは、以下のような重大なパフォーマンス上の問題が発生する可能性があります。ただし、session_set_save_handler()を使用して、FSの代わりにDBを使用するカスタムセッションハンドラを作成し、多くのパフォーマンスの低下を打ち消すことができます。 – Meep3D

答えて

10

PHPスクリプトが実行されてセッションを開始するたびに、古いセッションを強制終了するセッションフォルダをスイープする可能性があります。

クリーンアップは、特定の時間内にアクセスされなかったセッションのみを削除します。しかし、PHPはセッションがその時間内に破棄されることを保証するものではありません。

あなたの長期的なセッションの戦略はうまく動作するはずですが、あなたが外を見るためにもう一つは、オペレーティング・システムは、中に/ tmpフォルダをクリーンアップするかもしれないということである0.1%

のようなものに1%を削減することができますPHPがそれをしなくても再起動します。

+0

確率を1/100から1/1000000(0.000001%)に減らしました。私はその問題を解決することを望んでいる。また、これはMagentoサイトなので、セッションは/ var/sessionに保存されます。このフォルダは、私が知る限り、サーバーには触れられていません(ただし、Magentoの管理者から「キャッシュキャッシュの格納」を選択した場合は削除されます)。 – pspahn

+0

ああ、Magentoがgc_ *設定を無視する代替セッションを実装しないようにしましょう。 – romaninsh

+5

の可能性を減らすという副作用は、古いセッションでハードディスクをいっぱいにすることです。セッションの検索と読み込みに時間がかかりますが、その日の終わりには、たとえリモートで小さい場合でもセッションを消去する機会は最小限に抑えられます。独自のセッションハンドラを作成し、削除するセッションと削除するセッションを正確に制御するなどの代替オプションを検討することができます。それほど難しいことではありません。 http://www.php.net/manual/en/function.session-set-save-handler.php – bumperbox

2

私は専門家ではありませんが、マニュアルを読むことで別の設定session.gc_maxlifetimeに注目しています。ドキュメントから:

session.gc_maxlifetimeデータは「ごみ」として見られ、潜在的にクリーンアップされるまでの秒数を指定します。ガベージコレクションは、セッション開始時に発生することがあります(session.gc_probabilityおよびsession.gc_divisorに応じて)。

あなたが適切な値(半年用60 * 60 * 24 * 365/2、そう15768000)にこの設定を設定するのであれば、その後、適切なデータは関係なく、他の設定が何であるか、ガベージコレクションの対象となりません。

+1

私はすでにgc_maxlifetimeを15552000(180日)に設定しています - devサイトではすべてが正しく動作していたようですが、一旦ライブをプッシュすると、ログインページに戻る前にしばらく働いていました。 – pspahn

+7

この値は「セッション作成後の秒数」または「最後の変更後の秒数」を意味しますか? –

+0

ガベージコレクタをオフにして、セッションデータが辞書に格納されるようにするだけでなく、セッションデータの行に固有のセッションIDを保存するように、Cookieの有効期間を延長する必要があります。 – vikingben

7

最後に、divisorと確率を使用して、session_start()の各呼び出しがソースを見て、「サイコロを巻いた」と話しました。ヒットした場合、session.gc_maxlifetimeより古いすべてのファイルがsession.save_pathディレクトリから削除されます。スクリプトの実行終了時にPHPがセッションファイルをデフォルトで上書きするので、通常の状況では問題ではありませんが、modとアクセス時間はほとんど常に非常に一致するはずです。

// Rough psuedo code of how php's session_start() function works regarding garbage collection. 
function session_start() { 
    $percentChanceToGC = 100 * ini_get('session.gc_probability')/ini_get('session.session.gc_divisor'); 
    $shouldDoGarbageCollection = rand(1, 100) < $percentChanceToGC; 
    if ($shouldDoGarbageCollection) { 
     $expiredCutoffTime = time() - ini_get('session.gc_maxlifetime'); 
     foreach (scandir(ini_get('session.save_path')) as $sessionFile) { 
      if (filemtime($sessionFile) < $expiredCutoffTime) { 
       unlink($sessionFile); 
      } 
     } 
    } 

    // ... rest of code .... 
} 

あなたが最低6ヶ月間生きて欲しいと思っている場合、何回セッションファイルがハングアップするのか分かりません。 phpが何千ものファイルを統計して年齢を判断するのに少し時間がかかるかもしれないと考えてください。おそらく、このデータの耐久記憶のための他のオプションを検討してください。またはphp gcを無効にして、古いセッションファイルを削除するためのcronジョブを実行することもできます。さもなければ、リクエストの1%がgcを起動させ、PHPを待たなければなりません。言い換えれば、遅れる可能性があります。