sessions表锁定

dashan 提交于

论坛: 
drupal 基础
users表用于存在Drupal用户的基本信息，可以存储所有用户共用的UID及其基本字段；
sessions表用于存放Drupal用户Sessions，可以统计所有站点的在线用户量；
role表用于存放所有Drupal站的角色；
users_roles存放所有Drupal站的权限；
Drupal会话（session）会话生命周期
从一个浏览器向服务器发送一个请求起，会话开始。在Drupal的引导指令流程的DRUPAL_BOOTSTRAP_SESSION阶段，会话代码开始运行。如果浏览器不能提供以前从站点接收到的cookie的话，PHP的会话管理系统将位浏览器提供一个带有一个新的PHP会话ID的cookie。其中会话ID通常为32位字符串，使用MD5哈希函数处理过。当然，PHP5允许你将配置指令session.hash_function设置为1，使得你可以使用SHA-1哈希来得到40位的字符串作为会话ID。 
注意：MD5是一个文本字符串的哈希值的算法，也是Drupal选用的默认哈希算法。 
Drupal然后检查在表sessions中是否存在以该会话ID为键的记录。如果存在的话，那么函数sess_read()将会话数据取出，并进行一次SQL联合操作，对表sessions中的该记录及表users中的相应记录进行联合，其结果是得到一个包含了两个记录所有字段和值的对象，这就是在后面的Drupal中广泛使用的全局变量$user。那么，通过$user,具体一点就是$user->session也可以访问会话数据。在这里，当前用户的角色也被取出并分配给$user->roles。 
如果没有一个用户的用户ID和会话中的用户ID相匹配，那会发生什么呢？这个问题具有欺骗性。由于Drupal的表users中默认有一记录其用户ID为0，而且匿名用户在sessions表中其uid指定为0，所以联合总是工作的。 
当页面发送给浏览器时，最后一步工作就是关闭会话。PHP出发includes/session.inc里面的sess_write()函数，它将$_SESSION(请求期间的)中存放的任何数据都写入到表sessions中。也有例外情况，比如，如果请求者不接受cookie时，在这种情况下，不向表sessions中写入任何数据。这样就可以在网络爬虫抓取页面时，阻止向表sessions中写入数据了，因为表中的数据量的大小直接影响到性能。
调优Sessions表
Drupal 将用户会话保存到了它的数据库中，而不是文件中（参看第16章）。这意味着Drupal能够很容易的应用到多个服务器上，但是由于要管理每个用户的会话信息这也增加了数据库的负担。如果一个站点每天有成千上万的用户访问，那么很容得就会看到这个表将会极速膨胀。
你可以通过PHP来控制多长时间清除一次旧的会话记录。Drupal将这一配置放到了它的settings.php文件中：
ini_set('session.gc_maxlifetime', 200000); // 55 hours (in seconds)
垃圾收集系统运行周期，默认设置为两天多点时间。这意味着如果用户两天内没有登录，那么它的会话将被删除。如果你的sessions表不断疯长，那么你需要提高PHP的会话垃圾收集系统的运行频率。
ini_set('session.gc_maxlifetime', 86400); // 24 hours (in seconds)
ini_set('session.cache_expire', 1440); // 24 hours (in minutes)
当调整session.gc_maxlifetime时，最好也将session.cache_expire设为相同的值，session.cache_expire用来控制缓存中会话页面的存活周期。注意session.cache_expire值的单位为分钟。
管理已验证用户的访问
由于Drupal可以为匿名用户提供缓存了的页面，而匿名用户一般也不需要与Drupal进行交互，你可能想要减少用户登录停留的时间，或者更疯狂一点，一旦用户关闭他们的浏览器就使他们退出。通过调整settings.php文件中的cookie生存周期来做到这一点。在下面这行代码中，我们将它的值改为24小时：
ini_set('session.cookie_lifetime', 86400); // 24 hours (in seconds)
而在这里一旦用户关闭浏览我们就将他们登出：
ini_set('session.cookie_lifetime', 0); // When they close the browser.
settings.php中的默认值（2,000,000秒）能够允许用户保持登录大约3周的时间（在此期间会话垃圾收集系统不会将他们的会话记录从sessions表中删除）。
提示 如果你处于一个非常特殊的环境下，在一个访问量很大的站点上cron却永远没有运行过或者它没有被充分的运行，你可以手工的进行一些属于cron管理的操作。你可以随时清空缓存表(TRUNCATE TABLE 'cache', TRUNCATE TABLE 'cache_filter', and TRUNCATE TABLE 'cache_page')，而它将会重新构造自己。还有，在情急之时，你可以清空watchdog和sessions表来重新控制一个失控的Drupal站点。删除watchdog记录意味着你将丢失所有的错误消息，它们可能指示站点的问题所在。如果你想保存这些数据，那么在清空表watchdog以前，先对它进行备份。清空sessions表会使当前已登录的用户退出系统。
遇到sessions表损坏这种情况是非常罕见的，php虚拟主机用户免费迁移drupal站点的时候偶尔会的出现这样的问题。这个问题处理起来其实是很简单的。
错误的类型确定以后呢，就来处理这个问题吧。
1、使用phpMyAdmin选择sessions表并选择“修复表”选项，如果没效果的话继续往下看。
2、选择sessions表，并选择“清空”，但这样很直接的就是导致sessions表中的数据丢失，但您不用去担心恢复表中的数据的问题，所以的数据会在您网站的认证用户再次登录到您的站点的时候会重新建立。