多すぎるセッションファイルをどのように処理する必要がありますか?
-
16-10-2019 - |
質問
私は、Magentoサイトを保持しているいくつかのサーバーのSysadminとして行動しており、時にはセッションファイルでいっぱいになります。
これらのファイルを管理することはMagento内からできることではないと言われており、それらの一時的な使用は、彼らがただオフにすることはできないことを意味しますが、Magentoにこれらの除去を処理する方法がないことは奇妙に思えますファイル?
私の解決策は、このようなことを実行する毎晩のクロンタブです find /path/to/magento/sessions/ -name "sess*" -type f -delete
しかし、控えめに言っても、それはエレガントだと感じています。
これらを処理するための最良の方法は何ですか?
解決
セッションファイルを削除することは別として find
他の人が述べたようにカスタム変更時間を使用すると、次のこともできます。
を助けて データベースのセッション. 。もちろん、これはデータベースに負荷をかけ、最速の方法ではありませんが、そのようにしてより多くのセッションを処理することができ、複数のフロントエンドサーバー間でセッションを共有できます。設定を変更できます
app/etc/local.xml
切り替えによって<session_save><![CDATA[files]]></session_save>
に
<session_save><![CDATA[db]]></session_save>
使用する memcached セッションストレージとして。 Magentoはデフォルトでこれをサポートしています。見て
app/etc/local.xml.additional
構成用。私は生産でそれを使用したことはありませんが、これは少し難しいかもしれないと聞いています。を処理します レディスのセッション Colin Mollenhours Brilliant Extensionを使用します cm_redissession. 。 Redisのセットアップはあまりにも時間がかかるはずであり、キャッシュにも使用できます(参照 cm_cache_backend_redis)そして、RAMキャッシュをディスク上の永続性と組み合わせます(Memcached、RAMディスクなどに反対して)、サーバーが常にクラッシュしている場合は常に行われます。
他のヒント
ファイルベースのセッションでは、PHPセッションクリーンアップクロンによって自動制作されます。そのため、ファイルは作成から約7200秒以内に削除される可能性があります。したがって、忙しいサイト(1日あたり30Kユニーク)でも、通常、./var/sessionには約4,000のセッションファイルしかありません。これは、ローエンドのLinuxサーバーでもありません。
ただし、クリーンアップは実際にはCronの動作に依存しています。これは通常、Magentoの./var/sessionディレクトリを見ることはありません。したがって、新しいシステムクロンをセットアップする必要があります
/usr/bin/find /home/myuser/public_html/var/session -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 -exec rm {} \; >/dev/null 2>&1
セッションのデフォルトのクリーンアップ期間は7200秒ですが、これは適切であるはずですが、上記を変更することはできます。
Memcacheセッションでは、TCP/IPが唯一のオーバーヘッドです。シングルサーバーの展開では、ファイルベースよりも遅くなります。そのため、代わりにUnixソケットを使用して、そのオーバーヘッドを削除し、より良いセキュリティを提供します。それでも、顧客セッションは、割り当てることができるRAMの量に関して切り捨てられ/制限されます。平均Magentoセッションは4kbです。そのため、割り当てたMBあたりの256のアクティブセッションをサポートできます。したがって、顧客がカート/セッションをランダムに失うことを避けるために、適切な制限を設定してください。また、Memcache Daemon Restartが既存のすべてのセッション(悪い!)を一掃することにも留意してください。
Redis(ネイティブではなく、拡張機能を介して利用可能)を使用すると、Memcacheと同様のレベルのサポートが得られますが、Persistenceの追加の利点があります(使用したい場合)。 CM_redis拡張機能を使用すると、セッション圧縮を活用することもできます。この拡張機能は、CEとEEの両方の展開で非常にうまく機能することがわかりました。
DBを使用すると、デフォルトのプルーンの有効期限設定は1週間であるため、上記のストアサイズを例として(1日あたり30Kユニーク)、約7GBのcore_cache_sessionのDBテーブルサイズを調べます。ほぼすべてのセッションベースの操作について、あなたの店が完全に停止します。
ホスティングの経験から 大規模な(1日あたり230kのユニーク訪問者)と小規模(1日あたりの1k <1Kユニークビジター)ストアの両方が、次のとおりです。
シングルサーバー展開-Files
マルチサーバー展開-Redis(メインMagentoキャッシュから個別のデータベースを使用)
私はここにいくつかの本当に徹底的な返信を書きました http://magebase.com/magento-tutorials/magento-session-storage-to-choose-and-why/comment-page-1/#comment-1980
私はしばらく前に関連する質問をしました:
https://stackoverflow.com/questions/7828975/php-garbage-collection-crolification
私が見つけたことがないこと(私はその仕事を新しい仕事に任せ、元の問題は他の人の仕事になりました)は、Magentoのセッションがこれらの設定を尊重するか、Zendを使用してセッション処理を実装する場合です(そしておそらくある種のZend.ini構成ファイル)。
見るべきPHP設定:
session.gc_maxlifetime
session.gc_probability
session.gc_divisor
http://php.net/manual/en/session.configuration.php#ini.session.gc-probability
通常、クロンの仕事で十分ですが、ここに留意すべきことがいくつかあります。
1)セッションを以下に続くことはありません session.gc_maxlifetime
(php -i | grep session.gc_maxlifetime
)秒(これにより、PHP.iniまたは.htaccessによるゴミ収集の準備のために期限切れのセッションが設定されます)
2)データベースにセッションを保存することをお勧めします ここ これを行う方法の詳細について
3)考慮すべき別のオプションは、Memcached Witchがサーバーをスピードアップすることもできることです(質問に完全に接続されていませんが、知っておくと便利だと思います)
詳細については、この質問を参照してください。 https://stackoverflow.com/questions/4353875/how-long-the-magento-session-files need-to-be-skept
すべてのセットアップには、時々ログとVARディレクトリのクリーニングを処理するMentainance.phpファイルがあります。セッションはデータベースまたはファイルシステムに保存する必要があるため、このメンテナンスファイルは両方をクリーンアップします。 (以下のコードを参照)。
ログをクリーンアップするために、次のコマンドをCronジョブとして実行できます。
php maintenance.php clean=log
上記のコマンドは、次の出力を生成します。
catalogindex_aggregation has been truncated
catalogindex_aggregation_tag has been truncated
catalogindex_aggregation_to_tag has been truncated
catalog_compare_item has been truncated
dataflow_batch_export has been truncated
dataflow_batch_import has been truncated
log_customer has been truncated
log_quote has been truncated
log_summary has been truncated
log_summary_type has been truncated
log_url has been truncated
log_url_info has been truncated
log_visitor has been truncated
log_visitor_info has been truncated
log_visitor_online has been truncated
report_compared_product_index has been truncated
report_event has been truncated
report_viewed_product_index has been truncated
次のコマンドをCronジョブとして実行して、VARフォルダーをクリーンアップできます。
php maintenance.php clean=var
上記のコマンドは、次の出力を生成します。
downloader/.cache/* has been emptied
downloader/pearlib/cache/* has been emptied
downloader/pearlib/download/* has been emptied
var/cache/ has been emptied
var/locks/ has been emptied
var/log/ has been emptied
var/report/ has been emptied
var/session/ has been emptied
var/tmp/ has been emptied
実際のコード(local.xmlファイルへのパスを調整することを忘れないでください):
<?php
$xml = simplexml_load_file('./app/etc/local.xml', NULL, LIBXML_NOCDATA);
$db['host'] = $xml->global->resources->default_setup->connection->host;
$db['name'] = $xml->global->resources->default_setup->connection->dbname;
$db['user'] = $xml->global->resources->default_setup->connection->username;
$db['pass'] = $xml->global->resources->default_setup->connection->password;
$db['pref'] = $xml->global->resources->db->table_prefix;
if (!isset($argv[1]) || !stristr($argv[1], 'clean=')) {
echo 'Please use one of the commands below:' . PHP_EOL;
echo 'php maintenance.php clean=log' . PHP_EOL;
echo 'php maintenance.php clean=var' . PHP_EOL;
die;
}
$method = str_replace('clean=', '', $argv[1]);
switch ($method) {
case 'log':
clean_log_tables();
break;
case 'var':
clean_var_directory();
break;
default:
echo 'Please use one of the commands below:' . PHP_EOL;
echo 'php maintenance.php clean=log' . PHP_EOL;
echo 'php maintenance.php clean=var' . PHP_EOL;
break;
}
function clean_log_tables() {
global $db;
$tables = array(
'catalogindex_aggregation',
'catalogindex_aggregation_tag',
'catalogindex_aggregation_to_tag',
'catalog_compare_item',
'dataflow_batch_export',
'dataflow_batch_import',
'log_customer',
'log_quote',
'log_summary',
'log_summary_type',
'log_url',
'log_url_info',
'log_visitor',
'log_visitor_info',
'log_visitor_online',
'report_compared_product_index',
'report_event',
'report_viewed_product_index'
);
mysql_connect($db['host'], $db['user'], $db['pass']) or die(mysql_error());
mysql_select_db($db['name']) or die(mysql_error());
foreach($tables as $v => $k) {
@mysql_query('TRUNCATE `'.$db['pref'].$k.'`');
echo $db['pref'] . $k . ' has been truncated' . PHP_EOL;
}
}
function clean_var_directory() {
$dirs = array(
'downloader/.cache/*',
'downloader/pearlib/cache/*',
'downloader/pearlib/download/*',
'var/cache/',
'var/locks/',
'var/log/',
'var/report/',
'var/session/',
'var/tmp/'
);
foreach($dirs as $v => $k) {
exec('rm -rf '.$k);
echo $k . ' has been emptied' . PHP_EOL;
}
}
Magento CMSなど(古いセッションを掃除していない)の場合、PHP.iniの設定に基づいてCronジョブを使用しています。
php5/ubuntu 14.04/debian
PHP5用のシステムCRON.DセットアップはMagento ./var/session(またはデフォルトのセッションフォルダー(/var/lib/php5以外のもの)をクリーニングしません。 dists)。
ただし、デフォルトのPHP5/Debian System Cronに従って、「SessionClean」と「Maxlifetime」を使用できます。
例コマンドラインから試すことができます:
# sudo /usr/lib/php5/sessionclean /var/www/{yoursite}/var/session $(/usr/lib/php5/maxlifetime)
そのため、セッションファイルの読み取り/書き込み許可を持っているシステム/ルートクロンタブまたはクロンタブにそれを組み込むだけです。
$ sudo crontab -e
これを追加して、システムPHP Cronに似ているようにしたいです。
20,40 * * * * [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/www/*/var/session ] && /usr/lib/php5/sessionclean /var/www/{yoursite}/var/session $(/usr/lib/php5/maxlifetime)
または - これらのファイル/dirが存在することがわかっているため:
20,40 * * * * /usr/lib/php5/sessionclean /var/www/*/var/session $(/usr/lib/php5/maxlifetime)
これで、管理可能な量のセッションがあり、PHP.ini(CLI)設定を介してデフォルトのガベージコレクション/ライフタイムを介してきれいに保たれています。
(上にワイルドカードを残すか、SiteNameに置き換えることができます。)
編集(php7 / ubuntu 16.xx / debian):
「SessionClean」スクリプトが変更され、Maxlifetimeスクリプトが削除されました。システム/PHP Cronジョブの場合、それは現在1つのスクリプトになっています。 ファイル呼び出しがスクリプトの静的になるので、これを実際に使用することはできません。
古いphp5 SessionClean システムがクリーンアップしていない場合、スクリプトは引き続き機能します。あなたができることは、年をとることです Debian Php5パッケージ そして抽出します sessionclean
それから。または、これをスクリプト領域に単純にコピーすることもできます(適切な/var/www/(site)権限/所有権を与える):
#!/bin/sh
# first find all used files and touch them (hope it's not massive amount of files)
[ -x /usr/bin/lsof ] && /usr/bin/lsof -w -l +d "${1}" | awk -- '{ if (NR > 1) { print $9; } }' | xargs -i touch -c {}
# find all files older then maxlifetime
find "${1}" -depth -mindepth 1 -maxdepth 1 -ignore_readdir_race -type f -cmin "+${2}" -delete
また、名前を変更することもお勧めします。これにより、新しいPHP 'SessionClean' Cronjobと混同されないこともあります。その後、あなた自身の「maxlifetime」番号をように差し込むことができます:
20,40 * * * * /home/-username-/scripts/MySessionClean /var/www/*/var/session 61
(61年齢(数分で)と「MySessionClean」は、上記からダウンロードまたはコピーされたPHP5スクリプトと改名された「MySessionClean」です)。
このようにして、php.ini/envコールを完全に回避します。
(編集13DEC2016:Debian Archive Repoリンクを更新)
これらすべての古いセッションファイルからDBを再びクリアしました。私がインストールするまで、それは刺激的な手動の作業でした Magento Optimizer これにより、このすべての日常的な機能が機能します。また、私のキャッシュは絶えず更新されており、製品や静的ブロックを変更した後、手動ではそうではありません。ああ、はい、エラーレポートと放棄されたカートも掃除されています。
上記のすべてのコメントの中で、これは簡単なソリューションであり、長いスクリプトよりも優れていることを願っています。
- 下に「clean_session.sh」というファイル名を作成します
magento
フォルダ。 - これらの行を貼り付けます。
#!/bin/bash
# delete session files older than 14 days
find /home/DOMAIN/public_html/var/session -name 'sess_*' -type f -mtime +14 -exec rm {} \;
- その後、Cronjobを毎週スケジュールしてクリーンアップを実行できます。
1 1 * * 6 /bin/sh /home/DOMAIN/public_html/clean_session.sh
- ファイルを実行可能にすることを忘れないでください
chmod u+x clean_session.sh
- また、そのように実行することもできます
sh clean_session.sh
私の場合、私はこのスクリプトを配置します magento/var/
セッションファイルを1週間以上削除するためのディレクトリ(-mtime +7
) 年:
#!/bin/sh
# Place this script in magento/var/ directory
for n in `seq 0 9`
do
for u in `seq 0 9`
do
for m in `seq 0 9`
do
name="sess_"$n$u$m*
echo $name
find session/ -name $name -type f -mtime +7 -delete
echo $name ok
done
for m in {a..z}
do
name="sess_"$n$u$m*
echo $name
find session/ -name $name -type f -mtime +7 -delete
echo $name ok
done
done
for u in {a..z}
do
for m in `seq 0 9`
do
name="sess_"$n$u$m*
echo $name
find session/ -name $name -type f -mtime +7 -delete
echo $name ok
done
for m in {a..z}
do
name="sess_"$n$u$m*
echo $name
find session/ -name $name -type f -mtime +7 -delete
echo $name ok
done
done
done
for n in {a..z}
do
for u in `seq 0 9`
do
for m in `seq 0 9`
do
name="sess_"$n$u$m*
echo $name
find session/ -name $name -type f -mtime +7 -delete
echo $name ok
done
for m in {a..z}
do
name="sess_"$n$u$m*
echo $name
find session/ -name $name -type f -mtime +7 -delete
echo $name ok
done
done
for u in {a..z}
do
for m in `seq 0 9`
do
name="sess_"$n$u$m*
echo $name
find session/ -name $name -type f -mtime +7 -delete
echo $name ok
done
for m in {a..z}
do
name="sess_"$n$u$m*
echo $name
find session/ -name $name -type f -mtime +7 -delete
echo $name ok
done
done
done
これは私の最初のバッシュスクリプト(改訂2)であり、いくつかの面で最適化できると思います。私はどんな最適化の提案でもオープンです。
このスクリプトを取得できます。 https://gist.github.com/nolwennig/a75dc2ff8628be2864bb2
var/sessionディレクトリを空にするスクリプトを作成しました。 Cronジョブに追加して、1日に1回実行し、必要に応じて調整することができます。セッションディレクトリが入力されると、CPANELまたはSSHを介してファイルを削除することは不可能であることがわかります。このスクリプトは、Magento Root Directoryにあるトリックを行います。
<?php
function adjustSessionFiles($dir, $pattern = "*")
{
$files = glob($dir . "/$pattern");
foreach ($files as $file) {
if (is_dir($file) and !in_array($file, array('..', '.'))) {
adjustSessionFiles($file, $pattern);
}else if(is_file($file) and ($file != __FILE__)) {
unlink($file);
}
}
}
$dir = __DIR__ . DIRECTORY_SEPARATOR . 'var' . DIRECTORY_SEPARATOR . 'session';
adjustSessionFiles($dir);