ここにマニュアルが私に言ったことがあります：
有効期限が切れたセッションは、実際には24分後に破棄されません。 これがどのように起こるかです：セッションを使用する各リクエストの開始時に（ session_start（）関数の予備呼び出しまたはsession / auto_startをonに設定するため ）、PHPインタープリターがサーバー上のすべてのセッションをスキャンし、期限切れのセッションを削除する可能性が1％あります コンピュータプログラムに関連する「1％の機会」は、まったく予測不可能です。 そうです。 しかし、そのような予測不能性は全体的なパフォーマンスを改善します。 集中的に作業しているサイトは、各要求の実行の開始時にビジー状態になり、セッションを削除するために期限切れのセッションを検索するため、サーバーリソースを大量に消費します。
これは、削除されたデータの「ランダム性」を説明しています。
しかし、私のプロジェクトではダウンタイムが24分を超える可能性があるため、この問題を解決する方法。
再びマニュアルに目を向けます。
session.gc_maxlifetime構成ディレクティブは、セッションアクティビティが維持されているリクエスト間の最大アイドル時間の設定を制御します。 デフォルト値は1440-24分でちょうど数秒です。 session.gc_maxlifetimeの値を変更するには、サーバー構成を設定するか、プログラムからini_set（）関数を直接呼び出します。 この関数の呼び出しは、 session_start（）関数の呼び出しの前に行う必要があります。
さて、これですべてが明確になりましたが、この不幸な1％の確率についてさらに学びたいです。 プロジェクトでセッションデータに関する別のロジックが必要な場合、この値を何らかの方法で変更することは可能ですか？
期限切れのセッションを確実に削除する場合は、1％の確率に依存しないでください。 session.gc_probability構成ディレクティブは、要求処理の開始時に「廃止セッションの削除」サブルーチンを開始する確率の割合を設定します。 各リクエストの処理の開始時にこのプロセスを開始するには、ディレクティブ値を100に設定します。また、 session.gc_maxlifetimeの場合と同様に、 session.gc_probabilityの値を変更するini_set（）関数の呼び出しは、 session_start（）関数の呼び出しよりも前に行う必要があります。
ただし、確率値を100に設定すると、各リクエストの前に古いセッションの検索が実行されるため、パフォーマンスに大きく影響し、サーバーが十分に曲がることがあります。
私の場合、必要なデータが消去されないように、セッションデータを削除する前にダウンタイムを増やすだけです。 おそらく、プロジェクトでセッションデータを使用したより厳密な作業が必要な場合は、確率とダウンタイムの理想的な比率を見つける必要があります。
この情報が誰かに役立つことを願っています...
上記の「マニュアル」へのリンク： physics.grsu.by/seti/doc/PHP/PHP5/g8_4.html
更新
私自身も、この「マニュアル」で考慮されなかったsession.gc_divisorディレクティブについて追加したいと思います。 デフォルトでは100であり、 session.gc_probabilityの値が実際に％確率と一致することがわかります。 実際、確率はgc_probability / gc_divisorとして計算されます。 つまり 値付き：gc_probability = 1確率はすでに1％ではなく、0.1％です。
gc_divisor = 1000
ロシアのほとんどのホスティングプロバイダーは（サーバーの負荷を減らすために）この比率を1/1000に設定しているため、24分（デフォルト）後にデータが削除される可能性は非常に小さいことに注意してください。 セッションデータを使用してアプリケーションがより強力に動作するように設定する必要がある場合は注意してください。