magento 会话文件需要保留多长时间？答案

【问题标题】：How long do the magento session files need to be kept?magento 会话文件需要保留多长时间？
【发布时间】：2010-12-04 14:06:12
【问题描述】：

我有一个客户，他的 magento 会话文件正在迅速失控。我们每周清洗一次，但似乎需要更频繁。

1) 这些文件有什么作用？它们如何与用户的在线体验相关联（例如，如果我删除它们而用户仍在网站上，它们将如何受到影响）

2) 我多久可以删除它们？文件真正需要在服务器上保留多长时间？

克里斯

【问题讨论】：

标签： php session magento memcached

【解决方案1】：

对于基于文件的会话，它们将被 PHP 会话清理 cron 自动修剪——因此文件很可能在创建后约 7200 秒内被删除。因此，即使在一个繁忙的站点（每天 30k 唯一身份）上，./var/session 中通常也只有大约 4,000 个会话文件——这对于 Linux 服务器来说不算什么。

但是，清理实际上依赖于 cron 工作 - 通常不会在 Magento 的 ./var/session 目录中查看。所以你应该设置一个新的系统cron

/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 守护进程重启会清除所有现有会话（糟糕！）。

使用 Redis（不是原生的，但可以通过扩展获得），您可以获得与 Memcache 类似级别的支持，但具有持久性的额外好处（如果您希望使用它）。通过 Cm_Redis 扩展，您还可以利用会话压缩。我们发现这个扩展在 CE 和 EE 部署中都非常有效。

使用 DB，默认修剪到期设置是 1 周，因此以上述存储大小为例（每天 30k 唯一），您将看到 core_cache_session 的 DB 表大小约为 7GB –对于几乎所有基于会话的操作，这将使您的商店完全停止。

根据托管大型（每天 230k 独立访客）和小型（每天

单服务器部署 - 文件

多服务器部署 - Redis（使用与主 Magento 缓存不同的数据库）

我在这里写了一些非常彻底的回复http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980

【讨论】：

这是一个非常可靠的策略，文件用于单服务器，Redis 用于多服务器部署。另一个答案是关于为什么会话文件在繁忙的服务器上不断增长的原因，这与 PHP.INI 设置 session.gc_maxlifetime 有关

【解决方案2】：

每个文件都是一个人的会话，应该持续时间不超过session.gc_maxlifetime 秒 - 垃圾收集 - 在服务器的 php.ini 文件中设置或在 .htaccess 文件中被覆盖。降低此值意味着将累积更少的会话。

Magento 有另一个关于会话的技巧；在/app/etc/local.xml 文件中，session_save 值可以更改为db，这意味着将使用数据库而不是文件，但仍会遵守上述垃圾收集器的生命周期。如果您已经设置了memcache，也可以指定它（参见/app/etc/local.xml.additional）。如果服务器是集群，两者都非常有用。

【讨论】：

使用数据库进行会话管理还有其他优势吗？我通常使用文件系统（我相信这是默认设置）。
数据库存储的会话会更容易备份。如果数据库是一个单独的服务器，它将减少在主服务器硬盘上的工作量，尽管如果您担心这种事情，您也可以将会话文件夹挂载为 tmpfs。与数据库不会随着会话数量的增加而用尽文件句柄的文件不同，文件系统对其可以容纳的文件数量有限制，而繁忙的服务器可能会超过该限制。数据库也可以透明地压缩它的表，这也会减少空间需求。
我建议不要使用 memcache 来存储会话，因为 Magento Cache Flush with memcache 是全部或全部 - 这意味着当您刷新缓存时，您将终止客户会话。 Memcache 非常适合 magento，而不是会话。
@JonathanDay 如果您将单独的 memcached 实例用于缓存/全页缓存和会话，则无论如何都应该这样做

【解决方案3】：

取决于您的会话生命周期，如果会话保持用户保持登录状态或他的偏好在再次访问商店时保持不变。您可以随时清除它们，但请记住，它会在您执行此操作时为所有登录的用户注销/清除购物车

【讨论】：

【解决方案4】：

不要忘记查看系统的哪个部分在会话中不正确地存储了不合理的数据量以实际解决问题。尽早清除会话只是临时解决办法。

会话文件应始终保持较小。奇怪的是，一些脚本为了“效率”在会话中存储了不恰当的大量数据并导致了问题。

几乎可以肯定的是，会话中存储的对象会导致此问题。 Magento 中的一个常见模式是像这样链接对象数据：

$product->
   'attr1' => 'somevalue',
   ...
   'categories' => array(
       'products' => array(
         <and so on and so forth>
       ),
   ),

将对象放入会话中可能会无意中包含这个巨大的对象链，存储大量无关数据。如果可能，在会话中仅存储字符串/数字数据，例如产品的 ID 数组，而不是产品本身。

【讨论】：

嗯好吧，任何关于可能是什么的例子的想法。我确实有很多修改。您是否认为存储诸如 magento 对象之类的东西或类似性质的东西可能会导致这种情况？

【解决方案5】：

我也让它们堆积起来，所以我添加了一个带有以下内容的 cron 作业......（这是来自我的 php.ini 文件中的说明......就在“session.gc_maxlifetime = 1440”设置下）

例如，以下脚本相当于 ;将 session.gc_maxlifetime 设置为 1440（1440 秒 = 24 分钟）： ;查找 /path/to/sessions -cmin +24 | xargs rm

【讨论】：